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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
