On 29 October 2012 11:00, Rob Stradling <[email protected]> wrote: > 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.
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. > 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. > > > > On 26/10/12 17:16, Stephen Farrell wrote: >> >> >> 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. >> >> >> >> _______________________________________________ >> therightkey mailing list >> [email protected] >> 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. > > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
