Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt (second part)

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 6 Nov 2008 11:26:53 +0100

In order to keep the message short, two answers are given on this document.
 
Comments on draft-ietf-pkix-ta-mgmt-reqs-02
 
Topic: Clarifications needed about associated data, purpose and 
constraints.
 
For most web browsers and Java machines, the current situation is the 
following:
 
   - self-signed certificates are used for all purposes, e.g. TLS server,
     TLS client, sending e-mails, receiving e-mails, applets' signatures,
     and
 
   - it is unknown whether revocation conditions are checked and how.
 
Suppose (for the time being) that we want to move from the current 
situation where self-signed certificates are placed in the same storage and 
hence used for all purposes to a situation where self-signed certificates 
are no more used for any purpose, e.g. used for sending e-mails or used for 
receiving e-mails.
 
There are two possible approaches:
 
   a) consider a given a *purpose*, e.g. applets' signatures, and then 
      list all self-signed certificates that can be used for such a
      purpose, or
 
   b) consider each self-signed certificate and tell for which purpose 
      that self-signed certificate may be used.
 
If we take into consideration the "need-to-know" requirement, some 
applications need to know which self-signed certificates shall be used for 
a given purpose and do not need to know if they are also used for a 
different purpose.
 
The approach a) fulfils this requirement, but not the approach b).
 
When a path validation must be done for a given purpose, case a) is rather 
straightforward: all the information is under the purpose.
 
With case b), this would be more difficult, since the application would 
need to scan every "Trust Anchor" store (?) and look if the given purpose 
is mentioned under a "Trust Anchor".
 
Case a) allows a clear and clean separation of information. However, it 
seems that the document has implicitly chosen case b). :-(
 
It is unclear in the current document what is the relationship between the 
purpose of use of a self-signed certificate that would be placed in TA, the 
"Trust Anchor" itself or the "Trust Anchor Store”.
 
Is one Trust anchor Store usable for some specific purpose(s)? 

Hence is the "purpose" part of the Trust Anchor Store rather than 
the Trust Anchor itself? 

All this needs to be clarified. Once this will be clarified, 
it will be possible to address the kind of operations that should be 
possible on the various objects.
 
==========================================================================
 
In the abstract the text states:
 
   The public key is used to verify digital
   signatures and the *associated data is used to constrain* the types of
   information for which the trust anchor is authoritative.
 
This sentence is confusing since the word "constrain" is kept vague and 
thus does not make the difference between:
 
   1) the intended purpose,
   2) the constraints that are set by the CA and apply for all purposes,
   3) the constraints that are set by the RP.
 
Let us now illustrate case 2): the constraints are included into the self-
signed certificate. The constraints are set by the CA and apply to all 
usages of that self-signed certificate, i.e. all "purposes".
 
Let us now illustrate cases 3): the constraints are external to the self-
signed certificate. The constraints come in addition to those included 
inside the self-signed certificate and are tailored to the specific 
purpose.
 
Case 2) and case 3) may co-exist. 
 
However, the current draft does not make the distinction between case 2) 
and case 3). This is rather fundamental, since a "TA manager" cannot change 
the constraints that are included in a self-signed certificate.
 
============================================================================
 
The document defines a Trust Anchor as : "A trust anchor represents an 
authoritative entity via a public key and associated data". This sentence 
is confusing since the wording "associated data" means everything and thus 
nothing. 
 
This definition is not coherent with RFC 5280 which states on page 76:
 
   " The trust anchor information includes:
 
      (1)  the trusted issuer name,
      (2)  the trusted public key algorithm,
      (3)  the trusted public key, and
      (4)  optionally, the trusted public key parameters associated
           with the public key.
 
The issuer name shall always be present in a trust anchor".
 
The definition of a TA should also make the difference between:
 
   a) the constraints that are set by the CA and apply for all purposes,
   b) the constraints that are set by the RP.
 
Only the later, can be managed when self-signed certificates are used.
Denis

----- Message reçu ----- 
De : owner-ietf-pkix 
À : i-d-announce 
Date : 2008-10-30, 21:45:01
Sujet : I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt

Pièce(s) Jointe(s) au message original :
  (1). draft-ietf-pkix-ta-mgmt-reqs-02.txt

  Title : Trust Anchor Management Requirements
  Author(s) : R. Reddy, C. Wallace
  Filename : draft-ietf-pkix-ta-mgmt-reqs-02.txt
  Pages : 19
  Date : 2008-10-30

