Re: [keyassure] Objective: Restrictive versus Supplementary Models

[Michael Richardson <[e-mail]>]

>>>>> "Yoav" == Yoav Nir <[e-mail]> writes:
    Yoav> So it's really down to 4 cases:
    Yoav> - CA-lock (I only use Verisign)
    Yoav> - Cert-lock (I only use this cert)
    Yoav> - This CA (This is the CA cert that issues my certificate, and
    Yoav> it may not be in your TAS) 

    Yoav> - This Cert (this is the cert I'll be using, and I'm not
    Yoav> promising that you can validate it) 

    Yoav> While I see some value in cert-lock, I don't see much value in
    Yoav> CA-lock. It would solve Comodogate if I was a customer of
    Yoav> another CA, but not if I was a customer of Comodo. 

Presumably, if you were a customer, they would never issue two certs for
the same DN to different customers.

    Yoav> Cert-lock (and CA-lock) are what EKR calls supplementary,
    Yoav> while the others are the restrictive. While the sever (and
    Yoav> domain owner) can't dictate client policy, they should be able
    Yoav> to indicate whether the Certificate (TA or EE) that's in the
    Yoav> TLSA record is supposed to be validatable or not. The client
    Yoav> (relying party) may have a policy to ignore records that push
    Yoav> a non-valid certificate, but if you're going to publish a
    Yoav> record with a certificate that you have just issued using
    Yoav> openssl on your laptop and expires in 1975, the TLSA record
    Yoav> had better reflect that this certificate is just a container
    Yoav> for a public key, not something you can chain and validate. 

So, you are arguing that the protocol must signal the intent.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [e-mail] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.