Daniel Migault's editorial feedback #80
Comments
|
This comment is better addressed by @hannestschofenig or @henkbirkholz who is more familiar with the security and privacy considerations of RATS.
|
|
7.1
This could use a strong statement that freshness MAY be contained inside the embedded Evidence, or it may be carried in the certificate management protocol that is carrying this CSR, but freshness is out-of-scope for the CSR itself, which is the focus of this document. |
|
@daniel Migault
I vote against this. This section is meant to be examples / informative. I think that if we try to make this section normative, then we will get into trouble. In general, we are providing containers and want to leave room for an Attester and Verifier from the same vendor to use these structures however they want. In particular, if we say anything about mandatory certificate order, then we make it hard for cases where we want to include multiple cert chains, or multiple partial cert chains in a single EvidenceBundle. We decided at a meeting that things like P12 files already require certificate parsing clients to be able to handle bags of certificates in arbitrary order that may contain extra certs not needed for a specific Leaf -> CA path, so it is fair to also expect this of Verifiers. If a given vendor's Verifier cannot do this, then they should construct their Evidence accordingly, but I do not think that the specification should arbitrarily restrict those of us with proper certificate path building logic :) Similar reasoning for whether the Root should be placed or not. For example, in complex cross-certified or bridged PKIs it is possible that a self-signed root certificate is not in your trust store, but it is cross-signed as a subordinate of a root that is. So in that case the Attester would need to include the root cert in the EvidenceBundle. I think that making any restrictions here on what may be in the certificate list will make it impossible to transmit certain complex PKIs, only for the benefit of simple PKIs that do not implement 5280 path-building properly :) |
|
On Daniel's final point about freshness. I think we discussed this during the meeting on 2024-01-29. This draft is just an envelope; it is just a carrier for existing Evidence formats. We have tried to say, in general terms, that freshness is good, but that it may not always be possible, and regardless, it is outside the scope of this draft. I am open to alternate wording, if you want to propose something. |
|
All merged in #81 |
Hi,
Please find my review of the document. Mostly hints except for freshness that I think we need to require or recommend a bit stronger.
Yours,
Daniel
2 Intro:
"""
At the time of writing, several standard and several proprietary attestation technologies are in use. This specification thereby is intended to be as technology-agnostic as it is feasible with respect to implemented remote attestation technologies. Instead, it focuses on (1) the conveyance of Evidence via CSRs while making minimal assumptions about content or format of the transported Evidence and (2) the conveyance of sets of certificates used for validation of Evidence. The certificates typically contain one or more certification paths rooted in a device manufacture trust anchor and the leaf certificate being on the device in question; the latter is the Attestation Key that signs the Evidence statement.
"""
I would probably add at the end of the paragraph:
Evidences are carried in a Attribute designated as EvidenceStatements, certificates are carried in a CertificateAlternatives. EvidenceStatements and CertificateAlternatives are grouped into EvidenceBundles.
"""
This document specifies two ATTRIBUTE/Attribute definitions.
""
We do not really know if one is designated ATTRIBUTE while the other Attribute or if some call these two attributes ATTRIBUTES while other call them Attributes.
In my opinion, it would be clearer to name directly the Attributes CertificateAlternatives EvidenceStatements.
I would propose the following text:
This document specifies two Attributes. The first Attribute is CertificateAlternatives that may be used to carry a set of certificates or public keys that may be required to validate signed Evidence. The second Attribute is EvidenceStatements that carries a structure that may be used to convey Evidence. These two Attributes combined into a
"""
With these attributes, additional information about whether to issue a certificate and what information to populate into the certificate is available to an RA or CA.
"""
I am reading that the content of the evidence will determine the information of in the issued certificate. I THINK these Evidence will determine the issuance of the certificate if they are matching a policy and information provided is determined by policies. In my my opinion we should limit the scope to the policy.
The scope of this document is, however, limited to the conveyance of Evidence within CSR. The exact format of the Evidence being conveyed is defined in various standard and proprietary specifications.
3 Architecture
I tend to think we should indicate the CA/RA on the figure, potentially the HSM.4.1 Intercation with an HSM
"""
As discussed in RFC 9334, different security and privacy aspects need to be considered.
"""
I think we should say why. I would for example add:
As discussed in RFC 9334, different security and privacy aspects need to be considered to enforce trust in the Evidence.
"""
Finally, the keying material used by the Attester need to be protected against unauthorized access, and against signing arbitrary content that originated from outside the device.
"""
To me that seems to be the primary thing to be listed ;-)
Fig 2 I like OpenSSL and I think it should remain but probably as an example.
"""
the generates and embeds Evidence and the corresponding certificate chains when constructing the CSR.
"""
I suspect "HSM" is missing I propose:
The HSM generates and embeds....
Fig 2: I think HSM here is composed of the attestation environment and the service. getEvidence is addressed to the platform sign to the service. I am wondering if we should split these two. Note that I see the service as "Software" so maybe I am biassed.
"""
Externally-generated CSRs may require extra round-trips of communication between the CSR generator and the attesting environment, first to obtain the necessary evidence statements about the subject key, and then to use the subject key to sign the CSR. For example, consider a CSR generated by a popular crypto library about a subject key stored on a PKCS#11 [PKCS11] device.
"""
Should we replace "evidence statements" by Evidence ? I do not think that popular is necessary, mentioning "(like OpenSSL): might be helpful. I know it used to be on the figure.
4.2. Implementation Strategies
Fig 3 : the meaning of 0,n are bit enigmatic to me. In particular I am wondering if inverting 0 and n would change the meaning. I interpret it as meaning between 0 - n. If that is the case, the text mentions one to many, so maybe that needs some clarifications.
Maybe we could mention that CertificateAlternatives represents various format of certificates I propose to complement the last sentence of the paragraph to:
Each EvidenceBundle contains one or multiple EvidenceStatement structures as well as one or many CertificateAlternatives which enable to carry various format of certificates.
"""
Single Attester, which only distributes Evidence without any certificate chains, i.e. the Verifier is assumed to be in possession of the certificate chain already or there is no certificate chain.
"""
I think what the last sentence is saying is the say the statements are not signed.
If so, "or there is no certificate chain." should be replaced by "or statements ar enot signed."
"""
It may be possible that there is an overlap in the certificate chains transmitted by the different Attesters.
"""
I think we can be more specific and say:
This may result in certificates being duplicated across multiple EvidenceBundles.
Implementation strategies to order certificates are only useful if they can be used, so I suspect we should provide some requirements such as the strategies described here MUST be supported and Certificates MUST be ordered from leaf to top. We should also specify whether the root CA needs to be placed probably a SHOULD NOT or MUST NOT. A verifier SHOULD NOT make any assumption....
5.2 Evidence Attribute and Extension
"""
The hint is intended for an Attester to indicate to the Relying Party which Verifier should be invoked to parse this statement.
"""
We need to specify that RP will designate later the Relaying party. I propose to change "Relying Party" to "Relying Party (RP)"
"""
In many cases, the type OID will already uniquely indicate which Verifier to invoke, but in some cases it may still be ambiguous, or the type may indicate another layer of conceptual message wrapping in which case it is helpful to the RP to bring this hint outside of the statement.
"""
I think we need to explicitly mention why the OID will indicate the Verifier. I suspect the reasoning is that OID will be vendor specific and Verifier will be vendor specific as well. I expect that verifier will be also configured by the client and as such who will send the CSR but such authentication will be made outside the scope of the CSR.
I understand that hint indicates the Verifier. Do we expect the hint to be something like a FQDN ?
One thing one need to consider is that I have the impression the hint cannot be trusted unless the CSR is generated by the attesting environment. If that is correct, we probably need to be cautious regarding that hint and mention it in the security considerations.
I do not clearly see what id-ata represents. I have the impression this is the arc under which all Evidence Statement will be registered. id-ata.1, id-ata.2, ... will represent evidence statements. This specific evidence statements are represented by the EvidenceStatementSet structure.
I am reading that id-aa-evidenceStatement represents EvidenceBundles. If so I am wondering why do not we call it id-aa-evidenceBundles.
The following text is quite obscure to me:
"""
We are leaving the SEQUENCE OF EvidenceBundle since it is in general more flexible than relying on the containing structure to handle multiplicity and allows for this structure to be re-used in the future in other PKIX protocol contexts.
"""
7: Security Consideration
"""
A PKCS#10 or CRMF Certification Request message consists of a distinguished name, a public key, and optionally a set of attributes, collectively signed by the entity requesting certification.
"""
Well with DN being the certificate Subject I think it can be empty. I woudl propose to replace distinguished name by an identity or identifier.
"""
The private key used to sign the CSR MUST be different from the Attesting Key utilized to sign Evidence about the Target Environment.
"""
This seems correct - at least in general -, but I am questioning we never never never have a case where a root CA requests a CSR...
"""
Key separation is an important principle in cryptography and also applies to this specification with regards to the Attestation Key and the CSR signing key.
"""
I do not really understand the sentence, CSR the key is signing the CSR prove the ownership of the key for which a certificate is issued. Evidences are signed to authenticate thetrust of the evidences. I guess I am missing something here.
"""
For example, one implementation may perform a software measurement of the CSR library along with the crypto library implementation that has access to the keying material.
"""
I am reading software measurement as the CSR being a target environment.
If the CSR library is outside the attesting environment, it is unclear to me how it can be attested unless we are in a multi attester use case.
"""
None of these things are practical when interacting with Hardware Security Modules (HSM).
"""
I think I disagree here and we need to have freshness or at least some lifetime for Evidences. TLS or ACME are ways to provide a nonce that needs to be considered during the attestation. We should strongly recommend to implement freshness. It is correct that freshness can be implemented in various ways, including a simple serial number. The threat model seems simple, the key is generated on a HSM, the crypto becomes weak, I can generate the key on my raspberry pie, the CSR can be used for that key - while all certificate have expired. CSR are not necessarily encrypted.
The text was updated successfully, but these errors were encountered: