[Trans] Comments on draft-ietf-trans-rfc6962-bis-03

[Russ Housley <[e-mail]>]

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