Using webid for cert issuing. Dependency relationship between domain-cert and webid

http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html

 

The issues of CAs issuing domain-certs and Comodo CA, specifically, has been
introduced here before now. Let's consider the relationship of the
underlying topics to webid, in light of standardized unit testing. Let's
remember, that claims have been made that webid is "secure". Let's test this
by applying webid to the RA/CA interactions - transactions that are
particularly security sensitive - and which impact the security model of
webid itself.

 

Let's imagine that an authorized cert issuer uses the manufacturing services
of Comodo, leveraging it's RA/CA relationship. Let's say that the RA user
makes use of a commodity browser to logon to an improved Comodo online
Certificate Management System, using webid protocol. To do this, the CA
issues the RA user a domain-cert for his/her webid endpoint. The RA user
duly issues him/herself a self-signed webid citing an https URI
(specifically), creates the foaf card as normal, and registers the webid URI
in the CA/RA access control system. Let's say that the CA, acting as relying
party, insists on a https class webid for access control, so that its harder
for an attacker to falsify the foaf card in transit. Let's assume the CA has
the means to determine from SSL when that foaf card has integrity.

 

While enforcing its security policy, the CA decides to suspend the RA
pending investigations. Lets say it now uses its CRL and OCSP capabilities
(see Comodo link for relevance) to suspend the domain cert supporting the
https webid.

 

What does this mean to us? The foaf card exist in many caches of course, and
its triples have been incorporated in many a aggregated triple store by the
likes of Google. How critical is the revocation status of the https
endpoint's domain-cert to the validity of the webid? Which controls validity
of a webid: a cache or the domain-cert? is validity subjective?

 

While it makes sense that the CA as a relying party to superimpose its own
validity model on certain webids (based on the status of the domain-cert for
the endpoint of the foaf card), does it make sense for other relying parties
to consider the status of the domain-cert?

 

Do we intend the general relying party to first consult the CA for
revocation standing of an domain-cert to determine if the (https) webid is
valid?

 

If the CA merely suspends the cert but does not revoke its name/key binding,
what is the validity status of the webid?

 

If no unexpired revocation information can be obtained (because an attacker
is blocking access to the latest update with a DOS, say), does the validity
status of the webid change to invalid? 

 

Are we perhaps assuming that there are n validity models - one per relying
party? that each relying party has different criteria and thresholds? That
one consumer of a webid may consider the validity of the domain-cert, and
another may not? That one may consult and consider revocation information,
and another may not? That one may ignore revocation status change from valid
to suspended, while another may interpret suspended as invalid. If the DNS
record of the https URI's domain name suddenly disappeared under the
influence of a government (think wikileaks), does this make the domain-cert
invalid (even though it's NOT listed on the CA's CRL or OCSP) and thus make
the webid invalid?

 

In general, do we promote any dependency relationship between the validity
of the server cert hosting the foaf card (if any) and the validity of the
webid itself?

 

How does a machine reason with these issues, using purely logical
propositions?