[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: TAM as a new WG item?
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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] Im Auftrag von Denis Pinkas
>Gesendet: Freitag, 7. Dezember 2007 12:08
>An: ietf-pkix@xxxxxxx
>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