Responses inline...
From: owner-ietf-trust-anchor@xxxxxxxxxxxxx [mailto:owner-ietf-trust-anchor@xxxxxxxxxxxxx] On Behalf Of Yoav Nir
Sent: Sunday, October 14, 2007 11:20 AM
To: ietf-trust-anchor@xxxxxxxx
Subject: Re: For your consideration: TAMP and CCC
OK. I've finally managed to read this, although not as thoroughly as I would have liked to.
The TAMP protocol described in the draft describes a "cryptographic module" or trust anchor store that has three tiers of trust anchors
- Apex TA - exactly one of those. Has two key pairs. One is only used in the replacement of the Apex TA.
- Mgmt TA - one or more of those
- Identity TA - several of those - they're the regular trust anchors, such as the CA certs in a browser.
[CRW] The number of Mgmt and Identity TAs could vary depending on the purpose of a trust store. Though not really intended by the spec, a trust store could feature just an Apex and be managed using only the Apex-related messages. An instance that requires only Identity TAs could have zero Mgmt TAs (but would still require an Apex). A trust store that supports only a limited number of management operations may have zero Identity TAs.
- The protocol specifies messages used in managing the trust anchor stores.
- The Apex TA represents the ultimate authority (owner of the cryptographic module?) and is used to manage Mgmt TAs, Mgmt TAs are used to manage identity TAs.
[CRW] Additionally, an Apex can be used to manage identity TAs and Mgmt TAs can be used to manage other Mgmt TAs.
- All the messages in the protocol are requests or responses. All requests have responses. Requests must be signed, responses should be.
Problems I see:
1. It's always request-response. the store-and-forward, or email scenario is missing, but it could probably be added.
2. There is no association between identity TA and the Mgmt TA that added it. You can't have an operation like "erase the Mgmt TA and everything it added", which I think is important.
[CRW] It wouldn't be difficult to add an association, but the removal operation could get tricky, particularly if multiple trust anchor managers collaborate on the definition of a particular trust anchor. Maybe an option like you suggest in 4) would cover this well enough, i.e., erase all and use a new list.
3. You can query whether a particular TA is present, but you can't ask for a list of all present TAs.
[CRW] The TAMP Status Query response provides a list of all TAs present in a trust store. The terse response option provides just a list of key identifiers. The verbose option provides full details of the TAs that are installed.
4. You can delete a particular TA, but you can't delete a group or all TAs. You may want this if you want to erase all current TAs and add a new list.
[CRW] You can delete all TAs, but only when replacing the Apex. You can delete groups of TAs with a single response by including multiple elements in the updates field. Aside from the clearTrustAnchors flag in the TAMPApexUpdate message, there is currently no short hand instruction for removing groups of trust anchors.
5. The mandatory Apex TA. I can see cases where the user or owner manually controls the list of Mgmt TAs, and using the protocol just for the Identity TAs.
[CRW] I think you could use one of the manually controlled Mgmt TAs as the Apex then use the protocol for Identity TA management.
That's about what I've seen. Thoughts?