I think there should be two separate drafts. 1) Cover the technical spec describing how the notary log system works, the data formats etc. 2) Cover the use of the scheme in the context of PKIX.
(1) is then reusable to other applications. Phill On Tue, Nov 20, 2012 at 7:33 AM, Ben Laurie <[email protected]> wrote: > Dear Group, > > Following the recent BoF and discussion with Stephen Farrell, the plan > is to try to publish an experimental RFC for CT and, all going well, > follow up later with a WG. > > In the experimental RFC we will cover the operation of the log, the > log protocol and TLS client verification of CT. We will be > specifically targetting the use of CT with PKI for HTTPS, and not > other applications such as DNSSEC, self-signed certs, device certs, > other TLS secured protocols, etc. Not that we exclude the possibility > of using transparency logs for such things, of course, they just will > not be covered by this initial RFC. > > The RFC will be broadly similar the existing I-D but will flesh out > the protocols for interacting with the log, as far as they are > currently defined. It will add RSA signatures for logs that would > prefer to use it. > > It will not cover details of the audit process (that is, how clients > verify that the timestamps they see really are included in the public > log) as we think that will evolve quite rapidly for some time to come. > > The approximate timeline is that we hope to go to IETF last call > around the end of the year. > > I intend to put out at least one more version for comment before that, > though. > > As always, all comments are welcome. > > Cheers, > > Ben. > _______________________________________________ > 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
