Subject: Comments on CA clearance constraints

From: Stefan Santesson <[email-masked]>
Date: Tue, 10 Feb 2009 11:28:47 +0100

1) Nit

Second paragraph of section 1. Introduction says:

   Clearance attribute may be placed in the Subject Directory extension
   of a PKC or may be placed in a separate attribute certificate (AC).

It should say:

   Clearance attribute may be placed in the Subject Directory Attributes
   extension of a PKC or may be placed in a separate attribute
   certificate (AC).

Also, the different occurrences of this extension name use different
capitalizations.

2) Path Processing requirements for TA PKC extensions

 Section 4, second para:
       Authority Clearance
   Constraints certificate extension in the TA and in each PKC up to but
   not including the end PKC in a PKC certification path impact the
   effective-clearance.

Section 4, Para after numbered bullet list:
   Assuming a certification path consisting of n PKCs, the effective-
   clearance for the subject of the end PKC is the intersection of
   Clearance attribute in the subject PKC, Authority Clearance
   Constraints, if present, in trust anchor and all Authority Clearance
   Constraints present in intermediate PKCs.

These examples clearly defines clearance information in a TA certificate to
be part of the clearance processing. There is no room to treat this as
optional information as is the case for Root extensions in standard path
processing.
Technically this is not in conflict with RFC 5280 simply because this draft
does not define path validation or any changes to it. It just defines a new
type of certificate content and states the rules for processing it.

However, I¹m a bit concerned that this may cause integration problems with
current RFC 5280 compliant path processing engines and the APIs used to
invoke them. Some implementations may strip all information but the
essential variables from the root certificate but more seriously, some
environments use a mix of extension information and locally configured
parameters to determine the initial state variables for path processing. A
solid practice worth preserving in some cases.

The golden principle for PKI is that the relying party ultimately decides
the initial state variables and determines in the end if the certificate is
valid for their intended use.

I do not suggest any material changes but I¹m considering if the following
small adjustments would improve the document.
1. Make a clear note that this standard requires processing of TA
information beyond the initial state variables of RFC 5280.
2. Add a section/paragraph about initial state variables and TA information.
In this section state that the default input to the initial state is any CA
clearance extension in the TA certificate of the path but that this may
further be restricted by local policy at the discretion of the relying
party. 
3. Following this paragraph/section, only refer to the TA initial state
variables defined above, and not to specific data in the TA certificate.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 10 Feb 2009 09:18:47 -0500

Stefan,
 
I am ok with your suggestion.  Thanks for thinking of it.
 
Sean and Steve, 
 
Let me know.  If you agree, I will update the draft.

________________________________

	From: Stefan Santesson [mailto:[email-masked]] 
	Sent: Tuesday, February 10, 2009 5:29 AM
	To: [email-masked]; Sean Turner; Santosh Chokhani
	Cc: Stephen Kent
	Subject: Comments on CA clearance constraints

	1) Nit

	  Clearance attribute may be placed in the Subject Directory
extension
	   of a PKC or may be placed in a separate attribute certificate
(AC).

	It should say:
	
	  Clearance attribute may be placed in the Subject Directory
Attributes 
	   extension of a PKC or may be placed in a separate attribute
	   certificate (AC).

	Also, the different occurrences of this extension name use
different capitalizations.

	 Section 4, second para:
	       Authority Clearance
	   Constraints certificate extension in the TA and in each PKC
up to but
	   not including the end PKC in a PKC certification path impact
the
	   effective-clearance.
	
	Section 4, Para after numbered bullet list:
	  Assuming a certification path consisting of n PKCs, the
effective-
	   clearance for the subject of the end PKC is the intersection
of
	   Clearance attribute in the subject PKC, Authority Clearance
	   Constraints, if present, in trust anchor and all Authority
Clearance
	   Constraints present in intermediate PKCs.
	
	These examples clearly defines clearance information in a TA
certificate to be part of the clearance processing. There is no room to
treat this as optional information as is the case for Root extensions in
standard path processing.
	Technically this is not in conflict with RFC 5280 simply because
this draft does not define path validation or any changes to it. It just
defines a new type of certificate content and states the rules for
processing it.
	
	However, I'm a bit concerned that this may cause integration
problems with current RFC 5280 compliant path processing engines and the
APIs used to invoke them. Some implementations may strip all information
but the essential variables from the root certificate but more
seriously, some environments use a mix of extension information and
locally configured parameters to determine the initial state variables
for path processing. A solid practice worth preserving in some cases.
	
	The golden principle for PKI is that the relying party
ultimately decides the initial state variables and determines in the end
if the certificate is valid for their intended use.
	
	I do not suggest any material changes but I'm considering if the
following small adjustments would improve the document.

	1.	Make a clear note that this standard requires processing
of TA information beyond the initial state variables of RFC 5280. 
	2.	Add a section/paragraph about initial state variables
and TA information. In this section state that the default input to the
initial state is any CA clearance extension in the TA certificate of the
path but that this may further be restricted by local policy at the
discretion of the relying party. 
	3.	Following this paragraph/section, only refer to the TA
initial state variables defined above, and not to specific data in the
TA certificate.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Feb 2009 14:39:22 -0500

>Let me know.  If you agree, I will update the draft.

yes, please update the draft and publish it.

Steve