Ben,
Thanks for explaining what you and your co-authors have in mind when
you use the term mis-issuance. This is a very important first step toward
clarification for CT.
A certificate is characterized as mis-issued if the certificate is issued to
an entity that is not authorized to represent the host (web server) named in
the certificate Subject field or Subject Alternative Name extension. <do we
want to focus exclusively on SAN vs. Subject?)
This is not the only form of mis-issue - for example, the Baseline
Requirements impose key size limits, lifetime limits, usage bits
restrictions and so forth.
EV adds even more stuff.
So the scope of mis-issuance is much broader than what I had imagined.
I think we may need to add two things to 6269-bis:
- normative references to CABF documents that are the basis for the
broader
set of cert issuance criteria that you note
- maybe two appendices to enumerate the criteria. this will be
critical if
if the CABF docs contain other criteria that are outside the
scope of CT,
e.g., criteria that cannot be evaluated based on what is logged.
Do you agree?
...
The other recourse is to revoke directly in the browsers - either the
whole CA or the offending certificate(s). This is what happened to
DigiNotar, for example.
I agree that one might do that, but I am aware of no IETF standards for
doing so. My understanding is that DigiNotar, as a trust anchor, was
removed from the TA list. I am not aware (but then I am not a browser
vendor) of an equivalent mechanism for CAs below TAs. Also, the TA list
mechanism is not an IETF standard. We need to cite a spec, preferably
a standard, on how to deal with browser-based revocation. Is there an
appropriate CABF document that needs to become a normative reference?
...
I do agree that we need to define the gossip protocol to complete the CT story.
I'm glad that we're in agreement here.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
