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.
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.
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?
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
