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. On Mon, Oct 29, 2012 at 2:23 PM, Ben Laurie <[email protected]> wrote: > 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 > -- Website: http://hallambaker.com/
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
