>> 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
> If, as I suspect, its still a bit early for a BoF on
> this topic, but a bunch of you will be at the Paris
> IETF in any case, then you can self-organise a
> bar-BoF/side-meeting, (if you do, please try do it
> in a real bar:-). You don't need me or anyone else
> to help with that, just do it if
serious security architecture it does not look like a chain, it does
> not have a single point failure mode.
>
>
>
> On Thu, Jan 26, 2012 at 5:55 PM, Richard L. Barnes wrote:
>>>>> As security engineers, our role is to (a) reduce the number of
>>>>>
>>> As security engineers, our role is to (a) reduce the number of
>>> entities we trust; (b) reduce the extent to which we trust the
>>> remaining trusted entities; and (c) determine the trustworthiness of
>>> trusted entities.
>>
>> Really?
>
> Yep.
+1
One of the better definitions I've hea
>>> If a system is going to be robust in practice it has to take account
>>> of all possible sources of error including administrative incompetence
>>> and user error.
>>
>> I'm curious: where do you draw the line? Should routing system security
>> be included? Email security (since many transac
Illegitimate transfers are out of scope. From the point of view of the DNS, an
illegitimate transfer is indistinguishable from a legitimate transfer.
The only thing technology could do for this case is allow the web site to tell
customers "I'm not planning to change anything in the next N days"
Like, his dog dies? Someone posts naked pictures of his girlfriend to facebook?
I think we might need to constrain things a little further.
On Jan 19, 2012, at 6:51 PM, Phillip Hallam-Baker wrote:
> None of them
>
> The threat we should be interested in at this point is the following:
>
> *
