Add Security Considerations consistent with RFC 3552 #5
Conversation
Signed-off-by: Jon Geater <jon.geater@rkvst.com>
| * TLS client authentication | ||
|
|
||
| Transparency Services MUST provide a configuration surface that | ||
| allows Issuers to specify which authorized clients can submit |
There was a problem hiding this comment.
Should there be a direct correlation between Issuers and Client Auths?
I'm trying to think through the scenarios where this would be required.
There was a problem hiding this comment.
No, I think this should be left to the instance to decide what's right. It's totally legitimate for multiple apps to submit on behalf of the same Issuer, and for a single app to submit Statements signed by many Issuers.
|
|
||
| Replay attacks are not particularly concerning for SCITT or SCRAPI: | ||
| once a statement is made it is intended to be immutable and non- | ||
| repudiable, so making it twice should not lead to any particular |
There was a problem hiding this comment.
A reply attack could be done, that undoes an update:
- An issuer makes a statement, attesting to an artifact has met a set of compliance standards.
{"compliance-2": "true"} - The issuer discovers a vulnerability, making it no longer compliant with the standard:
{"compliance-2": "false"} - A reply attack is made, resetting the compliance:
{"compliance-2": "true"}
There was a problem hiding this comment.
I don't think accumulated state like this is a very good way to use a ledger. Payloads should be complete and make a full statement about whatever they're saying. In your example above the compliance statement should reference which version of the compliance standard was tested against, and what date the assessment was made.
Co-authored-by: A.J. Stein <alexander.stein@nist.gov>
|
I merged the markdown nits, but left the suggestions that should be reviewed by others. |
Co-authored-by: Steve Lasker <stevenlasker@hotmail.com>
Hackathon entry for 119, fill in required elements from RFC 3552