Re: [Trans] Threat model outline, attack model

[Stephen Kent <[e-mail]>]

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