On 17 December 2012 01:54, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > 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?).
We implemented it in OpenSSL. I have patches for Apache. > 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? I do not have a view on whether it is problematic, but would be happy (ish) to propose an extension all of CT's own. > [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. [response in separate email] > > (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. OK, I have gone through the document and cleaned this up. In short, I have referred to "the logs" meaning all of them, and used terms like "a log", "each log" or "a particular log" elsewhere. The actual phrase "the log" still crops up but is hopefully clear from context. > (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. I removed the word "most" :-) > (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. Done. > (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?) Done. > (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.) I think I clarified this in the process of fixing point (6). > (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. This is essentially hedging against operational CA difficulties, so I have clarified that. > (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.) [response in separate email] > (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. [response in separate email] _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