A trust anchor represents an authoritative entity via a public key
and associated data. The public key is used to verify digital
signatures and the associated data is used to constrain the types of
information for which the trust anchor is authoritative. A relying
party uses trust anchors to determine if a digitally signed object is
valid by verifying a digital signature using the trust anchor's
public key, and by enforcing the constraints expressed in the
associated data for the trust anchor. This document describes some
of the problems associated with the lack of a standard trust anchor
management mechanism and defines requirements for data formats and
protocols designed to address these problems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-reqs-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 6 Nov 2008 11:24:39 +0100

Topic: automatic root key rollover only using trust anchors initially 
installed.
 
The document states on page 7:
 
   Ideally, only the initial set of trust anchors are installed in 
   a particular trust anchor store should require out-of-band 
   verification, particularly when the costs of performing out-of-band 
   checks commensurate with the security requirements of applications 
   using the trust anchor store are high.
 
It implicitly means that once an initial set of trust anchors is installed, 
the renewal should happen automatically.
 
Unfortunately, this text is only a *statement* within section 2 "Problem 
Statement" rather than a *requirement* within section 3 "Requirements". It 
should be transformed into a requirement with section 3.
 
In practice, we are very close to reach this goal.
 
The CMP protocol allows RPs to pull the information and to automatically 
update trust anchors using the old-by-new self-signed certificate and the 
new-by-new self-signed certificate. There are only two additional questions 
to be answered: 
 
   a) where to fetch these self-signed-certificates ?
   b) when to fetch these self-signed-certificates ? 
 
The answer to the first question is: 
 
   1) add an LDAP address or an HTTP address, or
   2) use an Authority Information Access extension 
      within the self-signed certificate.
 
The answer to the second question is: 
 
   1) add a time period for root key renewal, or
   2) use a private key usage extension within the self-signed certificate.
 
 ... and then we are done when CA issue self-signed certificates, which is 
what *all* CAs are doing today.
 
It does not matter where self-signed certificates are stored, e.g. in 
validation policies or in TA anchors stores (whatever this last term may 
mean).
 
It means that the use of self-signed certificates allows automatic root key 
rollover and to reach the ideal situation mentioned above.
 
A major advantage of this approach is the use of a pull model: the process 
is initiated from the inside of a company and the number of applications 
using that self-signed certificate may be hidden to the outside. Denial of 
service is easier to handle since the first exchange comes from the inside. 
 
These considerations should be taken into consideration in the draft.
 
=======================================================================
 
The document states in section 3.1.: Transport independence
 
   "It MUST work in both session-oriented
   and store-and-forward communications environments as well as in both
   push and pull distribution models".
 
CMP only works in a pull model. With such sentence CMP would be ruled out 
whereas it is already a standard track protocol.
 
The document states in section 3.1.: Transport independence
 
   "connectionless integrity and data origin
   authentication for TA transactions MUST be provided at the
   application layer".
 
With CMP, the security is obtained directly by the self-signed 
certificates, i.e. the data itself which is self-protected. With such 
sentence CMP would be ruled out, whereas it is already a standard track 
protocol.
 
The document cannot say on one side that the pull model is allowed and on 
the other side include requirements which rule out the use of CMP (which is 
based on a pull model).

Denis

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 17 Nov 2008 13:25:23 -0500

inline...

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Denis Pinkas
	Sent: Thursday, November 06, 2008 5:25 AM
	To: ietf-pkix
	Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt

	In order to keep the message short, two answers are given on
this document.

	Topic: automatic root key rollover only using trust anchors
initially 

	installed.

	   Ideally, only the initial set of trust anchors are installed
in 

	   verification, particularly when the costs of performing
out-of-band 

	   checks commensurate with the security requirements of
applications 

	It implicitly means that once an initial set of trust anchors is
installed, 

	Unfortunately, this text is only a *statement* within section 2
"Problem 

	Statement" rather than a *requirement* within section 3
"Requirements". It 

	The CMP protocol allows RPs to pull the information and to
automatically 

	update trust anchors using the old-by-new self-signed
certificate and the 

	new-by-new self-signed certificate. There are only two
additional questions 

	to be answered: 

	   2) use a private key usage extension within the self-signed
certificate.

	 ... and then we are done when CA issue self-signed
certificates, which is 

	It does not matter where self-signed certificates are stored,
e.g. in 

	validation policies or in TA anchors stores (whatever this last
term may 

	mean).

	It means that the use of self-signed certificates allows
automatic root key 

	A major advantage of this approach is the use of a pull model:
the process 

	is initiated from the inside of a company and the number of
applications 

	using that self-signed certificate may be hidden to the outside.
Denial of 

	service is easier to handle since the first exchange comes from
the inside. 

	These considerations should be taken into consideration in the
draft. 

	[CRW] A mechanism based solely on self-signed certificates and
