try to remove ambiguity about TAs nature as endorsements

$subject + update CoSWID ref

Fix #3

draft-ietf-rats-concise-ta-stores.md

@@ -34,7 +34,7 @@ author:
 normative:
   I-D.draft-ietf-rats-corim:
   I-D.draft-ietf-rats-eat: EAT
-  I-D.draft-ietf-sacm-coswid:
+  RFC9393:
   RFC5280:
   RFC5914:
   RFC8949: CBOR
@@ -74,9 +74,9 @@ Trust anchor (TA) stores may be used for several purposes in the Remote Attestat
 
 The RATS architecture {{RFC9334}} uses the definition of a trust anchor from {{RFC6024}}: "A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative." In the context of RATS, a trust anchor may be a public key or a symmetric key. This document focuses on trust anchors that are represented as public keys.
 
-The Concise Reference Integrity Manifest (CoRIM) {{I-D.draft-ietf-rats-corim}} specification defines a binary encoding for reference values using the Concise Binary Object Representation (CBOR) {{RFC8949}}. Amongst other information, a CoRIM may include key material for use in verifying evidence from an attesting environment (see section 3.11 in {{I-D.draft-ietf-rats-corim}}). The extension in this document aims to enable public key material to be decoupled from reference data for several reasons, described below.
+The Concise Reference Integrity Manifest (CoRIM) {{I-D.draft-ietf-rats-corim}} specification defines a binary encoding for reference values and endorsmenents using the Concise Binary Object Representation (CBOR) {{RFC8949}}. Amongst other information, a CoRIM may include key material for use in verifying evidence from an attesting environment (see {{Section 3.1.4.4 and 3.1.4.5 of I-D.draft-ietf-rats-corim}}). The extension in this document aims to enable public key material to be decoupled from reference data and other kinds of endorsement data for several reasons, described below.
 
-Trust anchor (TA) and certification authority (CA) public keys may be less dynamic than the reference data that comprises much of a reference integrity manifest (RIM). For example, TA and CA lifetimes are typically fairly long while software versions change frequently. Conveying keys less frequently and indepedent from reference data enables a reduction in size of RIMs used to convey dynamic information and may result in a reduction in the size of aggregated data transferred to a verifier.  CoRIMs themselves are signed and some means of conveying CoRIM verification keys is required, though ultimately some out-of-band mechanism is required at least for bootstrapping purposes. Relying parties may verify attestations from both hardware and software sources and some trust anchors may be used to verify attestations from both hardware and software sources, as well. The verification information included in a CoRIM optionally includes a trust anchor, leaving trust anchor management to other mechanisms. Additionally, the CoRIM verification-map structure is tied to CoMIDs, leaving no simple means to convey verification information for CoSWIDs {{I-D.draft-ietf-sacm-coswid}}.
+Trust anchor (TA) and certification authority (CA) public keys may be less dynamic than the reference data that comprises much of a reference integrity manifest (RIM). For example, TA and CA lifetimes are typically fairly long while software versions change frequently. Conveying keys less frequently and indepedent from reference data enables a reduction in size of RIMs used to convey dynamic information and may result in a reduction in the size of aggregated data transferred to a verifier.  CoRIMs themselves are signed and some means of conveying CoRIM verification keys is required, though ultimately some out-of-band mechanism is required at least for bootstrapping purposes. Relying parties may verify attestations from both hardware and software sources and some trust anchors may be used to verify attestations from both hardware and software sources, as well. The verification information included in a CoRIM optionally includes a trust anchor, leaving trust anchor management to other mechanisms. Additionally, the CoRIM verification-map structure is tied to CoMIDs, leaving no simple means to convey verification information for CoSWIDs {{RFC9393}}.
 
 This document defines means to decouple TAs and CAs from reference data and adds support for constraining the use of trust anchors, chiefly by limiting the environments to which a set of trust anchors is applicable. This constraints mechanism is similar to that in [fido-metadata] and [fido-service] and should align with existing attestation verification practices that tend to use per-vendor trust anchors. TA store instances may be further constrained using coarse-grained purpose values or a set of finer-grained permitted or excluded claims. The trust anchor formats supported by this draft allow for per-trust anchor constraints, if desired. Conveyance of trust anchors is the primary goal, CA certificates may optionally be included for convenience.
 
@@ -273,7 +273,7 @@ As defined in {{I-D.draft-ietf-rats-corim}}, an `envirionment-map` may contain `
 
 ### The `abbreviated-swid-tag-map` Container
 
-The `abbreviated-swid-tag-map` allows for expression of fields from a `concise-swid-tag` {{I-D.draft-ietf-sacm-coswid}} with all fields except entity designated as optional, compared to the `concise-swid-tag` definition that requires `tag-id`, `tag-version` and `software-name` to be present.
+The `abbreviated-swid-tag-map` allows for expression of fields from a `concise-swid-tag` {{RFC9393}} with all fields except entity designated as optional, compared to the `concise-swid-tag` definition that requires `tag-id`, `tag-version` and `software-name` to be present.
 
 ~~~~~~
 abbreviated-swid-tag-map = {