On 20 November 2012 13:07, Stephen Farrell <[email protected]> wrote: > > Hi Phill, > > Not sure what Ben thinks of that but I'd rather > just AD sponsor one draft for now. A split like > that would definitely make sense for the > standards-track work that's envisaged to follow > though. Do you think that's really a must-have > at this stage? I guess I don't, as of now.
My view is that teasing the two parts apart is hard and so I agree it would be good for standards track, but don't want to do it for experimental. > > Cheers, > S. > > On 11/20/2012 01:03 PM, Phillip Hallam-Baker wrote: >> 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 >>> >> >> >> >> >> >> _______________________________________________ >> therightkey mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/therightkey >> _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
