Re: [Trans] defining "mis-issuance"

[Stephen Kent <[e-mail]>]

Rick,
> ...
>
> It's doable, but it still leaves the CA in a bind. What if the CA 
> wants to start issuing certs according to new CABF docs, but finds 
> that none of the existing log servers support that version? This is 
> probably a moot point, isn't it, because Melinda has reminded us not 
> to introduce any normative dependencies on CAB Forum documents or 
> processes.
>
I'm ignoring that "advice" for now, as it was not accompanied by any 
description of
a procedural basis for ignoring the CABF guidelines in this context :-).

More to the point in the IETF if we want to avoid a normative reference 
to another SDO's doc,
we can do what I have already done, i.e., create our own version 
(usually a subset) of the doc
and make it part of an RFC (or make it a standalone RFC). We started 
doing this long ago when
we created CMS as a standards track RFC that updated PKCS docs. So, we 
can literally avoid
a normative dependency on CAF guidelines, merely cite them as the 
source/motivation for
our CT mis-issuance definitions.

Still, your point is a good one.  We could push the syntax checking back 
to Monitors,
but then we loose the ability to provide immediate feedback to CAs that 
are issuing
syntactically malformed certs. I'll have to think more about this issue.
>
> ....
>
>
> If the Subject provides a list of all o the keys associated with the 
> Subject, perhaps in the form
> of certs issued to the Subject (and currently valid) this would enable 
> a Monitor to detect this form of mis-issuance, agreed?
>
> Agreed, but it puts a burden on the Subject. Before issuing any new 
> legitimate certificate, the Subject would need to notify the Monitor 
> of the new Subject name and/or public key. We've got some customers 
> who issue thousands of certificates across their organization. IMO, 
> the model might work better if the Monitor is simply a conduit, 
> providing information found in log servers to the Subject, and then 
> the Subject can decide if each new certificate was intentionally issued.
>
I don't think we are fundamentally disagreeing here. I have assumed that 
a Monitor notifies a
Subject when the Monitor detects that a cert with the Subject's name has 
a different key from
the set supplied by the Subject to the Monitor, as reference data. The 
Subject makes the final
determination and acts on that. So, a Montitor is alerting a Subject to 
what appear to be a
mis-issuance. So, if the info that a Monitor passes to a Subject is the 
set of certs that the
Monitor finds in logs, the only difference in my proposal is that the 
Monitor would not pass on
certs that match a set of keys supplied by the Subject.  One could 
transform my model into what
you said by having a Subject provide no keys, but noting that the 
Subject does have one or more
certs issued to it.
>
>
>
> A separate topic is issuance of a bogus cert for a Subject who doesn't 
> have a cert issued legitimately.
> In this case there is no reference cert to present to a Monitor. It 
> may be hard for a Subject who
> doesn't have a cert to convince a 3rd party Monitor to check for certs 
> issued to the Subject name
> in question. Should we classify this as mis-issuance as well?
>
> See my comment above. Must the Monitor be able to decide by itself 
> what is legitimate and what is mis-issued, or is that the role of the 
> Subject, with help from the Monitor? In other words, couldn't we say 
> that it's mis-issuance if the Monitor finds a cert in a log, forwards 
> it to the Subject, and the Subject determines that it's mis-issued?
>
> -Rick
>
The issue here, I think, is that a web site that has no Web PKI cert, 
e.g., because it has a self-signed
cert or is relying on DANE, might not enlist the help of a Monitor, 
especially if there is a cost to do
so.  I'm not sure we need to address this case, but we do need to 
identify it and say that we are
not addressing it if we choose to do so.

Steve