Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

["Piyush Jain" <[e-mail]>]

> -----Original Message-----
> From: Martin Rex [mailto:[e-mail]]
> Sent: Tuesday, October 30, 2012 1:47 PM
> To: Miller, Timothy J.
> Cc: [e-mail]; Piyush Jain; [e-mail]; 'Stefan Santesson'
> Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
> 
> Miller, Timothy J. wrote:
> >
> > > X.509/PKIX is defective because it breaks badly already on
> > > fraudulent cert issuance (a weaker form of CA compromise) and can
> > > not cope at all with CA key compromise.
> >
> > Do you have an alternative to the technology, because AFAICT, no PKI
> > standards recover well from a breach of trust.
> 
> The design flaw of PKI is that all CA keys are single points of failure.
There is a
> complete lack of backup if one fails, or can be made to fail.

> 
> Designing a technology with complete lack of a backup system seems like a
> bad idea to me.  Like skydiving with only one single parachute, or
designing a
> large commercial passenger jet with just a single turbo-fan engine
> (something which FAA might refuse to certify for good reasons).
>
[Piyush] Technology is what it is. You can always design you system that
uses the technology in a way that makes it fault tolerant. In your example
above engine is the technology and jet is the system. You can always have a
system where you provide secondary method for authentication (may be certs
issued of a bakup CA) while you recover from main CA compromise.
 
> 
> The fact that _no_ existing PKI standards provide backup facilities today
is a
> mere technical defect that _could_ be fixed.
> 
> 
> 
> >
> > Even the web of trust has issues; if a well-connected introducer is
> > compromised, all descendent keys become suspect--which can potentially
> > encompass all nodes in the graph.  This can be as devestating as a CA
> > compromise, and would likewise require a re-execution of a large
> > number of signing ceremonies.
> 
> I beg to differ.
> 
> When a well-connected introducer is newly compromised, then this does not
> affect any trust relationships previously confirmed by that introducer,
only
> precludes adoption of trust for new relationships.
> 
> When a well-connected introducer turns out to have been never been trust-
> worthy, it affects only those trust relationships where he is the _only_
> introducer (same effect as in single-key PKI models).
> 
> 
> >
> > > The flaw with CRLs and OCSP is that it tries to infer, from a lack
> > > of a revocation, that a certificate has been properly issued and is
valid.
> > > Evidently, this turned out to be a logical fallacy with respect to
> > > real world usage scenarios.
> >
[Piyush] Why call it a flaw. My car does not have a flaw just because it
cannot fly. 
OCSP and CRLs make simple statement - Is the certificate in question revoked
by the issuing authority, nothing more, and nothing less.
If you want more out of you server, deploy SCVP.

What real world usage scenario? My car fell off the cliff. It would've been
nice if it could fly, but unfortunately my poor driving habits (or faulty
brakes in my car) are no reason to change the design of cars.
The scenarios that you mention are exceptions rather than norms. 

> > Absent a trusted observer, there is no positive statement that can be
> > issued by a CA that positively identifies only "valid" certificates.
> > Given a trusted observer, why not make him the CA and be done with it?
> 
> 
> Maybe because PKI(X) should be more about real-wold PKIs, and less about
> Utopia.
> 
> Why should businesses and banks deal with accounting, audits and fraud
> prevention, if they could simply use a system where fraud is impossible.
As it
> turns out, it is impossible to create and run a "system where fraud is
> impossible" in the real world (even if they wanted to), especially at a
cost-
> level where business operation makes sense.  So the second best approach
> is a security trade-off, a system that makes business sense and can cope
> reasonably with common real-world _operational_ problems, like software
> being subject to bugs and staff being susceptible to social engineering,
> bribery and threat/coercion.
> 
> 
> I could imagine why crooks, hackers and certain agencies might not like
> a backup scheme that makes subverting the PKI significantly harder.
> But why should an engineer, and in particular one who understands and
> cares about security, oppose addition of a backup scheme to address
> the susceptibility of X.509 PKI to operational problems and risks
> from the pesky (physical) real world?
> 
[Piyush] Crooks would actually love the schemes that are being proposed
here. Let the victims continue to operate with the illusion of security.
Your argument would've been meaningful in this discussion if
- trust model is changes so that RP trusts the responder and CA
independently (CA compromise should not imply responder compromise)
- OCSP is the only way to check revocation status of the certificate. (RPs
should not arrive at different conclusion if the use CRLs instead of OCSP)

But I've not seen above being recommended in any of the proposals. And I
think the reason is obvious. You can deploy SCVP in DPV mode to address the
points that you raised above.



> 
> -Martin