Subject: Re: TAM as a new WG item?

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 7 Dec 2007 12:07:38 +0100

I disagree to support this topic as a new work item within the IETF.

The proposal is not TAM (Trust Anchor Management) as indicated, but TAMP.
This makes a major difference. The "P" means protocol.

There is no need to define new protocols to manage trust anchors.

We have already defined them in RFC 2510 "Certificate Management Protocols" 
in section 3.3.13: 

3.3.13 CA Key Update Announcement content

   When a CA updates its own key pair the following data structure MAY
   be used to announce this event.

  CAKeyUpdAnnContent ::= SEQUENCE {
      oldWithNew          Certificate, -- old pub signed with new priv
      newWithOld          Certificate, -- new pub signed with old priv
      newWithNew          Certificate  -- new pub signed with new priv
  }

However it would be nice to define validation policies, that would be used 
to validate public key certificates for the current time.

ETSI has already defined "signature policies", that may be used to validate 
electronic signatures based on non-repudiation public key certificates either 
for the current time or for a time in the past.

Two ETSI TR have been published:

  - ETSI TR 102 038  : XML format for signature policies 
  - ETSI TR 102 272  : ASN.1 format for signature policies   
 
These documents can be downloaded free of charge from:
http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx

A signature policy is a super set of validation policy. So removing the elements 
that are specific for long term signatures would lead to the definition of a validation policy.

Policies are static. There are not updated. 
When there is a change to be done, a new version needs to be defined. 

Managing validation policies or signature policies simply means adding or removing a policy, 
in a policy store, but never change its content. There are plenty of protocols able to do this and 
there is no need to define a new one.

To conclude, I see the need to define :

 a)  signature policies, and
 b)  validation policies.

Signature policies should be based on the ETSI TR. 
It could simply be an ETSI TR transformed into an informational RFC.

Validation policies should be defined. ETSI TC ESI is in charge of electronic signatures 
and thus this topic would be outside its scope. This work could be done within PKIX and 
should be based on the work from ETSI.

Denis

>At the PKIX meeting this week we hosted a presentation on trust 
>anchor management (TAM).  The presentation described a rich trust 
>anchor (TA) model and a management protocol expressed in an ASN.1 
>syntax.  The model accommodates three types of TAs, and an 
>authorization scheme for managing TAs and other signed objects that 
>might be associated with a crypto module (a hardware or software 
>implementation of crypto capabilities managed by one of more 
>administrative entities). The protocol accommodates both online and 
>offline (staged delivery) management of a module, i.e., it is 
>transport independent and does not require realtime connectivity.
>
>TAM is obviously of interest to PKIX members, as we make use of TAs 
>for cert path discovery and validation. However, TAs can be used in 
>more general contexts as well, e.g., for directly validating 
>signatures on CMS objects. Moreover, the issue of TA management is 
>potentially broader than just the X.509 context, i.e., one could 
>imagine developing a TA model and protocol that deals with other cert 
>types (e.g., PGP) and with public (signature) keys independent of 
>certs.  Despite the important role that TAs play in PKIX-based 
>implementations, the WG has never adopted a work item to develop a 
>model for the management of TAs, nor specified a protocol for remote 
>TA management.
>
>At the 69th IETF meeting there was a BoF to explore creating a new WG 
>to pursue development of a TA model and associated remote management 
>protocol, and a mailing list was established to develop a charter, 
>etc.  Tim Polk has decided that there is not critical mass to create 
>a separate WG for this purpose. However, Tim is willing to have PKIX 
>take on the effort as a new work item. If we do adopt this as a work 
>item, we will focus on TAs primarily in the X.509 context,consistent 
>with the PKIX charter.
>
>At the WG meeting in Vancouver this week I asked the room if there 
>were any objections to PKIX adopting this a work item, given that we 
>have permission from Tim to do so. Two folks voiced objections; both 
>agreed that pursuing TAM was important, but preferred creation of a 
>new WG for the task. However, that option is not on the table at this 
>time and thus is not a subject of the straw poll noted below.
>
>So I am calling for a straw poll in PKIX to gauge interest in pursing 
>this topic. The poll begins today and will end in two weeks, on 
>12/19.  Please examine the presentation slides to get a sense of what 
>work has been done already: 
>http://www3.ietf.org/proceedings/07dec/slides/pkix-2.pdf
>
>Thanks,
>
>Steve
>
>

