Subject: excluding all names of given type

From: Anne Anderson <[email-masked]>
Date: Thu, 17 Aug 2000 11:13:59 -0400 (EDT)

CASE: NameConstraints excludedSubtrees contains a directoryName where
the RDNSequence is null

SEMANTICS: Does this mean that the subsequent path may contain no
names of type directoryName in either Subject or the
SubjectAlternativeNames?

Is there a better way to achieve these semantics?

Anne
-- 
Anne H. Anderson             Email: [email-masked]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Aug 2000 11:29:53 -0400

Anne,

I think the example you gave is a reasonable way to express the 
semantics in question.  (Slight clarification: since a subject name 
is always a DN, the example suggests to me that the subject name 
would have to be NULL to comply, and that a subject alt name must be 
of a type other than directory name.)

Steve

---

From: Tim Polk <[email-masked]>
Date: Thu, 17 Aug 2000 13:55:59 -0400

Anne,

I think I would state this in reverse.

CASE: NameConstraints *includedSubtrees* contains a directoryName
where the RDNSequence is NULL

has the

SEMANTICS:  The Subject field and the directoryName field of the
SubjectAlternativeName (if it appears at all) may only contain names in
the subtree NULL for all successive certificates in the path.

The only name in the subtree NULL would be the exact match - the
NULL value.  That would work, since we require a NULL RDNSequence if
the Subject is omitted.  As Steve has pointed out, this should only
occur in an end entity certificate.

This is not particularly straightforward, I know.  We are using the
include feature to exclude names!  However, it works *if* you
consider the only name in the subtree NULL is NULL itself.

On the other hand, you could consider NULL the implicit root of all
subtrees, the correct answer is excludedSubtrees is NULL with a minimum
value of 1.  (We would need to set the minimum to 1 so that NULL
itself was not excluded.)

This would force us to use (and process) the minimum value.  RFC
2459 states that the minimum and maximum never are used, so minimum is
always zero.

I prefer the *includedSubtrees* solution.  The truth is, of course,
as long as we pick one way and state it clearly we should be fine.
I don't think the X.5xx specifications cover this issue, but I've been
wrong before on that point!

Sharon, do you know if this topic has been addressed anywhere
before??  Our first consideration should be conformance to X.509 etc
if a clear solution has been established.  If this has not been
addressed, we should sort it out ASAP.

Thanks,

Tim

At 11:13 AM 8/17/00 -0400, Anne Anderson wrote:

CASE: NameConstraints excludedSubtrees
contains a directoryName where

the RDNSequence is null

SubjectAlternativeNames?

Anne

--

Anne H.
Anderson
Email: [email-masked]

1 Network Drive,UBUR02-311     Tel:
781/442-0928

Burlington, MA 01803-0902 USA  Fax:
781/442-1692

---

From: "David Chadwick" <[email-masked]>
Date: Mon, 21 Aug 2000 18:50:20 +0100

Date sent:      	Thu, 17 Aug 2000 13:55:59 -0400

To:             	Anne Anderson <<[email-masked]>, [email-masked]

From:           	Tim Polk <<[email-masked]>

Subject:        	Re: excluding all names of given type

Copies to:      	Sharon Boeyen <<[email-masked]>

<FontFamily><param>Times New Roman</param><smaller>Anne,

<paraindent><param>left</param>CASE: NameConstraints *includedSubtrees* contains a directoryName where 
the RDNSequence is NULL

has the

<paraindent><param>left</param>SEMANTICS: The Subject field and the directoryName field of the 
SubjectAlternativeName (if it appears at all) may only contain names in the 
subtree NULL for all successive certificates in the path.

The only name in the subtree NULL would be the exact match - the NULL 
value. That would work, since we require a NULL RDNSequence if the Subject 
is omitted. As Steve has pointed out, this should only occur in an end entity 
certificate.

<paraindent><param>left</param>Tim</paraindent>

I do not agree with your semantics. The null name is the name of the root of the 
DIT, and therefore implies ALL subordinate names.
Since a DIT subtree can comprise a single entry or any number of entries up to 
the whole DIT, then a null name implies a subtree of the whole DIT.
Thus include NULL implies include any directory name at all - not a particularly 
usefull extension to include in a certificate.

David

This is not particularly straightforward, I know. We are using the include feature 
to exclude names! However, it works *if* you consider the only name in the 
subtree NULL is NULL itself.

On the other hand, you could consider NULL the implicit root of all subtrees, the 
correct answer is excludedSubtrees is NULL with a minimum value of 1. (We 
would need to set the minimum to 1 so that NULL itself was not excluded.)

This would force us to use (and process) the minimum value. RFC 2459 states 
that the minimum and maximum never are used, so minimum is always zero.

