Re: TAM as a new WG item?

["Denis Pinkas" <denis.pinkas@xxxxxxxx>]

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