Subject: [therightkey] How many documents?

From: Stephen Farrell <[email-masked]>
Date: Fri, 26 Oct 2012 17:16:32 +0100

Hiya,

I know we're not having a wg-forming BoF but there's a
thing I think I'd like to see discussed at or before
the BoF that'd normally be part of a wg-forming BoF but
is still worth doing now. (Discussing this on the list
since we've all read the draft is even better of
course:-)

Assuming for the moment that we do go ahead and
standardise CT, how many documents (RFCs) ought be
used to document that?

If the answer turns out to be one, then it might be more
efficient to process CT as an AD sponsored draft, so if
your answer to the above is 1, then I'd like input about
doing that or not doing that.

If the answer is more than one, then what might those
be, and are there dependencies on other IETF WGs or
external groups? Clearly, if the answer is more than
one non-wg draft, that means that AD sponsoring is
less likely and a WG is likely needed. If you think
this is the case, it'd be good to see your suggestion
for what RFCs ought be produced.

I guess I'm sort of asking for suggestions as to what
milestones a WG might adopt if we were to form one.
I do realise that this is only part of the discussion
that we need to have, and is contingent on us wanting
to do something with CT, but I've not seen it raised
so far, so thought I'd kick that off.

If you're not sure about the process parts of the
above (e.g. "AD sponsored") please just ask. Paul
or I can answer that.

Thanks,
S.

PS: Its ok to give your answer to this even if you
think that CT should not be standardised in the IETF.
If that's the case maybe say so if you want.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 29 Oct 2012 11:00:25 +0000

Hi Stephen.

Last month Ben posted this:
"Emilia Kasper and I came up with a mechanism for providing revocation
transparency. We currently have no plans to implement it, but the
mechanism is interesting.
Blog post here: http://www.links.org/?p=1272
Paper here: http://sump2.links.org/files/RevocationTransparency.pdf"

And in his draft charter he wrote:
"Optionally, do the same for certificate revocations."

CT will only be effective if:
1. "browsers will refuse non-CTed certs" (to quote Ben).
2. Effective revocation mechanisms exist, so that dodgy certs brought to 
light by CT can be effectively dealt with.

I think RT would definitely be a good project for a Transparency WG to 
take on after CT.

I don't have a strong opinion about this, but I think it might make 
sense to split up the CT standardization effort into multiple documents, 
because different audiences will be interested in different aspects of 
CT.  i.e.
   - One document aimed at the people who will implement and/or operate 
CT log servers.
   - One document aimed at CAs who will implement pre-certs and/or embed 
proofs into OCSP Responses.
   - One document aimed at browser authors who will write code to verify 
proofs.
   - One document aimed at webserver authors who will need to understand 
the importance of implementing RFC5878 and/or OCSP Stapling (RFC6066).
   - One document aimed at auditors who will need to know how to verify 
that a CT log has not been compromised.
   - One document aimed at domain owners who will need to know i) how to 
discover if any certs have been misissued to their domain names and ii) 
what to do about any detected misissuances.

Given the imminent closure of the PKIX WG, I'm tempted to also suggest...
   - One document that will define requirements for "Effective 
revocation mechanisms".

On 26/10/12 17:16, Stephen Farrell wrote:
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 29 Oct 2012 11:06:37 +0000

On 29 October 2012 11:00, Rob Stradling <[email-masked]> wrote:
> I think RT would definitely be a good project for a Transparency WG to take
> on after CT.
>
>
> I don't have a strong opinion about this, but I think it might make sense to
> split up the CT standardization effort into multiple documents, because
> different audiences will be interested in different aspects of CT.  i.e.
>   - One document aimed at the people who will implement and/or operate CT
> log servers.
>   - One document aimed at webserver authors who will need to understand the
> importance of implementing RFC5878 and/or OCSP Stapling (RFC6066).
>   - One document aimed at auditors who will need to know how to verify that
> a CT log has not been compromised.
> discover if any certs have been misissued to their domain names and ii) what
> to do about any detected misissuances.

TBH, I disagree - the reason being that almost all of these documents
will be identical (i.e. describing the cryptographic structure of the
log) and the only differences will be which parts of the protocol they
use - some of which will inevitably overlap. Right now the document is
lacking a few of these areas, but it is by no means unwieldy. I think
splitting across multiple documents will create a lot of pointless
duplication and effort.

>   - One document that will define requirements for "Effective revocation
> mechanisms".

Not against that at all, but it sounds like a different WG to me.

> This e-mail and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender by
> replying to the e-mail containing this attachment. Replies to this email may
> be monitored by COMODO for operational or business reasons. Whilst every
> endeavour is taken to ensure that e-mails are free from viruses, no
> liability can be accepted and the recipient is requested to use their own
> virus checking software.
>

