Subject: Re: AW: TAM as a new WG item?

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 7 Dec 2007 15:14:36 +0100

Thomas,

When a trust anchor is being updated, it is because new subordinate certificates will refer to it. 

These new subordinates certificates MAY refer to the new self-signed certificate 
using authorityCertSerialNumber in the AKI extension from the subordinate certificate.

Denis

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

>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?
>
>
>
>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
>
>
>
>
>
>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

Regards,

Denis Pinkas

---

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 10 Dec 2007 12:33:26 +0100

Dave,

>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.

I agree with you. 

>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.

The core of the issue is the following: we already have a protocol 
able to change root keys. We do not need another one.

Do we need something else ? 

My own view is the following:

There would be some value to define one or more syntaxes (ASN.1 and/ or XML ?) 
to define a validation policy and possibly a signature policy. This is a static description, 
not a protocol. There exists many protocols to change files. We may recommend 
which ones to use, but we should not invent a new one, unless there are strong 
arguments to do so.
 
>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".

Fine. We need clear terms on what is being proposed. 
However, we do not have a proposal at this time, only a presentation.

Denis

>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?
>
>
>