Hiya, I think this is getting very near the point where we can last call it, but isn't quite there yet. My review below.
Cheers, S. maybe needs thought, defo needs answering: ------------------------------------------ (1) RFC 5878 has a bunch of IPR declarations [1] attached and is not afaik widely implemented (is it at all?). Is re-use of that really a good plan for something ultimately intended to be used for all web servers if that IPR were problematic? Note: in the IETF we don't judge the terms nor applicability of IPR but we do pay attention to what IETF participants say they think about that. In this case, there's no WG, so I'm asking. (Full disclosure: one of the declarations is a 3rd party one I made. [2]) My take is that this might be problematic, but what do others think? [1] https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=5878 [2] https://datatracker.ietf.org/ipr/808/ (2) abstract: "domain owners or their agents" makes it sound like I might have to pay to monitor; be good to re-assure that no such constraint is planned. (Such re-assurance doesn't need to be in the abstract, arguably not even in the draft, but also arguably ought be somewhere.) While its none of the IETF's business who charges for what in general, in this case, where there has been ongoing negative comment on the impact of PKI business models on Internet security, I do think it'd be good for the authors of proposals to be clear how they think they're affecting such charging issues. Personally, I guess that since EFF and some academics have been able to afford to populate large databases of TLS server certs, this shouldn't become a huge barrier, but it could in principle impose new subscription costs or constraints on TLS servers or even clients and that might not be a good plan. (3) Sometimes you say "the log" and other times "logs" I think the term log needs to be used consistently otherwise we may end up being unclear about cardinalities of things later. Suggest adding a specific definition for this term, or invent a term for all logs everywhere. (4) You say you expect "most" public CAs to take part. I think that's a bad thing to say for an experimental RFC and could cause you problems at IETF LC (say if some CA says "this is BS because we're not taking part"). The experiment in any case doesn't need most CAs, just some useful number and you seem to have that. (5) 2.1, better to say sha-256 is hard-coded for now and that that's ok for an experiment - you may well get comment on that since a standards-track RFC would need alg. agility probably. Do *all* logs have to use sha-256 or is it just that all logs have to use one hash alg? Be good to be clear on that too. (6) The precertificate thing needs some more detail at least, e.g. what's "poision" about? (I assume its to prevent such a "pre-cert" be verified anywhere, but then you could also mess with the dates.) Also, saying the precert-signing-cert has to be signed by "the CA cert" private key isn't quite enough. If you mean the same CA cert that's above the TLS server cert then that might not be possible (e.g. with pathLen) albeit that's unlikely, but there could be other reasons why that CA can't issue a CA cert (which the precert-signing-cert is, right?) (7) 3.1, p10, 2nd para: "...chain...to a trusted root..." does that mean that trusted root has to be the CA that issued the topmost cert in the submission to the log, or is any trusted root accepted by the log ok? ("using" the chain might not be considered normative.) (8) 3.1, says the log can accept "not fully valid" things but also says that a "valid chain" is required. That needs clarification I think, since some would consider that a valid chain cannot contain e.g. an expired end-entity cert. (9) 3.1, " However, the log MUST refuse to publish certificates without a valid chain to a known root CA." seems to preclude any solution for self-signed certs or DNSSEC/DANE. Is that a good plan? Maybe if you make it a positive "must accept" then that'd avoid that problem? (If a good solution for SSCs or DANE spam is figured out later.) (10) 3.1, identifying a log solely on the basis of its key_id without any roll-over seems dumb. What if the log wants to roll its signature key? This would have to be fixed in a standards-track RFC but really could be done now and would be better for having being done. (11) various places: I'm not sure you need extensions in all the places you have 'em - if this does become an experimental RFC followed by a standards-track RFC, then that can be handled then. (12) 4.x - would it make sense to use .well-known/ct/ URLs or not? (13) 4.x - how does CT impact on the TLS server cert used for these HTTPS connections? needs fixing, but no thought: ----------------------------- - abstract: the RFC editor doesn't want references in abstracts, just use the RFC number and then put the [] into the body of the text 1st time you refer to each RFC. That might mean you need to repeat stuff from the abstract. (Apparent reason for RFC editor pref is that sometimes people just see the abstract and couldn't follow the reference, feel free to argue with the RFC editor on this about some other document:-) - Where're the OIDs in 3.1 and 3.2 registered? They should be in the some registry I guess. - 3.1, shameless self-promotion - draft-farrell-decade-ni has a way to hash public keys:-) Yes, filling in the TODO is needed. - STH needs to be expanded on 1st use - section 5, 2nd para: gossip TBD needs to be done - ref [1] results in a 404 random comments: ---------------- - abstract: "public end-entity" might not be the best term, maybe the word "web server" is needed since that's the real (inital) concern? - abstract: "accompanied by" seems wrong, "for which an accompanying" would seem better since that log-sig might be found in or out of band. - abstract: s/will be valid indefinitely/are good or bad forever and have no "expiry"/ ? - intro, para1: s/solve the problem/mitigate the problem/ better not to over-claim - intro, para1: what is an "untrusted log"? - intro, para1: s/added/are added/ - intro, para1: s/public TLS/public TLS server/ or are you adderssing client certs too? I don't care assuming it works but you ought be clear. - intro, para 2: ought "required" be 2119 terminology here? Its ok if it is repeated later, but if its not repeated later then it ought IMO be a 2119 term here. - intro, para 2: I'd avoid the word "prove" since mistakes can be made (e.g. a clock might be off) - intro, last para: I think you need to be clear about trusting the log. Clients do need to trust it to be available at least, and if they process a signature then they need to trust it to sign properly and for whatever signature-validity controls. - 2.1: "MTH({d(0)}) = SHA-256(0 || d(0))." The first input to the hash is ASCII '0' (0x30) or a 1-octet number 0 (0x00) or something else? You need to be clear on all those. Be good to say why you chose a 0 for the first but a 1 for others. - 2.1: would it be worth adding "if n is a power of 2 then k=n/2" ? Someone might miss "smaller than" when coding, though I'm not sure their code could work at all in that case, or could it? - 2.1.4: the NIST reference should be a proper reference - 3, 2nd para: saying clients MUST reject without defining client is odd and esp when doing more than audit with CT is optional. The servers MUST there is also odd. I think you want to say "conforming to this spec" in both cases at minimum. - 3, last para, is the MUST there correct use of 2119 language? Formally its not an interop thing but it is a security thing. While I have no issue with that, some other ADs do (mistakenly IMO, but nonetheless it has to be dealt with;-). Reading and closely following the definitions in 2119 might help with that. If, OTOH you want to argue that that's silly then I'm with you on that. - 3.1, 1st para: a list of roots does not "attribute each logged cert to its issuer" - 3.1, not all roots need to make self-signed certs for their root public keys, even though all probably do. Might be better for the language to recognise that. - 3.1, 1st para, s/shall/SHALL/ and maybe s/should/might usefully/ in the same sentence. - 3.1, what's the use-case for a log accepting a cert that has expired? (just curious) - 3.1, the log doesn't "publish" certs does it? - 3.1, why are log entries called "certificate entries"? - 3.1, why "0..." for X509ChainEntry and "1.." for PrecertChainEntry? You probably ought say and that might need to change if you change the "same CA issued both EE cert and precert-signing-cert" rule. - 3.2, it might be a pain to have the string SignedCertificateTimestampList mean two things i.e. both a type and the name of an OCTET STRING field. - 3.2, p13, 1st para, again you say *the* CA. - 3.4, 64 bits for tree size? seems a lot but ok. Is there any way to use a large size there as a DoS by someone on anyone? I've not thought about it, but has anyone? _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey