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

From: Tobias Gondrom <[email-masked]>
Date: Sat, 09 Feb 2013 21:34:53 +0800

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 with a number of implementations by major ECM and
DMS vendors.
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 <[email-masked]> wrote:
>> On Tue, 2013-01-29 at 11:35 +0000, Ben Laurie wrote:
>>> On 24 January 2013 19:06, Jeffrey Hutzelman <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Ben Laurie <[email-masked]>
Date: Sat, 9 Feb 2013 20:47:01 +0000

On 9 February 2013 13:34, Tobias Gondrom <[email-masked]> wrote:
> 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).

> with a number of implementations by major ECM and
> DMS vendors.

No idea what ECM or DMS are in this context.

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 10 Feb 2013 10:54:47 +0800

> 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.

> 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.)

---

From: Ben Laurie <[email-masked]>
Date: Fri, 22 Feb 2013 16:36:22 +0000

> MMD). As the RFCs only define the data structure.

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

> And protect the proof of integrity / non-repudiation with Timestamps and

These systems rely on trust. :-)

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 23 Feb 2013 21:41:50 +0800

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

Well. Whether you like to take it or parts of it or re-write/re-invent
the wheel is obviously up to you.
(and I agree that the base data structure (Merkle Hash Tree) itself is
pretty trivial. It gets complicated if/when you need to switch to new
algorithms over time, which I believe is ERS has proven very useful in
implementations. Whether that might be a potential use case for your
system, shall be for others to judge.)
I only thought I should make you aware of the existing RFCs.