I prefer the *includedSubtrees* solution. The truth is, of course, as long as we 
pick one way and state it clearly we should be fine. I don't think the X.5xx 
specifications cover this issue, but I've been wrong before on that point!

Sharon, do you know if this topic has been addressed anywhere before?? Our 
first consideration should be conformance to X.509 etc if a clear solution has been 
established. If this has not been addressed, we should sort it out ASAP.

Thanks,

Tim

<paraindent><param>left</param>CASE: NameConstraints excludedSubtrees contains a directoryName where
the RDNSequence is null

Anne
-- 
Anne H. Anderson Email: [email-masked]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692</paraindent>

<nofill>
***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: "David Chadwick" <[email-masked]>
Date: Mon, 21 Aug 2000 18:50:19 +0100

From:           	Anne Anderson <[email-masked]>
Date sent:      	Thu, 17 Aug 2000 11:13:59 -0400 (EDT)
To:             	[email-masked]
Subject:        	excluding all names of given type

> names of type directoryName in either Subject or the

Anne
I would agree with your interpretation above,
David

David Chadwick

---

From: Tim Polk <[email-masked]>
Date: Tue, 22 Aug 2000 11:24:05 -0400

Folks,

I believe we have achieved consensus, and that Anne's original proposal
should be incorporated into son-of-2459.  We have heard from Anne
Anderson, John Wray, and David Chadwick on the list.  I also spoke
to Sharon Boeyen on the phone.  Everyone agrees with David
that

"The null name *is* the name
of the root of the DIT"

so we should use the null name in excludedSubtrees to exclude
all names of type distinguished name (i.e, in the subject or
directoryName in subjectAltName.)

John pointed out that

"An empty subject DN in a certificate doesn't  mean that
the certificate applies to a principal whose DN is the root of  the
DIT, rather that the principal in question has no DN. This is a special
case, called out explicitly in the PKIX profile. A certificate

with an empty DN should be permitted regardless of any DN name
constraints.So I don't think this requires that you set the minimum value
to 1 - 0 should do just fine."

This means we do not have to change the specification with respect
to minimum and maximum.

Anyway, I will draft some proposed text and forward it to the list in the
next day or so...

Thanks!

Tim

At 06:50 PM 8/21/00 +0100, David Chadwick wrote:

Date sent:
Thu, 17
Aug 2000 13:55:59 -0400

To:
Anne
Anderson <[email-masked]>, [email-masked]

From:
Tim Polk
<[email-masked]>

Subject:
Re:
excluding all names of given type

Copies to:
Sharon
Boeyen <[email-masked]>

Anne, I think I would state
this in reverse. CASE: NameConstraints *includedSubtrees* contains a
directoryName where the RDNSequence is NULL

has the

The only name in the subtree NULL would be the exact match - the NULL
value. That would work, since we require a NULL RDNSequence if the
Subject is omitted. As Steve has pointed out, this should only occur in
an end entity certificate.

Tim

I do not agree with your semantics. The null name is the name of the root
of the DIT, and therefore implies ALL subordinate names. Since a DIT
subtree can comprise a single entry or any number of entries up to the
whole DIT, then a null name implies a subtree of the whole DIT. Thus
include NULL implies include any directory name at all - not a
particularly usefull extension to include in a certificate.

David

This is not particularly straightforward, I know. We are using the
include feature to exclude names! However, it works *if* you consider the
only name in the subtree NULL is NULL itself. On the other hand, you
could consider NULL the implicit root of all subtrees, the correct answer
is excludedSubtrees is NULL with a minimum value of 1. (We would need to
set the minimum to 1 so that NULL itself was not excluded.) This would
force us to use (and process) the minimum value. RFC 2459 states that the
minimum and maximum never are used, so minimum is always zero. I prefer
the *includedSubtrees* solution. The truth is, of course, as long as we
pick one way and state it clearly we should be fine. I don't think the
X.5xx specifications cover this issue, but I've been wrong before on that
point! Sharon, do you know if this topic has been addressed anywhere
before?? Our first consideration should be conformance to X.509 etc if a
clear solution has been established. If this has not been addressed, we
should sort it out ASAP. Thanks, Tim At 11:13 AM 8/17/00 -0400, Anne
Anderson wrote:

CASE: NameConstraints excludedSubtrees contains a directoryName where the
RDNSequence is null SEMANTICS: Does this mean that the subsequent path
may contain no names of type directoryName in either Subject or the
SubjectAlternativeNames? Is there a better way to achieve these
semantics? Anne -- Anne H. Anderson Email: [email-masked] Sun Microsystems
Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA
01803-0902 USA Fax: 781/442-1692

David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel
+44 161 295 5351  Fax +44 161 745 8169 Mobile +44 790 167 0359 Email
[email-masked] Home Page
http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J

</blockquote></x-html>