First version with passport model added. #175
Conversation
hannestschofenig
requested review from
ounsworth,
nedmsmith,
henkbirkholz and
mwiseman-byid
There was a problem hiding this comment.
Ok, so you are defining a second pair of extensions / attributes for id-aa-ar that are basically the same but without the layer that allows bundles and certs. ARs must be signed, right? Is that true that ARs never need an external certificate chain? I understand that you don't need a SEQUENCE OF AR, but should there be a SEQUENCE OF CertificateChoices ?
I did not read all the new text, but I skimmed it and it seems good.
Co-authored-by: Mike Ounsworth <mike@ounsworth.ca>
Co-authored-by: Mike Ounsworth <mike@ounsworth.ca>
|
Two points in response, Mike:
|
| |<-----------------| | ||
| | | | ||
| ~~~ | ||
| {: #fig-csr-client-p11 title="Example interaction between CSR generator and HSM."} |
There was a problem hiding this comment.
I think its confusing for a crypto lib to have getEvidence calls. This dissonance is easier to see if you also have a diagram for getAttestationResultToken(). Both the AR token and Evidence are already signed (by Verifier / Attesting Env respectively) so there isn't a crypto operation needed to fetch them.
|
|
||
| Typically, the RPs considered in the RATS architecture are application services that use remote attestation, rather than RAs or CAs. Devices inherently place significant trust in RA/CA infrastructure elements, and therefore any additional information revealed through remote attestation to such entities is generally less concerning than disclosure to application services. The problem of copying Evidence by CAs into an X.509 certificate is discussed in {{sec-con-publishing-x509}}. | ||
|
|
||
| These privacy risks can be mitigated using several approaches, including: |
There was a problem hiding this comment.
Differential privacy analysis may be applied to Evidence, Attestation Results, or Certificates to reveal personally identifiable information that may be used to track a user or to correlate user's transactions.
There was a problem hiding this comment.
There is a lot that could be done but I did not want to provide an exhaustive list
draft-ietf-lamps-csr-attestation.md
Outdated
| A PKCS#10 or CRMF Certification Request message typically consists of a | ||
| distinguished name, a public key, and optionally a set of attributes, | ||
| collectively signed by the entity requesting certification. | ||
| collectively signed by the end entity requesting certification. |
There was a problem hiding this comment.
I don't think certification requests are limited to end entities. SPDM and DICE device ID certs can be embedded CAs.
There was a problem hiding this comment.
Fair enough. I will change this text.
Co-authored-by: Ned Smith <ned.smith@intel.com>
Co-authored-by: Ned Smith <ned.smith@intel.com>
Co-authored-by: Ned Smith <ned.smith@intel.com>
Co-authored-by: Ned Smith <ned.smith@intel.com>
Co-authored-by: Ned Smith <ned.smith@intel.com>
Co-authored-by: Ned Smith <ned.smith@intel.com>
Co-authored-by: Ned Smith <ned.smith@intel.com>
In this PR, I have added the long-awaited support for the passport model to the CSR attestation draft. While the functionality was implicitly present through the use of the conceptual message wrapper, the text previously lacked any explicit explanation.
I understand that introducing this functionality at this stage may seem late. However, I strongly believe we should not publish the draft without it, as there is significant industry interest in supporting both models: the background-check model and the passport model.