On 29 October 2012 11:58, Stephen Farrell <[email protected]> wrote: > > > On 10/29/2012 11:18 AM, Rob Stradling wrote: >> On 29/10/12 11:06, Ben Laurie wrote: >>> On 29 October 2012 11:00, Rob Stradling <[email protected]> wrote: >> <snip> >>>> 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. >>> >>> 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. >> >> OK, scrap that idea then. :-) > > 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.
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. > 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:-) I am still holding out for a single document :-) > >>>> Given the imminent closure of the PKIX WG, I'm tempted to also >>>> suggest... >>>> - One document that will define requirements for "Effective >>>> revocation >>>> mechanisms". >>> >>> Not against that at all, but it sounds like a different WG to me. >> >> Maybe so. > > 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. > _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