newWithOld/oldWithNew will fail to meet several of the requirements.
Given that auto-renewal could be implemented in terms of existing
requirements, I don't see a need to add it as a separate requirement.  I
don't think we need to enumerate all extensions/associated data in this
draft.

	   and store-and-forward communications environments as well as
in both

	CMP only works in a pull model. With such sentence CMP would be
ruled out 

	

	   application layer".

	certificates, i.e. the data itself which is self-protected. With
such 

	sentence CMP would be ruled out, whereas it is already a
standard track 

	protocol.

	[CRW] CMP fails to meet several of the requirements.  

	The document cannot say on one side that the pull model is
allowed and on 

	the other side include requirements which rule out the use of
CMP (which is 

	based on a pull model).

	Denis

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 17 Nov 2008 13:25:25 -0500

inline...

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Denis Pinkas
	Sent: Thursday, November 06, 2008 5:27 AM
	To: ietf-pkix
	Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt
(second part)

	constraints.

	For most web browsers and Java machines, the current situation
is the 

	following:

	   - self-signed certificates are used for all purposes, e.g.
TLS server,

	     TLS client, sending e-mails, receiving e-mails, applets'
signatures,

	     and

	   - it is unknown whether revocation conditions are checked and
how.

	Suppose (for the time being) that we want to move from the
current 

	situation where self-signed certificates are placed in the same
storage and 

	hence used for all purposes to a situation where self-signed
certificates 

	are no more used for any purpose, e.g. used for sending e-mails
or used for 

	receiving e-mails.

	   a) consider a given a *purpose*, e.g. applets' signatures,
and then 

	      list all self-signed certificates that can be used for
such a

	      purpose, or

	   b) consider each self-signed certificate and tell for which
purpose 

	If we take into consideration the "need-to-know" requirement,
some 

	applications need to know which self-signed certificates shall
be used for 

	a given purpose and do not need to know if they are also used
for a 

	different purpose. 

	The approach a) fulfils this requirement, but not the approach
b).

	When a path validation must be done for a given purpose, case a)
is rather 

	With case b), this would be more difficult, since the
application would 

	need to scan every "Trust Anchor" store (?) and look if the
given purpose 

	Case a) allows a clear and clean separation of information.
However, it 

	[CRW] This document does not choose a) or b).  You are
describing implementation details for how a trust anchor store is
queried.  We're not defining an API for interacting with a trust anchor
store.

	It is unclear in the current document what is the relationship
between the 

	purpose of use of a self-signed certificate that would be placed
in TA, the 

	"Trust Anchor" itself or the "Trust Anchor Store".

	Hence is the "purpose" part of the Trust Anchor Store rather
than 
	the Trust Anchor itself? 

	it will be possible to address the kind of operations that
should be 

	[CRW] The document does not discuss purpose in terms of a trust
anchor store.  One could create and manage a trust anchor store such
that the trust anchor store served a specific purpose.  One could define
an purpose-centric API for interacting with a trust anchor store that
served multiple purposes.  

========================================================================
==

	   signatures and the *associated data is used to constrain* the
types of

	This sentence is confusing since the word "constrain" is kept
vague and 

	   1) the intended purpose,

	   2) the constraints that are set by the CA and apply for all
purposes,

	Let us now illustrate case 2): the constraints are included into
the self-

	signed certificate. The constraints are set by the CA and apply
to all 

	Let us now illustrate cases 3): the constraints are external to
the self-

	signed certificate. The constraints come in addition to those
included 

	inside the self-signed certificate and are tailored to the
specific 

	purpose.

	However, the current draft does not make the distinction between
case 2) 

	and case 3). This is rather fundamental, since a "TA manager"
cannot change 

	[CRW] A "TA manager" cannot change what's included in a
self-signed certificate but it can define additional restrictions or
further restrict the constraints contained in a self-signed certificate.
This is addressed in the subordination processing rules in the TAMP
draft. 

========================================================================
====

	The document defines a Trust Anchor as : "A trust anchor
represents an 

	authoritative entity via a public key and associated data". This
sentence 

	is confusing since the wording "associated data" means
everything and thus 

	nothing. 

	This definition is not coherent with RFC 5280 which states on
page 76:

	      (4)  optionally, the trusted public key parameters
associated

	           with the public key.

	   a) the constraints that are set by the CA and apply for all
purposes,

	Only the later, can be managed when self-signed certificates are
used. 

	[CRW] I think the definition of a trust anchor has been
sufficiently discussed and don't see anything here that warrants a
change.  I recognize the difference with 5280, but TAs have broader use
than just 5280, as noted in the draft. 

	Denis