Skip to content
This repository has been archived by the owner on Nov 10, 2022. It is now read-only.

Explain how to ensure effective redaction #178

Closed
wants to merge 4 commits into from

Conversation

robstradling
Copy link
Contributor

(and how to avoid futile redaction)

(and how to avoid futile redaction)
@AGWA
Copy link
Contributor

AGWA commented Jul 12, 2016

👍

@robstradling
Copy link
Contributor Author

@eranmes @AGWA Would it make sense to move this to the Security Considerations section?

@AGWA
Copy link
Contributor

AGWA commented Jul 12, 2016

@robstradling I don't like the implication that redaction is a security mechanism. It could be a Privacy Consideration, although it also seems fine where it is currently.

</list>
</t>
<t>
CAs SHOULD carefully consider each request to redact a label. When a CA believes that redacting a particular label would be futile, the CA SHOULD NOT redact it. TLS clients may have policies that forbid redaction, so redaction should only be used when it's absolutely necessary and likely to be effective.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/SHOULD/should/g, as it's not a part of the protocol, but a recommendation for CAs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto for "it is RECOMMENDED that domain owners", I suppose.

@eranmes
Copy link
Contributor

eranmes commented Jul 13, 2016

I agree with Rob it'd make sense to move it to another section, probably the Security Considerations section (which could be renamed Security & Privacy considerations). Since this text does not prescribe specific behaviour of a party in the protocol, it shouldn't be among the technical details of how to do redaction (it may go unnoticed there).

@robstradling
Copy link
Contributor Author

@eranmes PTAL

@eranmes
Copy link
Contributor

eranmes commented Jul 14, 2016

LGTM, please squash before merging (you can now do that with the green button).

@eranmes eranmes added the LGTM label Jul 14, 2016
@robstradling
Copy link
Contributor Author

Merged at 3068171

@robstradling robstradling deleted the redaction_caveats branch July 15, 2016 09:06
bifurcation added a commit to bifurcation/certificate-transparency-rfcs that referenced this pull request Mar 17, 2017
Issue google#176 - Remove `X509ChainEntry` and `PrecertChainEntryV2`
Issue google#177 - Instructions for constructing leaf hash from cert + SCT
Issue google#178 - Add description of how to validate an SCT
Issue google#179 - Indicate certificate / precertificate in Entry and SCT
bifurcation added a commit to bifurcation/certificate-transparency-rfcs that referenced this pull request Apr 3, 2017
…+ SCT

Also covers Issue google#178 - Add description of how to validate an SCT

Note: This branch is on top of 179-indicate-precert-in-sct, so that branch
should be merged first.
eranmes added a commit to eranmes/certificate-transparency-rfcs that referenced this pull request May 12, 2017
Detail the TransItem that has to be constructed as the input to the
signature validation phase, when validating SCTs.
eranmes added a commit to eranmes/certificate-transparency-rfcs that referenced this pull request Jun 15, 2017
Detail the TransItem that has to be constructed as the input to the
signature validation phase, when validating SCTs.
robstradling pushed a commit that referenced this pull request Jun 16, 2017
Detail the TransItem that has to be constructed as the input to the
signature validation phase, when validating SCTs.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
3 participants