Subject: Re: [keyassure] Charter sent to ADs

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 8 Oct 2010 16:53:37 -0500 (GMT-05:00)

Ilari and all,

-----Original Message-----
>From: Ilari Liusvaara <[email-masked]>
>Sent: Oct 8, 2010 4:20 PM
>To: "Richard L. Barnes" <[email-masked]>
>Cc: Tony Finch <[email-masked]>, Phillip Hallam-Baker <[email-masked]>, "[email-masked]" <[email-masked]>
>Subject: Re: [keyassure] Charter sent to ADs
>
>On Fri, Oct 08, 2010 at 03:32:06PM -0400, Richard L. Barnes wrote:
>> >
>> >The two are not mutually incompatible. The authorized CA
>> >identified in the DNS can be a private CA (which also deals with
>> >the many-certs problem that Phill identified) and in the simplest
>> >case it should also be possible to identify the server's cert
>> >directly.
>> 
>> Certainly agree that putting CA certs in the DNS could be a useful
>> approach.  It's not the same as a "do not issue" warning.
>
>Furthermore, bad enough CAs could just ignore the "do not issue"
>warnings (for instance if coerced). 
>
>Here's (another) way to do that:
>
>TLSCFP (Transport Layer Security Chaining FingerPrint) record.
>
>These come to play if no matching TLSFP record (eithe direct or
>indirect via TLSRQ) is found but usable TLSCFP records are present.
>
>The client will then collect all available (local store and server-
>sent) certificates that match fingerprints in TLSCFP records and
>runs normal PKI validation with collected certificates notionally
>declared to be trust anchors.

  This assumes that the Trust anchor(s) are trustworthy at the time
of this check.
>
>If this check passes, the key is OK from DNS key checking POV. The
>client may or may not trust it at this point (depending on client
>local policy).

Right.  But if the policy is bad at the time given the trustworthyness
of the Trust Anchor(s) relied upon.  Such may not be the case.
>
>If this check fails, the whole DNS key checking fails and client
>SHOULD NOT trust the certificate.

Right again.  However seems to me anyway that this possibility is
minimized by the questionable assumption that at least one Trust
Anchor used for validation is not compermized.  A reasonably good
assumption depending on the before mentioned policy, but not necessarly
an accurate assumption.
>
>
>The reason for excluding certs that match TLSFPs is that one can't
>attack those using bad-CA attacks anyway (since that certificate
>can't be used without server key, legimate server sends good
>certificate chains and compromising the key would compromise
>everything anyway).

Yes but only if the server key is ligitimate or valid which is not
necessarly an assumption that can be made.
>
>-Ilari
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams

"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

---

From: Paul Wouters <[email-masked]>
Date: Fri, 8 Oct 2010 21:28:50 -0400 (EDT)

On Fri, 8 Oct 2010, Jeffrey A. Williams wrote:

[Way behind on the list, possible more in-depth message following...]

The goals of the charter seem good in their goals to allow DNSSEC and CA based
authentication systems to coexist.

This is very important. Try to limit the interaction required for either system
so that they work as independantly as possible, without demanding or forbidding each other's
use. Where interaction occurs, try to limit data overlap or data duplication as much
as possible - this points specifically to SSL/TLS.

I should be able to configure my browser with a preference of auth scheme. One over
the other, or both as a minimum.

Bonus points if two machines can do this when connecting offline (eg bluetooth)

Paul