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.
- 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. - 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. 3. You can query whether a particular TA is present, but you can't ask for a list of all present TAs. 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. 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.
That's about what I've seen. Thoughts? On Oct 4, 2007, at 6:35 PM, Russ Housley wrote:
The Trust Anchor Management Protocol (TAMP) specification has been submitted for your consideration. The draft was developed primarily to support trust anchor management for cryptographic modules with an assumption that the module would manage a single trust anchor store. As such, there are some aspects of the specification that are out of alignment with the direction that this group seems to be taking. Specific items that are likely to change include the following:- Throughout the draft, the term "cryptographic module" can often be read as "trust anchor store". If I understand the direction of the group, then a focus on the trust anchor store is more appropriate.- Messages are targeted using hardware-centric names. I think this approach is one that ought to be supported, but there are probably others. At a minimum we should consider multiple trust anchor stores on the same device.- The mail list has discussed trust anchor types, but this draft defines a structure for trust anchors that are used in the validation of X.509 certification paths and signatures on CMS objects that are directly signed by the trust anchor. At a minimum, I think that it is important to add a hook for other trust anchor types.Additionally, some changes are planned for the section that describes the processing of TAMPUpdate messages. Additional language describing path processing in support of TAMP update processing will be added and the CertPathControls feature will be subject to subordination rules.The TAMP draft is accompanied by another draft: Cryptographic Message Syntax (CMS) Content Constraints X.509 Certificate Extension (CCC). The CCC draft defines a certificate extension to handle delegation of privileges expressed in TAMP via the TrustAnchorUsage type. This certificate extension is used to determine whether the public key in an X.509 public key certificate is appropriate to use in the processing of a CMS-protected content.The drafts are available at these locations: http ://www.ietf.org/internet-drafts/draft-housley-tamp-00.txthttp://www.ietf.org/internet-drafts/draft-housley-cms-content- constraints-extn-00.txt
smime.p7s
Description: S/MIME cryptographic signature