---

From: Rob Stradling <[email-masked]>
Date: Mon, 29 Oct 2012 11:18:00 +0000

> On 29 October 2012 11:00, Rob Stradling <[email-masked]> wrote:
<snip>
> splitting across multiple documents will create a lot of pointless

OK, scrap that idea then.  :-)

> Not against that at all, but it sounds like a different WG to me.

Maybe so.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Oct 2012 11:58:02 +0000

On 10/29/2012 11:18 AM, Rob Stradling wrote:
>>> sense to

Well.... maybe not quite so quickly. I think its a real issue
that a single document might be difficult for all those audiences.

Now, I don't think the IETF actually ought try address all of
those audiences, since RFCs are for the folks writing code, and
mostly not for auditors or CA/web site operators, though we do do
some of the latter sometimes.

But I still wonder if 1 or >1 document is right, and as Ben says
the current draft is a bit sketchy in some areas that might or
might not be better separated out. Perhaps the right answer will
turn out to be to look at the draft later when those areas are
more developed, but I'm asking now anyway:-)

>>> revocation

Right, or a later milestone after a re-charter if we end up
with a WG. At this point, I'd guess that anyone wanting revocation
considered sooner would need to be yelling (and since they
haven't written an I-D, they'd need to be quite convincing as to
why yelling with no I-D is appropriate).

S.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 29 Oct 2012 18:23:38 +0000

> some of the latter sometimes.

I should point out that in this context an auditor is a technical term
- an agent that, given some alleged entries from a log, audits that
the log actually contains those entries, or given an alleged past
snapshot of the log audits that it is consistent with the current log.
Clients may well be auditors, too, but technically the roles can be
separated.

> more developed, but I'm asking now anyway:-)

I am still holding out for a single document :-)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 29 Oct 2012 14:53:24 -0400

I very much doubt we will manage to get a finished spec with anything less
than four documents since I can't remember offhand any case when we have
not. But equally, I can't see a need for a split now. Going through four
documents rather than one is tedious.

In the longer term I see the parts of the spec that describe the notary
formats and structure as being potentially re-usable in other contexts and
that it will make sense to separate those out from the discussion of certs,
PKI and such.

-- 
Website: http://hallambaker.com/

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Oct 2012 12:02:25 -0700

On Oct 29, 2012, at 11:53 AM, Phillip Hallam-Baker <[email-masked]> wrote:

> I very much doubt we will manage ...

As a point of reference, the charter of this BoF is:

This non-WG forming BoF will discuss plans to specify mechanisms and
techniques that allow Internet applications to monitor and verify the
issuance of public X.509 certificates such that all issued certificates
are available to applications, and each certificate seen by an
application can be efficiently shown to be in the log of issued
certificates. Furthermore, it should be possible to cryptographically
verify the correct operation of the log.

Until that changes, there is really no "we" for doing anything: the proposal about individual submission or independent submission documents. Stephen's question about number of documents was for the current authors, not for a pre-WG (unless he has changed his mind without telling me...).

--Paul Hoffman, BoF chair for the next 8 days, and hopefully not much longer

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Oct 2012 19:11:15 +0000

> Until that changes, there is really no "we" for doing anything: the proposal about individual submission or independent submission documents. Stephen's question about number of documents was for th…

I tell you everything:-)

I'm interested in folks' opinions generally though. Reason
for that is to help evaluate the feasibility of the option
of just AD sponsoring a single draft. If there were a
justifiable widespread opinion that >1 doc is needed that
doesn't fit any current WG then that sort of takes the AD
sponsoring route off the table.

Cheers,
S.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Oct 2012 12:18:37 -0700

> standardise CT, how many documents (RFCs) ought be

1. It needs to be written so that both CAs and browser vendors can read it, but that's the only requirement. Extra points for a generally-readable summary and maybe an appendix for the layperson, but the definition of the scheme can live in a single document.

--Paul Hoffman

---

From: Ben Laurie <[email-masked]>
Date: Mon, 29 Oct 2012 19:19:35 +0000

> 1. It needs to be written so that both CAs and browser vendors can read it, but that's the only requirement. Extra points for a generally-readable summary and maybe an appendix for the layperson, b…

Actually, there are monitors, too.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Oct 2012 13:35:18 -0700

> Actually, there are monitors, too.

Yes, but if I am going to trust a monitor, they had better damn well at least as technically capable as the CAs and the browsers. My personal hope is for a small number of obviously-trusted monitors, not a thousand flowers blooming.

--Paul Hoffman