Re: [Trans] text to address DKG's conspiring CAs attack

On 18/03/16 14:09, Salz, Rich wrote: Steve, I know very well how the existing IETF mechanisms for revocation (i.e. CRL and OCSP) work. But I don't see why that should mean that new revocation mechanisms can't be invented, especially if those new mechanisms can thwart attacks that CRL and OCSP

Re: [Trans] Co-existence of V1 and V2 embedded SCTs in certificates

On 16/03/16 12:22, Eran Messeri wrote: How desirable is it for issuers to be able to embed V1 and V2 SCTs in the same certificate? Eran, thanks for thinking this through. I think that this is definitely desirable, and I like the solution you've proposed. If we don't do this, I think it

Re: [Trans] [trans] #111 (rfc6962-bis): Consider using the cached-info TLS extension

#111: Consider using the cached-info TLS extension Changes (by er...@google.com): * owner: draft-ietf-trans-rfc6962-...@tools.ietf.org => rob.stradl...@comodo.com Comment: Rob, assigning that to you as you originally suggested it. --

Re: [Trans] text to address DKG's conspiring CAs attack

David, I have never believed that "the X.500 directory tree is the basis for all names in certs.," and you know that! your assertion that X.509 requires all name uniqueness across CA boundaries makes sense only in the context of an X.500 DIT world. We had this debate already in the RPKI

Re: [Trans] text to address DKG's conspiring CAs attack

On 16/03/16 17:45, Stephen Kent wrote: Rob, So we (where "we" may or may not be TRANS) need to fix revocation! Revoking an intermediate _certificate_ just isn't sufficient. To be effective, the intermediate _public key_ needs to be revoked somehow. One does not revoke keys in a PKI. One

Re: [Trans] [trans] #118 (rfc6962-bis): Monitor function description problem

#118: Monitor function description problem Changes (by melinda.sh...@gmail.com): * status: new => closed * resolution: => fixed -- --+--- Reporter: k...@bbn.com | Owner: er...@google.com Type: defect|

Re: [Trans] Co-existence of V1 and V2 embedded SCTs in certificates

Agreed, but have in mind that there should be a transition period when RFC 6962-bis is published because it affects the issuance procedure in the CA and not all are quick enough to implement and the processing in the log servers. Iñigo Barreira Responsable del Área técnica

Re: [Trans] [trans] #132 (rfc6962-bis): unclear motivation for and handling of re-logging entries from a frozen log

#132: unclear motivation for and handling of re-logging entries from a frozen log Changes (by melinda.sh...@gmail.com): * status: new => closed * resolution: => fixed -- --+- Reporter: da...@mandelberg.org | Owner:

Re: [Trans] [trans] #141 (rfc6962-bis): expanding audit description

#141: expanding audit description Changes (by er...@google.com): * owner: draft-ietf-trans-rfc6962-...@tools.ietf.org => er...@google.com Comment: From issue #134 which I've just merged to this one: "Section 12 says that TLS clients can use logs and SCTs to reduce the likelihood that

Re: [Trans] text to address DKG's conspiring CAs attack

zBen, On 14 March 2016 at 14:39, Stephen Kent wrote: The logged bogus certificate can be detected by a Monitor (third party or self), that is watching the log(s) to which the certificate was posted. Thus the detection aspect of CT still works with regard to this certificate.

Re: [Trans] [trans] #153 (rfc6962-bis): Finish documenting support for RFC6962 (v1) structures in TransInfo

#153: Finish documenting support for RFC6962 (v1) structures in TransInfo Comment (by er...@google.com): Out for review in https://github.com/google/certificate-transparency- rfcs/pull/135 In short: - Removed all v1 structs because I didn't see a compelling reason to keep them. -

Re: [Trans] text to address DKG's conspiring CAs attack

My notes on several comments in thread: == I want to add to this part: On 15 March 2016 at 09:57, David A. Cooper wrote: > If there is an attack here, it seems that it would be as follows. Upon > detection of the bogus certificate browsers

Re: [Trans] [trans] #131 (rfc6962-bis): missing guidance for TLS servers to select logs

#131: missing guidance for TLS servers to select logs Changes (by melinda.sh...@gmail.com): * status: new => closed * resolution: => fixed -- --+--- Reporter: da...@mandelberg.org | Owner: er...@google.com Type:

Re: [Trans] text to address DKG's conspiring CAs attack

