On 17 March 2016 at 15:00, Stephen Kent <[email protected]> wrote: > 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 > status of an EE cert is specified by the CA that issued the cert. (There are > provisions > for indirect CRLs, but that's not a commonly used mechanism). RFC 5280 > recognizes that there > can be vulnerabilities associated with acquiring CRLs or OCSP data in some > contexts, and > that's why AIA allows a CA to tell RPs where to acquire such data. However, > for backward > compatibility purposes, and because this is not a problem in all contexts, > 5280 does not > mandate use of this extension. Thus one ought not assume that it is always > present, > and it is appropriate to acknowledge this residual vulnerability where > applicable.
I am struggling to imagine a context in which this is not a problem. But maybe there is one. > Note, that the RPKI does mandate use of AIA to point to CRLs, and relying > parties > in that context are required to verify that the extension is present,. If > it's missing > the cert (EE or CA) is rejected. > > The CT related problem is that people could perhaps be fooled into > thinking it was not necessary to revoke some logged bogus certificates > because they appear to come from a chain that was not trusted anyway. > > True. Also, a browser vendor might decide that it didn't need to blacklist > the > EE cert because it had already been revoked by the CA. I think that would depend on the EE cert (i.e. does it include the AIAs needed?). > Don't forget that the purpose of CT is to reveal problems with > certificates, not to solve them. > > My characterization of CT (draft-kent-trans-architecture-02.txt) is: > > Certificate transparency (CT) is a set of mechanisms designed to > deter, detect, and facilitate remediation of certificate mis-issuance > (as defined below). > > I wrote this (month ago) because I thought it was useful to provide a > concise > characterization of CT goals. Do you disagree with the text above? No. > > Also, I don't get the logic of the "not-logged bogus certificate", > which is identical to the logged certificate - and is therefore > logged. And not bogus. > > A cert is bogus when it is issued to an entity that is not authorized > to represent the Subject of the cert. This is true whether the cert is > logged or not. > > Ah, I see. In that case, is the cert in question not a "logged bogus cert"? > > > yes, it is. > > Steve > > _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
