I just got around to reading draft-ietf-trans-rfc6962-bis-03. I have 12
comments.
(1) I believe that the point of this document is to advance the protocol from
experimental to the standards track. However, the Abstract still says that it
is an experimental protocol. Please fix this.
(2) I find the Informal Introduction difficult to follow. It has not changed
since RFC 6962, and I hope that we can be more clear in this document. I had
to read this section more than once to figure out that who the actors are in
this protocol and what they are expected to do.
Here are the points as I understand them...
- Some CAs (Certification Authorities) are issuing certificates that are
surprising to the subject of those certificates.
- Certificate transparency facilitates the detection of such certificates
using publicly auditable, append-only, untrusted logs of all issued
certificates.
- Anyone can provide certificates to the logs, and it is expected that public
CAs will contribute all their newly issued certificates.
- Logs will only accept (unexpired?) certificates that chain back to a trust
anchor in their configuration. Different logs can have a different set of
trust anchors.
- Accepted certificate submissions will get a signed timestamped response as
evidence of the addition to the log.
- Merkle Trees are used to provide the append-only property of each log.
Merkle Trees also help ensure honest operation of the log.
- The logs provide a service to three entities in the overall PKI:
-- The relying party (but only TLS clients are described) get increased
confidence in the peer's certificate if it is in a log.
-- Submitter can used the signed timestamped message to demand a proof of
inclusion in the log.
-- Certificate subjects can check the logs for unexpected certificates,
and if detected take some action that is beyond the scope of this document.
While I understand the reason for declaring the action beyond the scope of the
document, I think that some help can be provided to the reader. Discovery of
an unexpected certificate might lead to (1) work with the CA to get the
unexpected certificate revoked, or (2) work with maintainers of trust anchor
lists to get the CA removed if this is a continual problem.
This exercise helped me to understand the big picture for this protocol. I
hope that the author can use it to make this easier for the next reader.
I was looking at Figure 1 in RFC 5280 and wondering how the entities might be
shown in a similar figure. I'm not sure, but maybe the authors have a figure
in their heads.
(3) Section 2.1 once again call this protocol experimental. Please fix this.
(4) In Section 2.1, this protocol only supports SHA-256. (This is repeated in
Section 3.5) For this protocol to move to the standards track, I would like to
see an algorithm identifier. I have great confidence in SHA-256, but I am sure
that a different hash function will be needed in the distant future. Please
make this transition easy by including the identifier now. We have examples
where the transition away from SHA-1 was much harder because protocol work was
needed to add such an identifier. Please add it now. I think the impact is to
the structure defined in Section 3.3. Further, the digitally-signed structure
from TLS already makes use of a hash algorithm identifier, so it should be no
big deal to use the same identifier here.
(5) In Section 2.1.4, this protocol supports two signature algorithms. I do
not think this raises any algorithm identifier concerns because the
digitally-signed structure from TLS is used. By reusing this structure, you
are accepting the IANA Registry rules for algorithm identifier assignment.
This leads to a question: will this protocol ever need a hash algorithm
identifier or a signature algorithm identifier that is not already registered?
I ask because the rules are strict (because the number of identifiers is not
very big)...
- TLS SignatureAlgorithm Registry:
-- Values in the range 0-63 (decimal) inclusive are assigned via Standards
Action.
-- Values in the range 64-223 (decimal) inclusive are assigned via
Specification Required.
-- Values from 224-255 (decimal) inclusive are reserved for Private Use.
- TLS HashAlgorithm Registry:
-- Values in the range 0-63 (decimal) inclusive are assigned via Standards
Action.
-- Values in the range 64-223 (decimal) inclusive are assigned via
Specification Required.
-- Values from 224-255 (decimal) inclusive are reserved for Private Use.
(6) Since anyone can submit a certificate to the log, one can imagine the same
certificate being submitted from more than one source. It the certificate
added multiple times, or do subsequent submissions get a pointer to the node in
the tree associated with the first submission? Section 3 should answer this
question.
(7) I find the mix of the Precertificate into Section 3.1 a bit confusing. It
says, "The Precertificate is an X.509v3 certificate for simplicity, but, since
it isn't used for anything but logging, could equally be some other data
structure." This standards-track document should say what structure is used,
and not go into the potential for other structures. In fact, the described
"special critical poison extension" only works with X.509v3 certificates.
(8) Section 3.1 says, "Logs MAY limit the length of chain they will accept." I
think they SHOULD do so to protect the log from denial of service attacks.
(9) In Section 3.1 the "certificate_chain" and "precertificate_chain" include
the trust anchor. The submitter must know which trust anchors are supported by
the log, so there does not seem to be value in transmitting it. It is
identified by the issuer field in the next certificate in the chain anyway.
Further, RFC 5280 does not require trust anchors to have self-signed root
certificates.
(10) I do not understand the use of whitespace in Section 4. if I was supposed
to get meaning from this, it did not work.
(11) Section 5.4 talks about an auditor role. I got no hint of such a role in
the Introduction. Please update the introduction so that this role is included.
(12) In Section 6, if you want IANA to point to this document for the
definition of the signed_certificate_timestamp extension instead of RFC 6962,
you should say so here.
Thanks,
Russ
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