Ben, OK. If you are right, then its pretty clear that any implementation that relies on CRLs/OCSP specified further up the path than the EE cert has a serious problem that has nothing to do with CT. Yes, I am right. But, again, I am puzzled by your comment. In PKIs in general, the revocation

[Trans] revised text for colluding, malicious CAs

- removed the reference to DKG (it will appear in the Acknowledgements section) - used "doppelganger" to refer to the bogus EE cert, trying to avoid the question of whether there are one or two bogus certs - removed reference to X.509 (to make David Cooper happier) -

Re: [Trans] [trans] #118 (rfc6962-bis): Monitor function description problem

Eran, There may be a misunderstanding here: in 6962-bis the Auditor entity was replaced with an auditing role, that different entities (a Monitor being one) can take. I recall when you and your co-authors unilaterally decided that there would be no Auditor as a separate CT element. Both DKG

Re: [Trans] [trans] #155 (rfc6962-bis): Describe how to match SCTs to certificates

#155: Describe how to match SCTs to certificates Changes (by melinda.sh...@gmail.com): * status: new => closed * resolution: => fixed -- --+--- Reporter: er...@google.com | Owner: rob.stradl...@comodo.com

Re: [Trans] text to address DKG's conspiring CAs attack

David, As others have pointed out, the description below is fundamentally flawed, and as a result the conclusion is flawed as well. See comments in-line below. Others are wrong :-). ... In fact, an attack of the sort Gilmor envisioned can be mounted by any two CAs that are not

Re: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd)

Bryan, Thanks for the feedback. I added text to address the concerns you cited about the threat analysis document last year, based on comments you made in the London meeting. I don't recall you mentioning this specific concern at that time or in subsequent messages. Can you refer me to one

Re: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd)

On 16 March 2016 at 18:34, Bryan Ford wrote: > On Mar 16, 2016, at 9:49 AM, Ben Laurie wrote: >> I do agree that these attacks can be mounted, and are in fact already >> discussed in general in 6962 and 6962-bis (s7.3 for the latter). > > I don’t see a

Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers

#145: Section 9.2 (TLS clients) needs more guidance for browsers Changes (by melinda.sh...@gmail.com): * status: new => closed * resolution: => fixed -- --+--- Reporter: k...@bbn.com | Owner: er...@google.com Type:

Re: [Trans] text to address DKG's conspiring CAs attack

On 03/17/2016 11:13 AM, Stephen Kent wrote: David, I have never believed that "the X.500 directory tree is the basis for all names in certs.," and you know that! your assertion that X.509

Re: [Trans] [trans] #132 (rfc6962-bis): unclear motivation for and handling of re-logging entries from a frozen log

#132: unclear motivation for and handling of re-logging entries from a frozen log Changes (by er...@google.com): * owner: draft-ietf-trans-rfc6962-...@tools.ietf.org => m...@google.com * milestone: => review Comment: Melinda/Paul, please review the fix. --

[Trans] [trans] #157 (rfc6962-bis): Conflate Version and TransType

#157: Conflate Version and TransType With TransItem support for v1 (RFC6962) disappearing in ticket #153, it seems that having the type and version as separate fields just seems to complicate matters unnecessarily. So let's conflate the two fields: enum { (0), x509_entry_v2(1),

Re: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd)

I finally had a chance to take a look at the latest version of the threat analysis document. Months ago, I pointed out that the document presents a lopsided view of the potential types of attacks, in general considering only attacks in which CAs or log servers misbehave “in place”, while

Re: [Trans] Co-existence of V1 and V2 embedded SCTs in certificates

Thanks for the feedback, I'll change https://github.com/google/certificate-transparency-rfcs/pull/135 accordingly. (More feedback is still welcome, of course, but I also strongly think it is beneficial). On Wed, Mar 16, 2016 at 1:07 PM, Rob Stradling wrote: > On

Re: [Trans] text to address DKG's conspiring CAs attack

I have never believed that "the X.500 directory tree is the basis for all names in certs.," and you know that! Nor does that have anything to do with what I said in my previous email. There's no reason for you to rebut my analysis. What is needed is

Re: [Trans] [trans] #131 (rfc6962-bis): missing guidance for TLS servers to select logs

#131: missing guidance for TLS servers to select logs Changes (by er...@google.com): * milestone: => review Comment: Landed in https://github.com/google/certificate-transparency- rfcs/commit/f2c1120f8f77461b8d36224ac211eef8257efa33 --