Issue #178: Describe how to validate an SCT #259
Conversation
draft-ietf-trans-rfc6962-bis.md
Outdated
| * `timestamp` is copied from the SCT. | ||
| * `tbs_certificate` is the TBSCertificate portion of the server certificate. | ||
| * `issuer_key_hash` is extracted from certificate in the chain that certified | ||
| the server certificate. |
There was a problem hiding this comment.
Is a "the" missing in the "issuer_key_hash" description?
* `issuer_key_hash` is extracted from the certificate in the chain that certified the server certificate.
draft-ietf-trans-rfc6962-bis.md
Outdated
| structure is constructed in the following manner: | ||
|
|
||
| * `timestamp` is copied from the SCT. | ||
| * `tbs_certificate` is the TBSCertificate portion of the server certificate. |
There was a problem hiding this comment.
Shouldn't this link to the "Reconstructing the TBSCertificate" section?
"is the TBSCertificate portion of the server certificate" is too simplistic. Embedded SCTs need to be removed too.
draft-ietf-trans-rfc6962-bis.md
Outdated
| * `timestamp` is copied from the SCT. | ||
| * `tbs_certificate` is the TBSCertificate portion of the server certificate. | ||
| * `issuer_key_hash` is extracted from the certificate in the chain that | ||
| certified the server certificate. |
There was a problem hiding this comment.
"extracted" seems to suggest that the issuer_key_hash field is actually present in the issuer certificate, when in fact it needs to be computed from the public key in the issuer certificate.
How about simplifying this sentence to...
"issuer_key_hash" is computed as described in section 4.5
?
draft-ietf-trans-rfc6962-bis.md
Outdated
| certified the server certificate. | ||
| * `sct_extensions` is copied from the SCT. | ||
|
|
||
| The signature (from the SCT's `signature` field) is then verified using the |
There was a problem hiding this comment.
Could be shortened to:
The SCT's "signature" is then verified using..."
draft-ietf-trans-rfc6962-bis.md
Outdated
| * `sct_extensions` is copied from the SCT. | ||
|
|
||
| The signature (from the SCT's `signature` field) is then verified using the | ||
| corresponding log's public key (identified by the `log_id` field). |
There was a problem hiding this comment.
"log_id" doesn't identify the log's public key, per se. Rather, it identifies the log.
Also, we should mention that the signature algorithm is one of the log's parameters.
Something like this:
The SCT's "signature" is then verified using the public key of the corresponding log, which is identified by the "log_id". The required signature algorithm is one of the log's parameters."
There was a problem hiding this comment.
Done (though I'd have left it saying "using the corresponding log's public key, which is...")
|
@robstradling PTAL |
draft-ietf-trans-rfc6962-bis.md
Outdated
| * `timestamp` is copied from the SCT. | ||
| * `tbs_certificate` is the reconstructed TBSCertificate portion of the server | ||
| certificate, as described in {{reconstructing_tbscertificate}}. | ||
| * `issuer_key_hash` is is computed as described in {{tree_leaves}}. |
Detail the TransItem that has to be constructed as the input to the signature validation phase, when validating SCTs.
eranmes
force-pushed
the
issue_178_validating_scts
branch
from
87cacad
to
e72e437
Compare
|
@robstradling PTAL. |
Detail the TransItem that has to be constructed as the input to the
signature validation phase, when validating SCTs.