Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC

[Carl Wallace <[e-mail]>]

On 11/17/12 2:37 PM, "Paul Hoffman" <[e-mail]> wrote:

>On Nov 17, 2012, at 11:32 AM, "Richard L. Barnes" <[e-mail]> wrote:
>
>>>> CT-for-PKIX helps a web site administrator determine if a trusted CA
>>>>ever issued a certificate that should not have been issued.
>>>> 
>>>> CT-for-DNSSEC helps a DNS zone administrator determine whether a DNS
>>>>server in the hierarchy above the leaf zone ever included a DS record
>>>>that should not have been included.
>>>> 
>>>> It would be good to have agreement on the above; feel free to offer
>>>>changes and see if the authors agree. Then we can talk about the
>>>>relationship between the two.
>>>> 
>>> 
>>> Sounds reasonable to me.
>>> 
>>> Does "CT" need to be renamed for DNSSEC? Since we're talking about
>>> transparency of delegation records/keys and not X.509 certificates.
>>> If C means "certification" in the general sense, then I suppose it
>>> might still be applicable since a (signed) DS record certifies the
>>> authenticity of the secure entry point key in a subordinate zone.
>> 
>> "DST"?
>> 
>> The definitions sound reasonable, but I'm at a loss as to why you would
>>bother with "CT-for-DNSSEC".  The whole point of CT is that the space of
>>X.509 issuers is very large, and the certificates can be presented by
>>any server on the Internet.    It's a hassle to check every, say, HTTPS
>>server on the Internet to see if a cert with your name is being provided.
>> 
>> In DNSSEC, the set of "issuers" is very small (parent domains), and the
>>DS records originate from a well-defined set of sources (authoritative
>>servers for those domains).  Checking those servers is not that much
>>more difficult than checking a CT log, and doesn't require any new
>>protocol.
>
>Maybe you missed the earlier discussion of this in the past few days.
>
>Rogue DS records might not be detectable to the party with the leaf
>record. For example, assume the domain name example.newtld. The owner of
>example has put DS record A in the newtld zone. If the owner of newtld
>goes rogue and shows DS record B to a limited number of requests (such as
>to a particular geographic region or set of network addresses), the party
>with the private key associated with B can spoof example, and the owner
>of example would not know unless he could see B.

Who is intended to be able to contribute to the log?  It seems like for
this to provide the desired visibility, any client should be able to.  For
CT, at least, I thought this was not to be the case.