Re: [secdir] dir review of draft-laurie-pki-sunlight-05

On 10 February 2013 02:54, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:
> On 10/02/13 04:47, Ben Laurie wrote:
>> On 9 February 2013 13:34, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:
>>> Hi Ben,
>>>
>>> I also just read through your draft in version -07.
>>> I can see the draft consists of two parts:
>>> 1. data structure
>>> 2. protocol.
>>>
>>> For part #1 the data structure: in case you are not aware of it, some
>>> years ago the IETF LTANS WG has done something a bit similar in a more
>>> generic way (i.e. for any data not only for certificates) in form of
>>> RFC4998 and RFC6283
>> Interesting. I was not aware of these. From a quick skim they are
>> indeed similar, but would need a bunch of added machinery to get them
>> to where CT is (e.g. not append only, no concept of MMD).
> You are welcome.
> I believe the gap is mostly towards the protocol side (e.g. including
> MMD). As the RFCs only define the data structure.

It seems like a lot of work to inherit an essentially trivial data structure.

>>> with a number of implementations by major ECM and
>>> DMS vendors.
>> No idea what ECM or DMS are in this context.
> ECM: Enterprise Content Management
> DMS: Document Management System
> (Systems that store electronic documents/data.
> And protect the proof of integrity / non-repudiation with Timestamps and
> RFC4998/RFC6283.)

These systems rely on trust. :-)

>
>
>>
>>> Just as a thought, maybe helpful looking at or even for re-use instead
>>> of re-inventing the wheel?
>>>
>>> Best regards, Tobias
>>>
>>>
>>>
>>> On 30/01/13 18:15, Ben Laurie wrote:
>>>> On 29 January 2013 21:28, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
>>>>> On Tue, 2013-01-29 at 11:35 +0000, Ben Laurie wrote:
>>>>>> On 24 January 2013 19:06, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
>>>>>>> Similarly, as an anti-spam measure, this document proposes that logs accept
>>>>>>> only certificates which chain back to a known CA, and requires that logs
>>>>>>> validate each submitted certificate before appending it to the log.  This
>>>>>>> sounds good, but it's not the only possible mechanism, and so I think MUST
>>>>>>> is too strong here.  Additionally, there is no discussion of the security
>>>>>>> implications if a client depends on a log to do this and the log does not
>>>>>>> actually do so.  Rather than requiring that logs validate every submitted
>>>>>>> certificate, the document should only RECOMMEND that they do so, and make
>>>>>>> clear that clients MUST NOT depend on such validation having been done.
>>>>>> On second thoughts, whilst that is an effective anti-spam measure, it
>>>>>> is also part of the functionality of CT: i.e. to identify misissue and
>>>>>> give some means to do something about it. The CA check ensures we have
>>>>>> someone to blame for misissue.
>>>>> Hrm.  I sort of thought the idea was for the logs to be untrusted
>>>>> repositories, able to be audited but not themselves expected to detect
>>>>> problems.  If logs are expected to do validation of this sort, is there
>>>>> a way for a third party to discover whether they are doing so (or at
>>>>> least, whether they are accepting certificates they shouldn't)?
>>>> A third party can indeed verify this - they just watch the log like
>>>> any monitor does.
>>>>
>>>>>> I am not averse to suggestions that achieve the overall aim, but I
>>>>>> don't see the virtue of leaving it vague in the description of the
>>>>>> experiment we are actually running.
>>>>> I'm not suggesting vagueness; rather, I'm merely suggesting downgrading
>>>>> a MUST to a SHOULD, which is still quite strong.  What happens if
>>>>> someone wants to start logging certs issued by a private CA, or
>>>>> self-signed certs they have observed, or...?
>>>> I don't see an issue with logging certs from a private CA. As for
>>>> self-signed certs, I don't see the point, but I guess if someone
>>>> figures out a point we can relax it in the next version.
>>>>
>>>>> I'm suppose I'm OK with keeping the scope narrower than that for
>>>>> purposes of the experiment, as long as it is possible to relax the
>>>>> requirement later without breaking the system.  Hence the importance of
>>>>> making it clear that clients must not rely on logs to have done
>>>>> validation (on which point I think we've already reached agreement).
>>>> Cool.
>>>> _______________________________________________
>>>> secdir mailing list
>>>> secdir@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/secdir
>>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>