Ben,
... I am struggling to imagine a context in which this is not a problem. But maybe there is one.
In any environment where all relying parties make use of just one source of revocation status info AIA is not required. Also, if the RPs deal with just one CA, or in a very tightly managed PKI, or ... Remember, 5280 is the IETF PKI spec for _all_ apps and _all_ contexts, so it needs to avoid being too proscriptive. For a given app or context one can profile 52580, as we did for the RPKI, as I noted.
I think that would depend on the EE cert (i.e. does it include the AIAs needed?).
I agree that if the EE cert contained the AIA extension (there can be only one per cert) and the extension specified the CRL or OSCP source, then a browser vendor might decide it isn't necessary to blacklist. But, since this decision is up to each vendor and there are no IETF guidelines for how to make such a decision, we really can't assume how this is managed for browsers in general. Also, if one wants to assert that the CT specs apply to all TLS client/server contexts (as opposed to the HTTPS context specified in the charter), then the problem is even less bounded.
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.
thanks. Steve
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
