[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TAM as a new WG item?
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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
>On Behalf Of Denis Pinkas
>Sent: Friday, December 07, 2007 6:08 AM
>To: ietf-pkix@xxxxxxx
>Subject: 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