Hiya, On 12/17/2012 06:20 PM, Ben Laurie wrote: > 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.
I wonder if anyone else plans to implement now and could say if they see this as an issue or not? > >> 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. Fair enough. As above, I guess if others don't comment then what you're doing must be ok for now at least. The rest below are fine, Cheers, S. > >> [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
