{"push_id":1027169497,"size":6,"distinct_size":1,"ref":"refs/heads/ticket_131","head":"f2c1120f8f77461b8d36224ac211eef8257efa33","before":"42e67b3ae1ad5f8058862fb022aa209c23a5bdaa","commits":[{"sha":"4a3dd43ad2044c398fdc65309c6efedbda33ff3a","author":{"email":"7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@comodo.com","name":"Rob Stradling"},"message":"Ticket 155: Describe how to match SCTs to certificates.\nSuggest evaluating the certificates in the order they appear in the chain.\nClarify that TLS clients MUST NOT consider invalid any SCT or inclusion proof until each potentially corresponding certificate has been evaluated.","distinct":false,"url":"https://api.github.com/repos/eranmes/certificate-transparency-rfcs/commits/4a3dd43ad2044c398fdc65309c6efedbda33ff3a"},{"sha":"b9126702f7d3a139258c65dd78bff309ae44009b","author":{"email":"7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@comodo.com","name":"Rob Stradling"},"message":"Only mention Symantec in the Acknowledgements section.","distinct":false,"url":"https://api.github.com/repos/eranmes/certificate-transparency-rfcs/commits/b9126702f7d3a139258c65dd78bff309ae44009b"},{"sha":"00b8bf705b570c8912dba024be96c161a3d6371c","author":{"email":"ae86a985811ad650849e18e2730905d68b96b36d@google.com","name":"Eran"},"message":"Ticket 142: Specify clients should send an empty extension_data.\n\nSee http://trac.tools.ietf.org/wg/trans/trac/ticket/142 for the reasoning behind this.","distinct":false,"url":"https://api.github.com/repos/eranmes/certificate-transparency-rfcs/commits/00b8bf705b570c8912dba024be96c161a3d6371c"},{"sha":"ddaff4fc87cb52bbcb84891abec6cdac371d2935","author":{"email":"ae86a985811ad650849e18e2730905d68b96b36d@google.com","name":"Eran Messeri"},"message":"Ticket 153: Explain about V1/V2 interoperability.\n\nV1 and V2 SCTs can co-exist for X.509 certificates, but not precertificates.\nThis change enables V2 SCTs to be valid for V1 precerts by specifying that V2\nclients should remove the X.509 extension with V1 SCTs prior to checking V2\nSCT signatures.","distinct":false,"url":"https://api.github.com/repos/eranmes/certificate-transparency-rfcs/commits/ddaff4fc87cb52bbcb84891abec6cdac371d2935"},{"sha":"7120d1867d40522f65c8fe19191388c6b88560c7","author":{"email":"ae86a985811ad650849e18e2730905d68b96b36d@google.com","name":"Eran Messeri"},"message":"Ticket 118: Monitors may do one of several things.\n\nClarify that monitors may watch logs to audit their behaviour, for certificates\nof interest or both.","distinct":false,"url":"https://api.github.com/repos/eranmes/certificate-transparency-rfcs/commits/7120d1867d40522f65c8fe19191388c6b88560c7"},{"sha":"f2c1120f8f77461b8d36224ac211eef8257efa33","author":{"email":"ae86a985811ad650849e18e2730905d68b96b36d@google.com","name":"Eran Messeri"},"message":"Ticket 131: Provide guidance on selecting CT logs.\n\nAdopting David's suggestion to recommend that a TLS server inspects the\nset of logs acceptable/recognized by popular TLS clients.","distinct":true,"url":"https://api.github.com/repos/eranmes/certificate-transparency-rfcs/commits/f2c1120f8f77461b8d36224ac211eef8257efa33"}]}