Regards,

Denis Pinkas

---

From: <[email-masked]>
Date: Fri, 7 Dec 2007 14:01:35 +0100

Get me wrong but...

... the oldWithNew-newWithOld-newWithNew procedure only works, when the AKI is NOT set to issuerSerial in the subordinate certificates, right?

Best regards

Thomas 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Denis Pinkas
Gesendet: Freitag, 7. Dezember 2007 12:08
An: [email-masked]
Betreff: Re: TAM as a new WG item?

 

Denis

Regards,

Denis Pinkas

Atos Origin GmbH, Theodor-Althoff-Str. 47, D-45133 Essen, Postfach 100 123, D-45001 Essen
Telefon: +49 201 4305 0, Fax: +49 201 4305 689095, www.atosorigin.de
ING Bank AG, Frankfurt/Main: Konto 001 014 0937, BLZ 500 210 00, Swift / BIC INGBDEFF, IBAN DE74 5002 1000 0010 1409 37
Geschäftsführer: Wilbert Kieboom, Handelsregister Essen HRB 19354, Ust.-ID.-Nr.: DE147861238

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 7 Dec 2007 12:54:22 -0500

Denis,

The scope of the TAMP draft is larger than that of CMP.  TAM deals with
trust anchors for multiple purposes, e.g. a trust store for validating
software updates separate from the trust store used to validate email
messages.  Although I might want to trust a large number of CAs for
validating email from across the Internet, I wouldn't want to trust all
(or even any) of them to validate new device drivers for my machine.

One of the tasks under this work item could be to ensure maximum
compatibility between TAMP and CMP - that could be done either by
extending RFC 2510 in various dimensions including a multiple trust
store model or by modifying the TAMP draft to incorporate CMP messages.

I don't think accepting this topic as a new work item means "take a
protocol draft written as a BOF starting point and stamp an RFC number
and PKIX approval on it".

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Friday, December 07, 2007 6:08 AM
To: [email-masked]
Subject: Re: TAM as a new WG item?

The proposal is not TAM (Trust Anchor Management) as indicated, but
TAMP.
This makes a major difference. The "P" means protocol.

We have already defined them in RFC 2510 "Certificate Management
Protocols" 
in section 3.3.13: 

However it would be nice to define validation policies, that would be
used 
to validate public key certificates for the current time.

ETSI has already defined "signature policies", that may be used to
validate 
electronic signatures based on non-repudiation public key certificates
either 
for the current time or for a time in the past.

 

A signature policy is a super set of validation policy. So removing the
elements 
that are specific for long term signatures would lead to the definition
of a validation policy.

Managing validation policies or signature policies simply means adding
or removing a policy, 
in a policy store, but never change its content. There are plenty of
protocols able to do this and 
there is no need to define a new one.

Validation policies should be defined. ETSI TC ESI is in charge of
electronic signatures 
and thus this topic would be outside its scope. This work could be done
within PKIX and 
should be based on the work from ETSI.

Denis

Regards,

Denis Pinkas

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Dec 2007 09:29:53 -0500

>This makes a major difference. The "P" means protocol.

The straw poll is correctly phrased.  It is true that the folks who 
briefed us have a candidate protocol to offer as a solution. However, 
if PKIX adopts this work item, we are free to develop whatever 
protocol(s) we see fit to address the requirements that are agreed 
upon.

Since we do not yet have WG agreement on the requirements for TAM, it 
seem premature to suggest that the functions offered by TAMP are not 
needed, and that other, extant protocols can fulfill the 
not-yet-agreed-upon requirements.

Monetheless, the CMP message you cite does not seem to be directly 
relevant to the TAM problem, as it reflects a message exchange 
between a CA and a client. I suspect, based on the discussions that 
have taken place on the TAM list, that the protocol we adopt will not 
assume that the administrative entities dealing with the client to 
manage TAs are necessarily CAs.

The ETSI documents you cite also may not directly address the TAM 
problem, in so far as you cite their use in a non-repudiation 
context, which is probably a narrower scope than what we will 
consider.

Nonetheless, if we adopt the proposed work item, feel free to propose 
solutions that you feel are consistent with the agreed upon problem 
statement, and which make use of existing protocols.  We don't need 
to define a new protocol if we can achieve our goals with extant ones.

Steve