On Wed, Nov 30, 2011 at 5:16 PM, Marsh Ray <ma...@extendedsubset.com> wrote: > On 11/30/2011 05:24 AM, Ben Laurie wrote: >> >> On Wed, Nov 30, 2011 at 1:18 AM, Marsh Ray<ma...@extendedsubset.com> >> wrote: >>> >>> Perhaps the relevant property is "certs issued by a browser-trusted >>> CA or subordinate" regardless of their visibility. >> >> If they are not visible, why would we care whether they are in the >> log or not? > > I guess I don't understand what you mean by 'publicly visible certs' in > the sentence: >> >> Firstly, every publicly visible certificate should be published in a >> publicly auditable certificate log. > > Perhaps you define this category of "publicly visible certs" as "certs > which display without warnings on default-configured browsers when > presented by the correct site". > > Which today is the same set as "certs issued by a browser-trusted CA or > sub-CA" and this set makes up the great majority of secure sites people > visit. Server operators generally don't buy certs from CAs for any > reason other than to ensure their site will display without cert errors > in default-configured browsers. (Of course they may have a deeper > appreciation for the security model as a whole). > > So it basically amounts to "all certs that a default-configured browser > should accept" which is approximately "all certs issued by > browser-trusted CAs or sub-CAs today", i.e. "valid certs". > > On the other hand, one could interpret this category of "publicly > visible certs" as "certs visible to the public", i.e., "certs served by > legitimate servers on routable IPs located via public DNS". But this > interpretation would be much weaker (and I don't think that's what you > mean).
Although I rather like your first definition, this one seems closer to the truth: it may be that some sites which currently validate correctly in default-configured browsers would choose not to in our system. However, for this second class the certs are already public, and so there does not seem a reason to choose not to participate, at least on visibility grounds. > Do I have this right? > >> CAs do not need to sign up to the plan. > > The title of the email is "Auditable CAs", so I started with the > impression that some part of this plan involved auditing as a property > of the CA itself. But this doesn't seem to be the right interpretation. No. > The goal is said to "make it impossible (or at least very difficult) for > a Certificate Authority (CA) to issue a certificate for a domain without > the knowledge of the owner of that domain" and "each certificate issued > must be accompanied by an audit proof". > > But the proposal does nothing _directly_ to prevent a CA from issuing a > cert, right? And since browsers aren't logging the certs as they find > them, this doesn't inform the owner of the domain either. > > Instead it seems to be a hoped-for effect of "default-configured > browsers will raise hell if they are presented with a non-logged cert > and CAs will feel compelled to go along with the audit logging". CAs do not have to go along with anything, the log will accept a cert from anyone - which obviously includes the owner of the cert. >> What do you mean by "auditing of sub-CAs"? > > If sub-CA-issued certs are to continue to display without warnings by > default-configured browsers, then they'll have to put the certs they > issue in the logs too, right? Someone will, yes. >>> The maybe-impossible problem to solve is that this explicitly >>> public audit log now represents a major information leak from the >>> company that's very concerned about its security. >> >> What information does it leak that is not already leaked? > > Wouldn't they have to put the certs they sign in the public log? They > don't have to do this today. No, but their certs are already publicly visible today. >> Internal certs are not a problem, as mentioned in the paper. > > It would probably be worth describing how internal logs for internal CAs > would work. It could be rather simple, like the audit proof identifies > the specific log in a manner that makes it straightforward to publish > via an internal network. The obvious way to do it is to allow the setting of an alternate log location in a CA cert installed into the trust store. Logs could also be separately configured. > I am liking this plan. Thankyou. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
