From Jeff.Hodges@KingsMountain.com Tue Jan 1 13:50:57 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2A41F0CF8 for ; Tue, 1 Jan 2013 13:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.552 X-Spam-Level: X-Spam-Status: No, score=-100.552 tagged_above=-999 required=5 tests=[AWL=-0.887, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsPyXwhqRCDl for ; Tue, 1 Jan 2013 13:50:55 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 0FC5E1F0CE7 for ; Tue, 1 Jan 2013 13:50:54 -0800 (PST) Received: (qmail 7143 invoked by uid 0); 1 Jan 2013 21:50:31 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 1 Jan 2013 21:50:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=k28ZxOMVbmKh9wzSH4GhvwSw/wJDPo9m8OU1IT4Y9tc=; b=3BwsQhUR1KAd7OWpVdeBgYHSckcRxbzusGEQf1J57BGoKxpOg7bdUffVpGjmQXmQDqFWXDFeCa6uGj9Xmpg3IRQ9L92RzQBA9Air1UDB0NuS4z6NLkTX6VOipJMM9x4C; Received: from [24.4.122.173] (port=60450 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Tq9jB-0003uF-QU; Tue, 01 Jan 2013 14:50:30 -0700 Message-ID: <50E35A23.9060003@KingsMountain.com> Date: Tue, 01 Jan 2013 13:50:27 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: therightkey@ietf.org, IETF Discussion List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: Emilia Kasper , Ben Laurie , Adam Langley Subject: [therightkey] LC comments on draft-laurie-pki-sunlight-05 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 21:50:57 -0000 Hi, Here are some last call comments on draft-laurie-pki-sunlight-05. Overall the spec is in basically overall reasonable shape but I do have some substantive comments that if I'm not totally misunderstanding things (which could be the case) ought to be discussed and addressed in some fashion. The plain overall comments are to some degree "take 'em or leave 'em" depending upon folks' sense of urgency to get the spec through the IETF pipeline, but the degree likely depends upon the observer. I hope this is helpful, =JeffH ------ comments on draft-laurie-pki-sunlight-05 substantive comments (in somewhat arbitrary order) -------------------------------------------------- 1. The client messages S4 don't explicitly lay out the syntax for request messages or responses. E.g., for S4.1 "Add Chain to Log", is the input a stand-alone JSON text array, or a JSON text object containing a JSON text array? The term "JSON object" as used in the first paragraph is ambiguous and perhaps what is mean is simply "JSON texts" or "JSON text objects or JSON text arrays". RFC4627 clearly defines "JSON text", and should be cited. But RFC4627 is a little ambiguous itself regarding "JSON object" and so I suggest these definitions: JSON text object: A JSON text matching the "object" ABNF production in Section 2.2 of [RFC4627]. JSON text array: A JSON text matching the "array" ABNF production in Section 2.3 of [RFC4627]. Also, the syntax for GETS isn't fully specified. Are the URL parameters to be encoded as (order independent) key-value pairs, or just as order-dependent values? Which separator character is to be used between parameters? RFC3986 should be cited. Examples for both JSON text inputs and outputs, as well as URL parameters would be helpful. 2. "4. Client Messages" doesn't define error handling, i.e., responses to inputs the log service doesn't understand and/or is unable to parse, and/or have other errors. If the log service is to simply return a 4xx or 5xx error code, this should at least be mentioned. 3. There appear to be three defined methods for TLS servers to provide TLS clients with CT data, in S3.2. For this experiment, which approach is mandatory to implement for servers and clients? Or, is it the case that participating TLS clients (ie web browsers etc) implement all three methods, and TLS servers can choose any of them? Also, S3.2 probably doesn't belong in S3 and perhaps should be a separate top-level section on its own, and have three subsections, one for each method. 4. "Leaf Hash" as used in S4.5 appears to be formally undefined. It apparently would be: SHA-256(0x00 || MerkleTreeLeaf) ..it should also be noted in S3.3. 5. The recursive equations in S2.1 describe how to calculate a Merkle Tree Hash (MTH) (aka "root hash"), and thus as a side effect generate a Merkle Tree, for a given set of input data. However, there doesn't seem to be a defined algorithm (or even hints, really) for adding further inputs to an existing tree. Even though this may be reasonably left as an exercise for implementers, it should probably be discussed to some degree in the spec. E.g., note that leaf hashes are "frozen" and various interior tree node hashes become "frozen" as the tree grows. Is it not sub-optimal to employ the obvious default brute-force mechanism of rebuilding a tree entirely from scratch when new inputs are available? Would not a recursive algorithm for adding new inputs to an existing tree be straightforward to provide? 6. Signed tree heads (STHs) are denoted in terms of "tree size" (number of entries), but SCTs are denoted in terms of a timestamp. Should there be a log client message supporting the return of the nearest STH (and thus tree size) to a given timestamp? 7. S3 paragraph 2 states that "TLS clients MUST reject certificates that do not have a valid SCT for the end-entity certificate" (i.e., hard-fail). Presummably this requirement is only for TLS clients participating in the CT experiment and that understand this protocol. This, or whatever the requirement actually is, should be further explained. For example, does the simple presence of SCT(s) in the TLS handshake serve to signal to participating TLS clients that hard-fail is expected if there are any issues with CT validation? 8. The spec implies, but doesn't clearly describe, especially in S3.1, that the hashes are "labels" for tree entries, and that given a leaf hash, the log implementation should be able to look up and present the LogEntry data defined in that section. 9. Validating an SCT presummably requires having the Log Service's public key, yes? This isn't clearly discussed, and also the mention of how one obtains a log service's public key is out of scope is buried in 2nd para of S4 -- it should be discussed in a separate clearly entitled subsection. 10. Unless I'm totally missing it, there isn't an explicit description of how one (eg a TLS client) goes about validating/verifying an SCT. Various overall comments: -------------------------- O-1. The phrase "this experiment" is used in S2.1 -- should describing this as an experiment be more explicitly done in the abstract and introduction sections? What about the document title? O-2. Should explicitly say in abstract and introduction that operationally, the logs are to be materialized as (experimental?) network services having the protocol operations for submissions and queries that are defined in this spec. O-3. The bare term "client" is used in various places where either the term "log client" or "TLS client" is being implied -- these should be made explicit. Also the roles of log clients and TLS clients should be more thoroughly presented/explored, in part because they can intersect. O-4. These things seem to be duplicate names: "root hash" and "Merkle Tree Hash (MTH)" "Tree Head Signature" and "Signed Tree Head (STH)" ..which makes parsing the spec more difficult than if one name is used consistently for each. O-5. The terms "leaf certificate" and "final certificate" appear to be used where.. End Entity certificate final End Entity certificate ..would be clearer and more consistent with TLS and PKIX terminology, and perhaps less confusing with the terms "leaf" and "leaf node" which are used when discussing the Merkle trees and their components. O-6. I found the "history tree" paper (aka "[1]", cited here as [CrosbyWallach]) helpful in understanding how such trees are constructed, perhaps it should be more prominently mentioned. Plus the differences between the two algorithms should perhaps be more explicitly mentioned. E.g. in [CrosbyWallach] version-n tree stores n+1 inputs, while in CT a version-n tree (D[n]) stores n inputs. [CrosbyWallach] O-7. The note mentioning "dummy leaves" in [CrosbyWallach] seems misleading. The difference is AFAICT that in [CrosbyWallach] all nodes at layer 1 and above (leaf entries are at layer 0), are "interior nodes", and have hashes created using 0x01. Thus in a tree with an odd number of entries (ie leaf nodes at layer 0), there will be one leaf node under an interior node having only that one child. It's not that there is a "dummy leaf", it's that such an interior node's hash is constructed from just one child rather than two. While in CT, if the input set is an odd number of entries, then the hash of the final single leaf is at layer 1, and is calculated as a leaf hash using 0x00. Thus CT "interior nodes" always have two children, but if the tree has an odd number of entries, the rightmost hash at layer 1 ("j" in the "binary Merkle tree with 7 leaves" figure) is a leaf node hash rather than an interior node hash. O-8. [CrosbyWallach] discusses auditing and gossiping and could be cited as a source for further discussion on those topics. O-9. The notion of "commitments" isn't well defined, and where "add a commitment to D[k:n]" couldn't "add an interior/intermediate node to D[k:n}" be used? Is not the term "commitment" used in [CrosbyWallach] equivalent to the sha256_root_hash (an STH component) in the spec? [CrosbyWallach] uses the term "interior node(s)" while the spec uses "intermediate nodes" (in one place). O-10. The recursive algorithms in S2 are dense and take effort to work through, perhaps adding simplistic example code (in an appendix) which implements, and/or actually working through the algorithms to arrive at some of the audit paths and consistency proofs in S2.1.3, would be helpful. I desk-checked S2.1, and it seems correct, but didn't do S2.1.1 or S2.1.2. The examples in S2.1.3 appear nominally correct but I didn't desk check them. Should there be a reference to ? And/or a note regarding available code and to contact the authors for more information? (as is done in RFC 2154) O-11. S3.3 should mention the Maximum Merge Delay MMD where it says "periodically append". Also, in S3.3, "Signed Merkle Tree Update" should be a "Tree Head Signature" aka "signed tree head (STH)"? O-12. S3.3, S3.4, S4.4, S4.5, and S4.7 mention the notion of logs "publishing" STHs, but no mechanism is described for explicitly "publishing". Is this meant to mean only that a "published" STH is available for retrieval by clients using the "Retrieve Latest Signed Tree Head" log client message? Or, would there be a use case, eg introducing an existing log service to a log monitor, for requesting (or being able to enumerate) all published STHs from the log? O-13. signed tree heads (STHs) are denoted in terms of "tree size" (number of entries), but SCTs are denoted in terms of a timestamp. Should there be a log client message supporting the return of the nearest STH (and thus tree size) to a given timestamp? O-14. Detailed comments on S2... ------------------------------ > 2. Cryptographic components > > > 2.1. Merkle Hash Trees > > > Logs use a binary Merkle hash tree for efficient auditing. The > hashing algorithm is SHA-256 (note that this is fixed for this > experiment but it is anticipated that each log would be able to > specify a hash algorithm). The input to the Merkle tree hash is a > list of data entries; these entries will be hashed to form the leaves > of the Merkle hash tree. The output is a single 32-byte root hash. > Given an ordered list of n inputs, D[n] = {d(0), d(1), ..., d(n-1)}, > the Merkle Tree Hash (MTH) is thus defined as follows: > > The hash of an empty list is the hash of an empty string: > > MTH({}) = SHA-256(). This MTH({}) construct doesn't appear to be used anywhere else in the spec (yes?), and so does it really need mentioning? > The hash of a list with one entry is: > > MTH({d(0)}) = SHA-256(0x00 || d(0)). The immediately above equation is for leaf entries (yes?), where in this notation n = 1, perhaps it should be stated explicitly: When n = 1, a leaf entry is denoted, and D[1] = {d(0)}. The leaf hash (LH) for a leaf entry is calculated as: MTH(D[1]) = LH(D[1]) = SHA-256( 0x00 || d(0) ) > For n > 1, let k be the largest power of two smaller than n. The unqualified "power of two" phrase is arguably ambiguous. Suggested rephrase for this where it occurs throughout section 2.. For n > 1, let k be a number which is the largest power of two such that k = 2^i, 0 <= i < n, and k < n. > The Merkle Tree Hash of an n-element list D[n] is then defined > recursively as The above statement applies to the combination of the n = 1 equation above and the equation below, and so should perhaps be moved up above the n = 1 equation. > MTH(D[n]) = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n])), > > where || is concatenation and D[k1:k2] denotes the length (k2 - k1) > list {d(k1), d(k1+1),..., d(k2-1)}. The above phrase doesn't parse well and is somewhat ambiguous, here it is extracted for clarity: "D[k1:k2] denotes the length (k2 - k1) list {d(k1), d(k1+1),..., d(k2-1)}" How about rephrasing it along the lines of this: D[k1:k2] denotes a sublist {d(k1), d(k1+1),..., d(k2-1)}, having (k2 - k1) elements, of the original input list D[n]. When (k2 - k1) is 1, a leaf hash is calculated. (Note that the hash calculation > for leaves and nodes differ. This domain separation is required to > give second preimage resistance.) > > Note that we do not require the length of the input list to be a > power of two. The resulting Merkle tree may thus not be balanced, > however, its shape is uniquely determined by the number of leaves. > [This Merkle tree is essentially the same as the history tree [1] > proposal, except our definition omits dummy leaves.] I suggest re-writing the first above Note along with the next paragraph in light of all above comments on S2 and [CrosbyWallach]. O-15. Some comments on S3: ------------------------------------ > 3. Log Format this section isn't just about "format" of log - it's also about log behavior/operation > Anyone can submit certificates to certificate logs for public > auditing, however, since certificates will not be accepted by clients > unless logged, it is expected that certificate owners or their CAs > will usually submit them. A log is a single, ever-growing, append- > only Merkle Tree of such certificates. > > When a valid certificate is submitted to a log, the log MUST > immediately return a Signed Certificate Timestamp (SCT). The SCT is > the log's promise to incorporate the certificate in the Merkle Tree > within a fixed amount of time known as the Maximum Merge Delay (MMD). > If the log has previously seen the certificate, it MAY return the > same SCT as it returned before. What if the submitted end entity cert is the same, but the certificate chain is different (yet valid)? > TLS servers MUST present an SCT from > one or more logs to the client together with the certificate. TLS > clients MUST reject certificates that do not have a valid SCT for the > end-entity certificate. [ see comment (7) above ] > Periodically, each log appends all its new entries to the Merkle > Tree, and signs the root of the tree. Clients and auditors can thus Should "Clients and auditors" actually be "TLS Clients, log monitors, and log auditors" ? > verify that each certificate for which an SCT has been issued indeed > appears in the log. Add forward reference here to S4 and S5 ? > The log MUST incorporate a certificate in its > Merkle Tree within the Maximum Merge Delay period after the issuance > of the SCT. > > Logs MUST NOT impose any conditions on copying data retrieved from > the log. s/copying data retrieved/retrieving or sharing data/ > 3.1. Log Entries > > > Anyone can submit a certificate to any log. In order to enable > attribution of each logged certificate to its issuer, the log SHALL > publish a list of acceptable root certificates (this list might > usefully be the union of root certificates trusted by major browser > vendors). Each submitted certificate MUST be accompanied by all > additional certificates required to verify the certificate chain up > to an accepted root certificate. The root certificate itself MAY be > omitted from this list. > > Alternatively, (root as well as intermediate) Certificate Authorities Additionally? which manner is the experiment going to operate, or is it TBD ? > may submit a certificate to logs prior to issuance. To do so, a > Certificate Authority constructs a Precertificate by adding a special > critical poison extension (OID 1.3.6.1.4.1.11129.2.4.3, whose > extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)) to the > leaf TBSCertificate (this extension is to ensure that the leaf == end entity ? s/leaf certificate/end entity certificate/g ? > Precertificate cannot be validated by a standard X.509v3 client), and > signing the resulting TBSCertificate [RFC5280] with either > o a special-purpose (Extended Key Usage: Certificate Transparency, > OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing Certificate. > The Precertificate Signing Certificate MUST be certified by the CA > certificate that will ultimately sign the leaf TBSCertificate "sign the leaf TBSCertificate" means to say "sign the actual issued-to-the-customer TBSCertificate component of the End Entity certificate" ? > (note that the log may relax standard validation rules to allow > this, so long as the final signed certificate will be valid), > > o or, the CA certificate that will sign the final certificate. "final certificate" is the "issued-to-the-customer End Entity certificate" ? > Structure of the Signed Certificate Timestamp: The SCT discussion here should probably be its own subsection. > > enum { certificate_timestamp(0), tree_hash(1), 255 } > SignatureType; > > enum { v1(0), 255 } > Version; > > struct { > opaque key_id[32]; > } LogID; > > opaque CtExtensions<0..2^16-1>; > > "key_id" is the SHA-256 hash of the log's public key, calculated over > the DER encoding of the key represented as SubjectPublicKeyInfo. I'd place the above paragraph regarding "key_id" down below the SignedCertificateTimestamp definition. > struct { > Version sct_version; > LogID id; > uint64 timestamp; > CtExtensions extensions; > digitally-signed struct { > Version sct_version; > SignatureType signature_type = certificate_timestamp; > uint64 timestamp; > LogEntryType entry_type; > select(entry_type) { > case x509_entry: ASN.1Cert; > case precert_entry: ASN.1Cert; > } signed_entry; > CtExtensions extensions; > }; > } SignedCertificateTimestamp; > > The encoding of the digitally-signed element is defined in [RFC5246]. I would add a few words here summarizing that what happens here is that the digitally-signed struct here is replaced in the actual serialized binary structure by a struct DigitallySigned and cross-ref to S4.7 of RFC5246. > 3.2. Including the Signed Certificate Timestamp in the TLS Handshake This should be it's own top-level section as mentioned in comment (3). > The SCT data from at least one log must be included in the TLS > handshake, either by using an Authorization Extension [RFC5878] with > type 182, or by using OCSP Stapling (section 8 of [RFC6066]), add to above sentence: or by embedding the the SCT(s) in the presented End Entity cert, > where > the response includes an OCSP extension with OID > 1.3.6.1.4.1.11129.2.4.5 (see [RFC2560]) and body: > > SignedCertificateTimestampList ::= OCTET STRING > > At least one SCT MUST be included. Server operators MAY include more > than one SCT. > > Similarly, a Certificate Authority MAY submit the precertificate to s/the precertificate/a precertificate/ > more than one log, and all obtained SCTs can be directly embedded in > the final certificate, by encoding the SignedCertificateTimestampList s/final certificate/actual End Entity certificate/ ? > structure as an ASN.1 OCTET STRING and inserting the resulting data > in the TBSCertificate as an X.509v3 certificate extension (OID > 1.3.6.1.4.1.11129.2.4.2). Upon receiving the certificate, clients > can reconstruct the original TBSCertificate to verify the SCT > signature. This last step of "clients can reconstruct the original TBSCertificate" probably should be more thoroughly explained. O-15. Some comments on S4: --------------------------- > 4. Client Messages title should be "Log Client Messages" ? > Messages are sent as HTTPS GET or POST requests. Parameters for > POSTs and all responses are encoded as JSON objects. Parameters for s/JSON objects/JSON texts/ see (it should be cited) > GETs are encoded as URL parameters. Binary data is base64 encoded as > specified in the individual messages. > > The prefix can include a path as well as a server name > and a port. It must map one-to-one to a known public key (how this > mapping is distributed is out of scope for this document). s/distributed/constructed and distributed/ ? > In general, where needed, the "version" is v1 and the "id" is the log > id for the log server queried. > 4.1. Add Chain to Log > > > POST https:///ct/v1/add-chain > > Inputs > > chain An array of base64 encoded certificates. The first element is a JSON text array? > the leaf certificate, the second chains to the first and so on to > the last, which is either the root certificate or a certificate > that chains to a known root certificate. > > Outputs > > sct_version The version of the SignedCertificateTimestamp structure, > in decimal. A compliant v1 implementation MUST NOT expect this to > be 0 (i.e. v1). > > id The log ID, base64 encoded. Since clients who request an SCT for s/clients/log clients/ ? > inclusion in the TLS handshake are not required to verify it, we s/the TLS handshake/subsequent TLS handshakes/ ? > do not assume they know the ID of the log. > > timestamp The SCT timestamp, in decimal. > > extensions An opaque type for future expansion. It is likely that > not all participants will need to understand data in this field. > Logs should set this to the empty string. Clients should decode > the base64 encoded data and include it in the SCT. > > signature The SCT signature, base64 encoded. "The SCT signature" means a SignedCertificateTimestamp structure ? > > If the "sct_version" is not v1, then a v1 client may be unable to > verify the signature. It MUST NOT construe this as an error. [Note: > log clients don't need to be able to verify this structure, only TLS > clients do - if we were to serve the structure binary, then we could > completely change it without requiring an upgrade to v1 clients]. Does this "if we were to serve the structure binary...." statement mean to say that since v1 log clients don't need to be able to verify the SCT signature over the various returned data items, that this operation could instead return an opaque binary blob? O-16. Some comments on S5: --------------------------- > 5. Clients > > > There are various different functions clients of logs might perform. Perhaps this section should be entitled "Log Client Roles" ? this section doesn't mention the role of a (CA) log client that submits "certs and cert chains" to logs. Even though the latter role is mentioned elsewhere in the spec it should perhaps be mentioned here also. > 5.1. Monitor > > > Monitors watch logs and check that they behave correctly. They also > watch for certificates of interest. "Monitor" should be "Log Monitor" ? > > 5.2. Auditor > > > Auditors take partial information about a log as input and verify > that this information is consistent with other partial information > they have. An auditor might be an integral component of a TLS > client, it might be a standalone service or it might be a secondary > function of a monitor. "Auditor" should be "Log Auditor" ? > 8. Efficiency Considerations > > > The Merkle tree design serves the purpose of keeping communication > overhead low. > > Auditing logs for integrity does not require third parties to > maintain a copy of each entire log. The Signed Tree Heads can be > updated as new entries become available, without recomputing entire > trees. Third party auditors need only fetch the Merkle consistency > proofs against a log's existing STH to efficiently verify the append- > only property of updates to their Merkle Trees, without auditing the > entire tree. The above could be explained in more detail, and S5.1 should be cross-referenced. Is the last sentence above essentially a summary of step #8 in S5.1? Or are there differences? --- end From carl@redhoundsoftware.com Mon Jan 7 06:04:29 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265BA21F86F7 for ; Mon, 7 Jan 2013 06:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38ndBUaWO24p for ; Mon, 7 Jan 2013 06:04:27 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA7D121F8732 for ; Mon, 7 Jan 2013 06:04:27 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so12529563qca.3 for ; Mon, 07 Jan 2013 06:04:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=o0+7yzpG3tepMAEEEic/wYPB0Ddshz66M9OaS5MTVmc=; b=dckFP5Qs0CFhvbnuba4j/pn565kx+x/JUiC1rvXvdTJdi1ZBvT4MWsrFS/50Fit5mv 63CK39gZYWRbiAUSXMqNTeEGN1/5KqlJwTKtsjPQG6VdNp7L+72oFc/ZANoF7IMTtEkq bQtiqDhnnZL/4AR7teVNzkmk8sQN/brr9n3GZKLzGHNuTOSWE5yz/70+4rHOEs6YUFwV zY7w9R+k5SMBd2baMZ2MHdqsiXqimcIVwtgBqr2QwLZwRXRCtUEMBp450lxySXMOjjkb 6D2CDtkTflsUwnLLQ55hjfThiVRGc2Xqsvb68uq4uUYdtVmINz9qFqPV6anv0bv640o3 8hEg== X-Received: by 10.224.9.65 with SMTP id k1mr43392079qak.10.1357567466875; Mon, 07 Jan 2013 06:04:26 -0800 (PST) Received: from [192.168.2.3] (pool-173-79-110-220.washdc.fios.verizon.net. [173.79.110.220]) by mx.google.com with ESMTPS id v10sm20551424qaa.15.2013.01.07.06.04.25 (version=SSLv3 cipher=OTHER); Mon, 07 Jan 2013 06:04:26 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 07 Jan 2013 09:04:24 -0500 From: Carl Wallace To: Message-ID: Thread-Topic: some CT questions/comments Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQkQA+QaHuo2elS+ihRwpLSUhkbRPDZFGTcNVOkwyC9k4DJPf6a7FMEh+wktfs6cAzvp3SZz Subject: [therightkey] some CT questions/comments X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 14:04:29 -0000 Here are a few questions/comments on draft-laurie-pki-sunlight-05. - In section 2.1.4, should algorithm requirements be stated using RFC2119 language? - In section 3.2, why would multiple SCTs be included in a handshake - for sct version diversity, for log signer diversity, for certification path diversity, something else? Is there any required relationship between sct included in a handshake and certificates returned in the handshake? - In section 4, what key is subject to the "one-to-one" mapping - the server's TLS key or the log signing key? I am assuming these are different keys and it means the log signing key, but this could made more clear. In either case, why is this mapping necessary? Given only the key ID appears in the sct, verification occurs with no knowledge of which prefix was employed. Why impose a different requirement for these API calls? The requirement interferes with mirroring log contents at a different prefix. - In 4.1, if multiple clients submit the same certificate, is the same sct signature returned to each? What if the path is different for different submissions? What should occur if the certificate contains log data already? Should it matter to a server operator if a certificate is already present in the log when he attempts to add the certificate to a log (probably not but this may be worth noting)? - In 4.1, what is the output when the log refuses to log a certificate presented by a client? Generally, all of the section 4 sections would benefit from discussion of error returns. - In section 7.2, if a server operator wants to make sure there are no other certificates for names of interest, must the entire log be monitored? It'd be nice if there were a client message that took a domain name as input. Of course, this could probably be achieved by sticking an X.500 or LDAP interface on the log instead:-) Should a server operator take any steps if it finds a new sct that chains to a different root than the sct it includes in TLS handshakes? - In section 9, what does "new log" mean? Doesn't the spec already support key rollover by simply including a different path in the prefix? Why not just use that for key rollover and define a "log" as the /LogID pair? If you are thinking about supporting multiple keys under the same prefix, the one-to-one mapping requirement in section 4 should be removed. - I agree with JeffH regarding lack of TLS client (at a minimum) verification steps. - It would be helpful if each type of client with different functionality (log, TLS, audit, monitor) were introduced early in the document and if unqualified "client" references were identified by type. - Having a client message to retrieve roots recognized by the log would be nice, to avoid having a client repeatedly attempt to submit certificates to the log that will be rejected. From benl@google.com Tue Jan 8 09:54:13 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC5111E80EE for ; Tue, 8 Jan 2013 09:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jadF61woe0aJ for ; Tue, 8 Jan 2013 09:54:10 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id DB2C621F85C3 for ; Tue, 8 Jan 2013 09:54:09 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id r6so571183wey.38 for ; Tue, 08 Jan 2013 09:54:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=il9sSMkxMTnkX6x3l0wpDb1HWnKd9cbymzRxCIcOwAQ=; b=NSLybn6GocImTIvJfhC6oaijKrnU05pnsvyehD+ykhI7eTqd7ahSgnSXZoiwjBz7x0 ZSOO682XkExcHLzVyauc4l/q+x3MxfNnHWrEYWz8McGwUNRoobRdIXxnD6wyZiggFdtN Ul7slZ2qvXgviox3n7Pz49Tok/lpHchldm+yFUB9rj+bF6yI2VwIOvcHz9LlMIPhxRW3 vLpE8qOYHO4pVLDEJ7NXk3FrxCOyk52hzv5fb3emijhpmb22kpH8ZR9lItwjIrQwR+5E xQB9uiUxVf81QQQkzX/JSr2APC8Ius0VQ8pPEmSlg7l2+LB6kqk1OCKbO2rgwDNCeax1 vQsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=il9sSMkxMTnkX6x3l0wpDb1HWnKd9cbymzRxCIcOwAQ=; b=Nmk1htpdHrwXwn+o7BC8vuG9L56YSbL72ZhtrGjT9SG4WhN7Qj/Y+Ym6c6msyFi/If dLT7osCKd7w7P/rgbTF5ChyxzczRfznShaIJjVdGAos/xBqIngUFQlEzo0V2ch6A3lys nLnCGJ183Bk6TE5rn05gjpnrn8HwKLwkk2EMWrUroGQZJXRJ18Yaiwyr//b9ldjK5mw8 pFznERTwuXq/QVXg35xMmNrIWmLrmLAcPmr0awxOvAwAR/iYlz1WcFWezrdDUIMuv+A4 Cqd+JRLThj1Ag1OiiyiUyjmH5FFTQWPghulQIe6yZVY76EWKIItA0kx0v547uewrFwDK oNhA== MIME-Version: 1.0 Received: by 10.180.106.34 with SMTP id gr2mr16194827wib.18.1357667648747; Tue, 08 Jan 2013 09:54:08 -0800 (PST) Received: by 10.194.22.36 with HTTP; Tue, 8 Jan 2013 09:54:08 -0800 (PST) Date: Tue, 8 Jan 2013 17:54:08 +0000 Message-ID: From: Ben Laurie To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlikDEGYKjhh91LLR8i/1vqfDOYIqlQ4g8npKFOtg2oIRPdnOeT+3hGISYti+7lXJoZzDfUHRpzekVIPBHUCPZ7l/vzGUv4XJOzEJlfP/+nsLauvna1SH4U69geDhRUxb6n/7/ShMnfS/GmIBuYoon1K/8VJRyjwK7DRg4nhq3tFxcH+IFrV4NrdiZCqwVAVd+HZ+YQ Cc: Emilia Kasper , "therightkey@ietf.org" , IETF Discussion List , Adam Langley Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:54:13 -0000 On 1 January 2013 21:50, =JeffH wrote: > Hi, > > Here are some last call comments on draft-laurie-pki-sunlight-05. > > Overall the spec is in basically overall reasonable shape but I do have some > substantive comments that if I'm not totally misunderstanding things (which > could be the case) ought to be discussed and addressed in some fashion. > > The plain overall comments are to some degree "take 'em or leave 'em" > depending upon folks' sense of urgency to get the spec through the IETF > pipeline, but the degree likely depends upon the observer. > > I hope this is helpful, It is indeed, thankyou. > =JeffH > ------ > > comments on draft-laurie-pki-sunlight-05 > > substantive comments (in somewhat arbitrary order) > -------------------------------------------------- > > 1. The client messages S4 don't explicitly lay out the syntax for request > messages or responses. E.g., for S4.1 "Add Chain to Log", is the input a > stand-alone JSON text array, or a JSON text object containing a JSON text > array? > > The term "JSON object" as used in the first paragraph is ambiguous and > perhaps what is mean is simply "JSON texts" or "JSON text objects or JSON > text arrays". RFC4627 clearly defines "JSON text", and should be cited. But > RFC4627 is a little ambiguous itself regarding "JSON object" and so I > suggest these definitions: > > JSON text object: A JSON text matching the "object" ABNF production > in Section 2.2 of [RFC4627]. > > JSON text array: A JSON text matching the "array" ABNF production > in Section 2.3 of [RFC4627]. I agree that RFC 4627 should be cited and I will correct that. The rest of this confuses me: JSON is a textual representation of structured data, as it states in the RFC. It defines an object quite clearly " An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array." Defining a "JSON text object" seems pointless to me - clearly a JSON object is an object as defined by JSON, surely? Introducing another term seems like to add confusion rather than remove it. > > Also, the syntax for GETS isn't fully specified. Are the URL parameters to > be encoded as (order independent) key-value pairs, or just as > order-dependent values? Which separator character is to be used between > parameters? RFC3986 should be cited. RFC 3986 says nothing about parameter format, though - is there a standard reference for that? I've refereced HTML 4.01, but perhaps there's a better one? > Examples for both JSON text inputs and outputs, as well as URL parameters > would be helpful. Yes, we will provide some. > 2. "4. Client Messages" doesn't define error handling, i.e., responses to > inputs the log service doesn't understand and/or is unable to parse, and/or > have other errors. If the log service is to simply return a 4xx or 5xx error > code, this should at least be mentioned. For now, I will specify 4xx/5xx. We may have more to say once we've gained some experience. > 3. There appear to be three defined methods for TLS servers to provide TLS > clients with CT data, in S3.2. For this experiment, which approach is > mandatory to implement for servers and clients? Or, is it the case that > participating TLS clients (ie web browsers etc) implement all three methods, > and TLS servers can choose any of them? The latter. > > Also, S3.2 probably doesn't belong in S3 and perhaps should be a separate > top-level section on its own, and have three subsections, one for each > method. Maybe. > 4. "Leaf Hash" as used in S4.5 appears to be formally undefined. It > apparently would be: > > SHA-256(0x00 || MerkleTreeLeaf) > > ..it should also be noted in S3.3. You are right. > 5. The recursive equations in S2.1 describe how to calculate a Merkle Tree > Hash (MTH) (aka "root hash"), and thus as a side effect generate a Merkle > Tree, for a given set of input data. However, there doesn't seem to be a > defined algorithm (or even hints, really) for adding further inputs to an > existing tree. Even though this may be reasonably left as an exercise for > implementers, it should probably be discussed to some degree in the spec. > E.g., note that leaf hashes are "frozen" and various interior tree node > hashes become "frozen" as the tree grows. Is it not sub-optimal to employ > the obvious default brute-force mechanism of rebuilding a tree entirely from > scratch when new inputs are available? Would not a recursive algorithm for > adding new inputs to an existing tree be straightforward to provide? I dunno about straightforward. I'll think about it. > 6. Signed tree heads (STHs) are denoted in terms of "tree size" (number of > entries), but SCTs are denoted in terms of a timestamp. Should there be a > log client message supporting the return of the nearest STH (and thus tree > size) to a given timestamp? I'm not sure why? Any STH (that includes that SCT) will do. > 7. S3 paragraph 2 states that "TLS clients MUST reject certificates that do > not have a valid SCT for the end-entity certificate" (i.e., hard-fail). > Presummably this requirement is only for TLS clients participating in the CT > experiment and that understand this protocol. Of course - what other way could it be? In other words, all RFCs can only say what implementations that conform with them do. > This, or whatever the > requirement actually is, should be further explained. ? > For example, does the simple presence of SCT(s) in the TLS handshake serve > to signal to participating TLS clients that hard-fail is expected if there > are any issues with CT validation? We are not saying what action a client should take when it rejects a certificate, as is, I believe the usual practice. > 8. The spec implies, but doesn't clearly describe, especially in S3.1, that > the hashes are "labels" for tree entries, and that given a leaf hash, the > log implementation should be able to look up and present the LogEntry data > defined in that section. We actually only require an entry to be retrievable by hash (in effect) for the message in 4.7, which we (at least currently) label as a debugging message - so I am not sure that logs really are required to be able to do that - certainly the system would work fine if they couldn't, I believe (other than being unable to provide the debugging data). > 9. Validating an SCT presummably requires having the Log Service's public > key, yes? This isn't clearly discussed, and also the mention of how one > obtains a log service's public key is out of scope is buried in 2nd para of > S4 -- it should be discussed in a separate clearly entitled subsection. Good point. > > > 10. Unless I'm totally missing it, there isn't an explicit description of > how one (eg a TLS client) goes about validating/verifying an SCT. Indeed, fixing that also fixes the above point. > Various overall comments: > -------------------------- > > O-1. The phrase "this experiment" is used in S2.1 -- should describing this > as an experiment be more explicitly done in the abstract and introduction > sections? What about the document title? The plan is this will be an Experimental RFC, which seems clear enough to me? > O-2. Should explicitly say in abstract and introduction that operationally, > the logs are to be materialized as (experimental?) network services having > the protocol operations for submissions and queries that are defined in this > spec. Seems a little redundant, but I have added something anyway. > > > O-3. The bare term "client" is used in various places where either the term > "log client" or "TLS client" is being implied -- these should be made > explicit. Also the roles of log clients and TLS clients should be more > thoroughly presented/explored, in part because they can intersect. Section 5 "Clients" is an attempt to document the various client roles, one or more of which may be embodied by any particular client implementation, rather than try to deal with this intersection. I have gone over mentions of "client" elsewhere to try to deal with your point, though. Sometimes it just means "any client" so not all instances have been changed. > > > O-4. These things seem to be duplicate names: > > "root hash" and "Merkle Tree Hash (MTH)" Yes, > > "Tree Head Signature" and "Signed Tree Head (STH)" These are not the same - you are probably confused by the digitally-signed struct, which is only used as input for a signature and never appears in its own right. However, we haven't been super clear about what's going on here and I've tried to clean that up. > > ..which makes parsing the spec more difficult than if one name is used > consistently for each. > > > O-5. The terms "leaf certificate" and "final certificate" appear to be used > where.. > > End Entity certificate > > final End Entity certificate > > ..would be clearer and more consistent with TLS and PKIX terminology, and > perhaps less confusing with the terms "leaf" and "leaf node" which are used > when discussing the Merkle trees and their components. Good point. > O-6. I found the "history tree" paper (aka "[1]", cited here as > [CrosbyWallach]) helpful in understanding how such trees are constructed, > perhaps it should be more prominently mentioned. Plus the differences > between the two algorithms should perhaps be more explicitly mentioned. E.g. > in [CrosbyWallach] version-n tree stores n+1 inputs, while in CT a version-n > tree (D[n]) stores n inputs. > > [CrosbyWallach] > > > O-7. The note mentioning "dummy leaves" in [CrosbyWallach] seems misleading. > The difference is AFAICT that in [CrosbyWallach] all nodes at layer 1 and > above (leaf entries are at layer 0), are "interior nodes", and have hashes > created using 0x01. Thus in a tree with an odd number of entries (ie leaf > nodes at layer 0), there will be one leaf node under an interior node having > only that one child. It's not that there is a "dummy leaf", it's that such > an interior node's hash is constructed from just one child rather than two. Not sure I really agree with this, but in any case I have reworded it slightly. I've also changed the reference to be a "proper" one, shown at the end of the I-D. > While in CT, if the input set is an odd number of entries, then the hash of > the final single leaf is at layer 1, and is calculated as a leaf hash using > 0x00. Thus CT "interior nodes" always have two children, but if the tree has > an odd number of entries, the rightmost hash at layer 1 ("j" in the "binary > Merkle tree with 7 leaves" figure) is a leaf node hash rather than an > interior node hash. > > > O-8. [CrosbyWallach] discusses auditing and gossiping and could be cited as > a source for further discussion on those topics. > > > O-9. The notion of "commitments" isn't well defined, and where "add a > commitment to D[k:n]" couldn't "add an interior/intermediate node to > D[k:n}" be used? > > Is not the term "commitment" used in [CrosbyWallach] equivalent to the > sha256_root_hash (an STH component) in the spec? > > [CrosbyWallach] uses the term "interior node(s)" while the spec uses > "intermediate nodes" (in one place). CT is not actually derived from [CrosbyWallach], we just mention it as a useful reference. "commitment" is a term of cryptographic art. > O-10. The recursive algorithms in S2 are dense and take effort to work > through, perhaps adding simplistic example code (in an appendix) which > implements, and/or actually working through the algorithms to arrive at some > of the audit paths and consistency proofs in S2.1.3, would be helpful. We have actual working code - would a reference to that be better? > I desk-checked S2.1, and it seems correct, but didn't do S2.1.1 or S2.1.2. > The examples in S2.1.3 appear nominally correct but I didn't desk check > them. > > Should there be a reference to > ? And/or a note > regarding available code and to contact the authors for more information? > (as is done in RFC 2154) I couldn't find such a thing in RFC 2154. My only concern about such a reference is whether it would live as long as the RFC does :-) > O-11. S3.3 should mention the Maximum Merge Delay MMD where it says > "periodically append". Also, in S3.3, "Signed Merkle Tree Update" should be > a "Tree Head Signature" aka "signed tree head (STH)"? I just removed that, as it is immediately repeated in the next section. > > > O-12. S3.3, S3.4, S4.4, S4.5, and S4.7 mention the notion of logs > "publishing" STHs, but no mechanism is described for explicitly > "publishing". Is this meant to mean only that a "published" STH is available > for retrieval by clients using the "Retrieve Latest Signed Tree Head" log > client message? > > Or, would there be a use case, eg introducing an existing log service to a > log monitor, for requesting (or being able to enumerate) all published STHs > from the log? I don't believe there is: the latest STH tells you everything you need to know at that point. I have removed mention of publishing. > > > O-13. signed tree heads (STHs) are denoted in terms of "tree size" (number > of entries), but SCTs are denoted in terms of a timestamp. Should there be > a log client message supporting the return of the nearest STH (and thus tree > size) to a given timestamp? I don't believe this is needed. > > > > O-14. Detailed comments on S2... > ------------------------------ > >> 2. Cryptographic components >> >> >> 2.1. Merkle Hash Trees >> >> >> Logs use a binary Merkle hash tree for efficient auditing. The >> hashing algorithm is SHA-256 (note that this is fixed for this >> experiment but it is anticipated that each log would be able to >> specify a hash algorithm). The input to the Merkle tree hash is a >> list of data entries; these entries will be hashed to form the leaves >> of the Merkle hash tree. The output is a single 32-byte root hash. >> Given an ordered list of n inputs, D[n] = {d(0), d(1), ..., d(n-1)}, >> the Merkle Tree Hash (MTH) is thus defined as follows: >> >> The hash of an empty list is the hash of an empty string: >> >> MTH({}) = SHA-256(). > > > This MTH({}) construct doesn't appear to be used anywhere else in the spec > (yes?), and so does it really need mentioning? If it is not defined, then we cannot represent an empty tree. >> The hash of a list with one entry is: >> >> MTH({d(0)}) = SHA-256(0x00 || d(0)). > > > The immediately above equation is for leaf entries (yes?), Yes. > where in this > notation n = 1, perhaps it should be stated explicitly: > > When n = 1, a leaf entry is denoted, and D[1] = {d(0)}. The leaf hash > (LH) for a leaf entry is calculated as: > > MTH(D[1]) = LH(D[1]) = SHA-256( 0x00 || d(0) ) Ugh. LH(D[1]) seems meaningless to me. A leaf hash is always of a "1 entry tree". > > > >> For n > 1, let k be the largest power of two smaller than n. > > > The unqualified "power of two" phrase is arguably ambiguous. It is? > Suggested rephrase for this where it occurs throughout section 2.. > > For n > 1, let k be a number which is the largest power of two > such that k = 2^i, 0 <= i < n, and k < n. If we're going to go down that path, then it should say: For n > 1, let k be the largest number such that k = 2^i and k < n. or For n > 1, let k = 2^i s.t. k < n and 2k >= n. surely? >> The Merkle Tree Hash of an n-element list D[n] is then defined >> recursively as > > > The above statement applies to the combination of the n = 1 equation above > and the equation below, and so should perhaps be moved up above the n = 1 > equation. ? It says n > 1, so doesn't apply to n = 1? >> MTH(D[n]) = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n])), >> >> where || is concatenation and D[k1:k2] denotes the length (k2 - k1) >> list {d(k1), d(k1+1),..., d(k2-1)}. > > > The above phrase doesn't parse well and is somewhat ambiguous, here it is > extracted for clarity: > > "D[k1:k2] denotes the length (k2 - k1) list {d(k1), d(k1+1),..., d(k2-1)}" > > > How about rephrasing it along the lines of this: > > D[k1:k2] denotes a sublist {d(k1), d(k1+1),..., d(k2-1)}, having > (k2 - k1) elements, of the original input list D[n]. When (k2 - k1) > is 1, a leaf hash is calculated. We tried lots of different ways of saying this and they were all a little messy. Yours mixes concerns and is rather verbose, so not convinced it is actually an improvement. > > > (Note that the hash calculation >> >> for leaves and nodes differ. This domain separation is required to >> give second preimage resistance.) >> >> Note that we do not require the length of the input list to be a >> power of two. The resulting Merkle tree may thus not be balanced, >> however, its shape is uniquely determined by the number of leaves. >> [This Merkle tree is essentially the same as the history tree [1] >> proposal, except our definition omits dummy leaves.] > > > I suggest re-writing the first above Note along with the next paragraph in > light of all above comments on S2 and [CrosbyWallach]. It was already partly rewritten as a result of above comments, so let's see how you like the next version? > O-15. Some comments on S3: > ------------------------------------ > >> 3. Log Format > > > this section isn't just about "format" of log - it's also about log > behavior/operation Good point. > > >> Anyone can submit certificates to certificate logs for public >> auditing, however, since certificates will not be accepted by clients >> unless logged, it is expected that certificate owners or their CAs >> will usually submit them. A log is a single, ever-growing, append- >> only Merkle Tree of such certificates. >> >> When a valid certificate is submitted to a log, the log MUST >> immediately return a Signed Certificate Timestamp (SCT). The SCT is >> the log's promise to incorporate the certificate in the Merkle Tree >> within a fixed amount of time known as the Maximum Merge Delay (MMD). >> If the log has previously seen the certificate, it MAY return the >> same SCT as it returned before. > > > What if the submitted end entity cert is the same, but the certificate chain > is different (yet valid)? The purpose of the chain is to: a) Prevent spam, and b) Identify who to blame in the event of a misissue. Alternate chains presumably don't actually change the direct blame, and so I see no reason to do other than what the I-D says - i.e. return the same SCT as before. >> TLS servers MUST present an SCT from >> one or more logs to the client together with the certificate. TLS >> clients MUST reject certificates that do not have a valid SCT for the >> end-entity certificate. > > > [ see comment (7) above ] > > >> Periodically, each log appends all its new entries to the Merkle >> Tree, and signs the root of the tree. Clients and auditors can thus > > > Should "Clients and auditors" actually be "TLS Clients, log monitors, and > log auditors" ? Bearing in mind that these are actually roles rather than distinct entities, it should probably just say "auditors". > > >> verify that each certificate for which an SCT has been issued indeed >> appears in the log. > > > Add forward reference here to S4 and S5 ? > > > >> The log MUST incorporate a certificate in its >> Merkle Tree within the Maximum Merge Delay period after the issuance >> of the SCT. >> >> Logs MUST NOT impose any conditions on copying data retrieved from >> the log. > > > s/copying data retrieved/retrieving or sharing data/ OK. >> 3.1. Log Entries >> >> >> Anyone can submit a certificate to any log. In order to enable >> attribution of each logged certificate to its issuer, the log SHALL >> publish a list of acceptable root certificates (this list might >> usefully be the union of root certificates trusted by major browser >> vendors). Each submitted certificate MUST be accompanied by all >> additional certificates required to verify the certificate chain up >> to an accepted root certificate. The root certificate itself MAY be >> omitted from this list. >> >> Alternatively, (root as well as intermediate) Certificate Authorities > > > Additionally? which manner is the experiment going to operate, or is it TBD > ? Not sure what you mean? The log will accept either type of submission. >> may submit a certificate to logs prior to issuance. To do so, a >> Certificate Authority constructs a Precertificate by adding a special >> critical poison extension (OID 1.3.6.1.4.1.11129.2.4.3, whose >> extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)) to the >> leaf TBSCertificate (this extension is to ensure that the > > > leaf == end entity ? > > s/leaf certificate/end entity certificate/g ? Yes. >> Precertificate cannot be validated by a standard X.509v3 client), and >> signing the resulting TBSCertificate [RFC5280] with either > > > >> o a special-purpose (Extended Key Usage: Certificate Transparency, >> OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing Certificate. >> The Precertificate Signing Certificate MUST be certified by the CA >> certificate that will ultimately sign the leaf TBSCertificate > > > "sign the leaf TBSCertificate" means to say "sign the actual > issued-to-the-customer TBSCertificate component of the End Entity > certificate" ? Well, it means something like that, I have added some words. > >> (note that the log may relax standard validation rules to allow >> this, so long as the final signed certificate will be valid), >> >> o or, the CA certificate that will sign the final certificate. > > > "final certificate" is the "issued-to-the-customer End Entity certificate" ? I have changed this to "issued certificate". > > >> Structure of the Signed Certificate Timestamp: > > > The SCT discussion here should probably be its own subsection. OK. > > >> >> enum { certificate_timestamp(0), tree_hash(1), 255 } >> SignatureType; >> >> enum { v1(0), 255 } >> Version; > >> >> >> struct { >> opaque key_id[32]; >> } LogID; >> >> opaque CtExtensions<0..2^16-1>; >> >> "key_id" is the SHA-256 hash of the log's public key, calculated over >> the DER encoding of the key represented as SubjectPublicKeyInfo. > > > I'd place the above paragraph regarding "key_id" down below the > SignedCertificateTimestamp definition. > > >> struct { >> Version sct_version; >> LogID id; >> uint64 timestamp; >> CtExtensions extensions; >> digitally-signed struct { >> Version sct_version; >> SignatureType signature_type = certificate_timestamp; >> uint64 timestamp; >> LogEntryType entry_type; >> select(entry_type) { >> case x509_entry: ASN.1Cert; >> case precert_entry: ASN.1Cert; >> } signed_entry; >> CtExtensions extensions; >> }; >> } SignedCertificateTimestamp; >> >> The encoding of the digitally-signed element is defined in [RFC5246]. > > > I would add a few words here summarizing that what happens here is that the > digitally-signed struct here is replaced in the actual serialized binary > structure by a struct DigitallySigned and cross-ref to S4.7 of RFC5246. Except it isn't :-) And we already reference RFC5246. >> 3.2. Including the Signed Certificate Timestamp in the TLS Handshake > > > This should be it's own top-level section as mentioned in comment (3). > > >> The SCT data from at least one log must be included in the TLS >> handshake, either by using an Authorization Extension [RFC5878] with >> type 182, or by using OCSP Stapling (section 8 of [RFC6066]), > > > add to above sentence: > > or by embedding the the SCT(s) in the presented End Entity cert, Addressed earlier. >> where >> the response includes an OCSP extension with OID >> 1.3.6.1.4.1.11129.2.4.5 (see [RFC2560]) and body: >> >> SignedCertificateTimestampList ::= OCTET STRING >> >> At least one SCT MUST be included. Server operators MAY include more >> than one SCT. >> >> Similarly, a Certificate Authority MAY submit the precertificate to > > > s/the precertificate/a precertificate/ Yes. >> more than one log, and all obtained SCTs can be directly embedded in >> the final certificate, by encoding the SignedCertificateTimestampList > > > s/final certificate/actual End Entity certificate/ ? Addressed earlier. >> structure as an ASN.1 OCTET STRING and inserting the resulting data >> in the TBSCertificate as an X.509v3 certificate extension (OID >> 1.3.6.1.4.1.11129.2.4.2). Upon receiving the certificate, clients >> can reconstruct the original TBSCertificate to verify the SCT >> signature. > > > This last step of "clients can reconstruct the original TBSCertificate" > probably should be more thoroughly explained. Yeah, it probably should. > O-15. Some comments on S4: > --------------------------- > > >> 4. Client Messages > > > title should be "Log Client Messages" ? Yes. >> Messages are sent as HTTPS GET or POST requests. Parameters for >> POSTs and all responses are encoded as JSON objects. Parameters for > > > s/JSON objects/JSON texts/ I don't agree with this. See above. > see (it should be cited) > >> GETs are encoded as URL parameters. Binary data is base64 encoded as >> specified in the individual messages. >> >> The prefix can include a path as well as a server name >> and a port. It must map one-to-one to a known public key (how this >> mapping is distributed is out of scope for this document). > > > s/distributed/constructed and distributed/ ? > > >> In general, where needed, the "version" is v1 and the "id" is the log >> id for the log server queried. > > > > > >> 4.1. Add Chain to Log >> >> >> POST https:///ct/v1/add-chain >> >> Inputs >> >> chain An array of base64 encoded certificates. The first element is > > > a JSON text array? It is already defined to be a field in a JSON object and hence that is all it could be. >> the leaf certificate, the second chains to the first and so on to >> the last, which is either the root certificate or a certificate >> that chains to a known root certificate. >> >> Outputs >> >> sct_version The version of the SignedCertificateTimestamp structure, >> in decimal. A compliant v1 implementation MUST NOT expect this to >> be 0 (i.e. v1). >> >> id The log ID, base64 encoded. Since clients who request an SCT for > > > s/clients/log clients/ ? That seems obvious, but I have added it anyway. >> inclusion in the TLS handshake are not required to verify it, we > > > s/the TLS handshake/subsequent TLS handshakes/ ? > > > >> do not assume they know the ID of the log. >> >> timestamp The SCT timestamp, in decimal. >> >> extensions An opaque type for future expansion. It is likely that >> not all participants will need to understand data in this field. >> Logs should set this to the empty string. Clients should decode >> the base64 encoded data and include it in the SCT. >> >> signature The SCT signature, base64 encoded. > > > "The SCT signature" means a SignedCertificateTimestamp structure ? No, the signature that is a component of the structure. >> If the "sct_version" is not v1, then a v1 client may be unable to >> verify the signature. It MUST NOT construe this as an error. [Note: >> log clients don't need to be able to verify this structure, only TLS >> clients do - if we were to serve the structure binary, then we could >> completely change it without requiring an upgrade to v1 clients]. > > > Does this "if we were to serve the structure binary...." statement mean to > say that since v1 log clients don't need to be able to verify the SCT > signature over the various returned data items, that this operation could > instead return an opaque binary blob? Indeed. > O-16. Some comments on S5: > --------------------------- > > >> 5. Clients >> >> >> There are various different functions clients of logs might perform. > > > Perhaps this section should be entitled "Log Client Roles" ? Since you persuaded me to include TLS clients, no :-) > this section doesn't mention the role of a (CA) log client that submits > "certs and cert chains" to logs. Even though the latter role is mentioned > elsewhere in the spec it should perhaps be mentioned here also. OK. > > >> 5.1. Monitor >> >> >> Monitors watch logs and check that they behave correctly. They also >> watch for certificates of interest. > > > "Monitor" should be "Log Monitor" ? There's no other kind of monitor :-) > >> >> 5.2. Auditor >> >> >> Auditors take partial information about a log as input and verify >> that this information is consistent with other partial information >> they have. An auditor might be an integral component of a TLS >> client, it might be a standalone service or it might be a secondary >> function of a monitor. > > > "Auditor" should be "Log Auditor" ? And there's no other kind of auditor. > > > >> 8. Efficiency Considerations >> >> >> The Merkle tree design serves the purpose of keeping communication >> overhead low. >> >> Auditing logs for integrity does not require third parties to >> maintain a copy of each entire log. The Signed Tree Heads can be >> updated as new entries become available, without recomputing entire >> trees. Third party auditors need only fetch the Merkle consistency >> proofs against a log's existing STH to efficiently verify the append- >> only property of updates to their Merkle Trees, without auditing the >> entire tree. > > > The above could be explained in more detail, and S5.1 should be > cross-referenced. Is the last sentence above essentially a summary of step > #8 in S5.1? Or are there differences? It is a summary of 5.1 > > > --- > end > > From benl@google.com Wed Jan 9 04:35:51 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5106621F87D5 for ; Wed, 9 Jan 2013 04:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Au+Vts+mvEd3 for ; Wed, 9 Jan 2013 04:35:50 -0800 (PST) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6AB21F87D4 for ; Wed, 9 Jan 2013 04:35:49 -0800 (PST) Received: by mail-vb0-f48.google.com with SMTP id fc21so1466135vbb.35 for ; Wed, 09 Jan 2013 04:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ZRHxLddY9UvLbzmAMupaTthrnUc5PZZrkehc4yoxGeY=; b=KyilebkhXaBhpYE6NF/fWbKC6euo+hUF81otrroCxAx+KTjlm7K3GaZNxG33zHCWr0 n5zqdCn5RE3qCPBnjC5Dvi4gacwbXgMJLuzn1ZkkxwpOAU2M8hpWuNTjI8FR3/u3q7Cd eCbDwjzlMCPBxNBzlqcvwAgpHdUXeDsEI3j+P959D/4+h67T3m4owGIXzQRyZEZI6w6C OAl32ufOXud/go/FSvPA3210MReE5zllJ6mU+84fyO7TqUBEeWaXuIyxXx7uTB5nPqqz Ee+A46PVHQOHhHHIq76IfsgHVLtIhOiZKEpeML6R376c08wmE47ap8OMcYfSu1PTWbyg Imiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=ZRHxLddY9UvLbzmAMupaTthrnUc5PZZrkehc4yoxGeY=; b=o59e59rrmPjD1k/74ULHJDOC4Mba/rwL6Yiq6ynWho+EdLIvhhtVBDXbffC4qqLkbo XWJpUjMTuCwox3WJnmcI3iPNnWTaqSWPND3R7xXVp4uYmS7lpcXiOL4ykQiKmSzM8gA+ yl76kHI5iqPKA564vh093Y5P3ThHqu1kb7Iqp6YTgM/GT2q7gtDk2eCuH+UdgmKO6yHj JhX2gDG4ZIi3DEYUh2e9cFXKTtLBGJuHjyBxaxsLQ1ujTKp8npujTmpWjU0fIf8YLk7Y TgBbla4TETIiHjwx7jd2zotxh8Vw+8H4Ls3JbYeJaRBDJ34Idt05KW3hVtKjCjCrCYE2 269w== MIME-Version: 1.0 Received: by 10.52.175.106 with SMTP id bz10mr76486313vdc.125.1357734948945; Wed, 09 Jan 2013 04:35:48 -0800 (PST) Received: by 10.220.252.72 with HTTP; Wed, 9 Jan 2013 04:35:48 -0800 (PST) Date: Wed, 9 Jan 2013 12:35:48 +0000 Message-ID: From: Ben Laurie To: Carl Wallace Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm0GJvjkc86NMQyw/a6sfwyvVWoZDnWxX2H2CQwAGSrnkx0Rgd50uxnnH4oVZCHwo7WLb4sXksJYeIRZOAl75Q/G+CBh7vvuPKb6ZwCp9sovMYH4yqmmi86Hte608IE4uVKp9YiBFa1heWGnG7hkG3yR1zfLHqNr9ziQFnrJ0tjD0SU+SS3c1sX0aRjQ0I8huUZtXYg Cc: "therightkey@ietf.org" Subject: Re: [therightkey] some CT questions/comments X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 12:35:51 -0000 On 7 January 2013 14:04, Carl Wallace wrote: > Here are a few questions/comments on draft-laurie-pki-sunlight-05. > > - In section 2.1.4, should algorithm requirements be stated using RFC2119 > language? Yes. > - In section 3.2, why would multiple SCTs be included in a handshake - for > sct version diversity, for log signer diversity, for certification path > diversity, something else? To increase the chance that one of the SCTs is valid (i.e. the log is still accepted by the client). > Is there any required relationship between sct > included in a handshake and certificates returned in the handshake? I'm not sure what you mean? The SCT has to be for the end entity certificate. > > - In section 4, what key is subject to the "one-to-one" mapping - the > server's TLS key or the log signing key? I am assuming these are > different keys and it means the log signing key, but this could made more > clear. Yes. > In either case, why is this mapping necessary? Given only the key > ID appears in the sct, verification occurs with no knowledge of which server> prefix was employed. Why impose a different requirement for these > API calls? The requirement interferes with mirroring log contents at a > different prefix. Hmmm. Good point. > - In 4.1, if multiple clients submit the same certificate, is the same sct > signature returned to each? This is addressed in 3. "If the log has previously seen the certificate, it MAY return the same SCT as it returned before" > What if the path is different for different > submissions? Only the end entity certificate is used to make the SCT. > What should occur if the certificate contains log data > already? Nothing special, I think? i.e. it is just part of the data in the certificate. > Should it matter to a server operator if a certificate is > already present in the log when he attempts to add the certificate to a > log (probably not but this may be worth noting)? I guess that depends what the provenance of the cert is, not sure I have anything intelligent to say about that. > - In 4.1, what is the output when the log refuses to log a certificate > presented by a client? Generally, all of the section 4 sections would > benefit from discussion of error returns. Already addressed. > - In section 7.2, if a server operator wants to make sure there are no > other certificates for names of interest, must the entire log be > monitored? Yes. > It'd be nice if there were a client message that took a domain > name as input. That is a service a monitor could provide to its clients. > Of course, this could probably be achieved by sticking an > X.500 or LDAP interface on the log instead:-) Should a server operator > take any steps if it finds a new sct that chains to a different root than > the sct it includes in TLS handshakes? I don't know, but I also don't think CT is a chain discovery mechanism, just an end entity cert discovery mechanism. > - In section 9, what does "new log" mean? Doesn't the spec already > support key rollover by simply including a different path in the server> prefix? Why not just use that for key rollover and define a "log" > as the /LogID pair? If you are thinking about supporting > multiple keys under the same prefix, the one-to-one mapping > requirement in section 4 should be removed. The note is there in response to a previous comment - in short, we haven't really decided what to do, but my inclination was as you say - define the log by its log id (I don't really see what the cost is for a log server operator to start a new log compared to key rollover - if, indeed, they even get a second chance). > - I agree with JeffH regarding lack of TLS client (at a minimum) > verification steps. Agreed,. > - It would be helpful if each type of client with different functionality > (log, TLS, audit, monitor) were introduced early in the document and if > unqualified "client" references were identified by type. Its a bit tricky, since that would cause forward references to how they perform their function - which would,. no doubt, lead to suggestions that we should put the messages and log structure earlier in the document... Client references have been qualified anyway. > - Having a client message to retrieve roots recognized by the log would be > nice, to avoid having a client repeatedly attempt to submit certificates > to the log that will be rejected. Good idea, I can add one. > > > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From carl@redhoundsoftware.com Sat Jan 12 12:14:12 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B14521F8853 for ; Sat, 12 Jan 2013 12:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjnyRE4+AQBc for ; Sat, 12 Jan 2013 12:14:12 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id CD13821F884F for ; Sat, 12 Jan 2013 12:14:11 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i20so638152qad.17 for ; Sat, 12 Jan 2013 12:14:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=4uS2ySNsu+5WxCEJOTtZ7wsqA2uYAJG3r43nJO3YE38=; b=XfvJbplHQNXtk4kTGSZ5RO14A8+i9lRlZXDWYOBNdV4P9ODpFA/1oS9q1OgRMK37zN /gO7Th4DXjQQnWwY2rtx9XK9xATEd/dx8swQcbiDypXfD52bm2AL6iTE0foTz41ZdXbK tyYMkGWs3l10fayRDDE+2rWJWgjjadOsrsBdWrOoNeXVALaRpdWGvTBPILPsrmyN7mp4 focfDNcydHsUeoFneIb9VBEqFQEfjHTPnbM4XOl6T4qYzawADck8Y6b1rRvtetPJNQNd ozE8gdPjd4gOz1oy076RSrDSqo/0GstbMjrWyWdg73VluyVv6RgA1dSjQK5YjyxSFXPZ nN3Q== X-Received: by 10.224.209.193 with SMTP id gh1mr30307070qab.86.1358021651003; Sat, 12 Jan 2013 12:14:11 -0800 (PST) Received: from [172.16.42.47] (pool-70-108-218-74.washdc.east.verizon.net. [70.108.218.74]) by mx.google.com with ESMTPS id ds8sm5235450qab.18.2013.01.12.12.14.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 12 Jan 2013 12:14:10 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Sat, 12 Jan 2013 15:14:05 -0500 From: Carl Wallace To: Ben Laurie Message-ID: Thread-Topic: [therightkey] some CT questions/comments In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQkScnRk53z0ymfU0vuupDBK75/aFQ2x+uZoHcveo6ydCMrtmCgK5jCmcX+CazX96y+p8JTD Cc: "therightkey@ietf.org" Subject: Re: [therightkey] some CT questions/comments X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 20:14:12 -0000 On 1/9/13 7:35 AM, "Ben Laurie" wrote: >> Is there any required relationship between sct >> included in a handshake and certificates returned in the handshake? > >I'm not sure what you mean? The SCT has to be for the end entity >certificate. OK. I drifted in and out of recognizing the SCT only has the EE while the messages to the server have the path. >> - In 4.1, if multiple clients submit the same certificate, is the same >>sct >> signature returned to each? > >This is addressed in 3. "If the log has previously seen the >certificate, it MAY return the same SCT as it returned before" Missed that. Thanks. Why not MUST? > >> What if the path is different for different >> submissions? > >Only the end entity certificate is used to make the SCT. This could be made clear. Seems like the log really doesn't care (or need to care) about multiple paths to an EE. Once it has an EE, the same SCT can be used. > >> It'd be nice if there were a client message that took a domain >> name as input. > >That is a service a monitor could provide to its clients. That makes sense. > >> Of course, this could probably be achieved by sticking an >> X.500 or LDAP interface on the log instead:-) Should a server operator >> take any steps if it finds a new sct that chains to a different root >>than >> the sct it includes in TLS handshakes? > >I don't know, but I also don't think CT is a chain discovery >mechanism, just an end entity cert discovery mechanism. Got it. From benl@google.com Sun Jan 13 05:30:56 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A115E21F870E for ; Sun, 13 Jan 2013 05:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVEtOPcHs3+D for ; Sun, 13 Jan 2013 05:30:56 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id DC19321F8707 for ; Sun, 13 Jan 2013 05:30:54 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hn3so731526wib.5 for ; Sun, 13 Jan 2013 05:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=60rYPu2NlwPK979ElqdWOwSyX3Suc+r1fR+GiEXtpsw=; b=AkdjvyPVRvL3epXgtneobcZ9I08hulery1lH78DsPrQB3+GHMYDYuVFOS6qxezmqxO qsDew0RqFnqKM57Amklq7JmWUclv5ZPEMFYNs/U9AJckaHRb38o35hwYJYK0Tsj62RTf H36P1aL6GrclpnA67NCQBLfARjy9qFS8NZYUl2HDQTpftdgL/RTXQfDih2Srg7cC5MRY VKiFbA/OsblHeYcZw3te8xJWsaPcwuTeTXQYaxeoQ9ABuJqfc/tluxEvv98MZ7J7nNjE OZv9o4fhqAGt+S6o6GZenqyRre3PRwhsXKB0NZapEGF88JRjD2rmclBrvbuZ9s09nuYU 9/Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=60rYPu2NlwPK979ElqdWOwSyX3Suc+r1fR+GiEXtpsw=; b=ZJ5QJWf+FTdtKsXa61jO4JW3xh44rcjMpR69jPfqpSxzEdTgHLRDoT30/cuiX6K8wq VvNe5dnFXxToAb+IQ8LqC45AS1r/4kbhd3LR50nidgHKG18RsznE0LdKGeEBqsm9FJGl ydgfLWYeLsXxfZMni3y9ZziURlvQhqbfp88NC4enuc9vrsl+g+06kc+rQdCtYSqnM0zc y7E5Z4QxIwUI00cjYOrIc7aip6eT5K7B62m8jNhv4j/214pdmq2od3ndfKiBPNJyTqjp CljVF8LyaL+UdY7mfrMJEyT57eOE/epGSNSv/tIBeh65vzb0spCuP9mORfuxniGhUm55 icLg== MIME-Version: 1.0 Received: by 10.194.5.74 with SMTP id q10mr130619677wjq.13.1358083853734; Sun, 13 Jan 2013 05:30:53 -0800 (PST) Received: by 10.194.234.134 with HTTP; Sun, 13 Jan 2013 05:30:53 -0800 (PST) In-Reply-To: References: Date: Sun, 13 Jan 2013 13:30:53 +0000 Message-ID: From: Ben Laurie To: Carl Wallace Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnSXvpXRV+wriHXOzUel621XAGeB29WGFgCtvngwyN2irTo42g9bXOCxN/hdRv5ShQhYxyGQZWxv6p/egfKNj+LgCAAV5lmpDqaxZpd2S4Ql+QIOTSYb2aK1H+DFtgsKTnveqUh725i/wxXBNLLLqSP1ajJ6Noa6nMNXsNamzgoOAnxOJs0sLqlH/YuHeKknhn//8I7 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] some CT questions/comments X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 13:30:56 -0000 On 12 January 2013 20:14, Carl Wallace wrote: >>> - In 4.1, if multiple clients submit the same certificate, is the same >>>sct >>> signature returned to each? >> >>This is addressed in 3. "If the log has previously seen the >>certificate, it MAY return the same SCT as it returned before" > > Missed that. Thanks. Why not MUST? It makes it harder to build reliable infrastructure. From stephen.farrell@cs.tcd.ie Mon Jan 14 03:31:08 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516F021F8607 for ; Mon, 14 Jan 2013 03:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGChYWb8OKoN for ; Mon, 14 Jan 2013 03:31:07 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 615D921F85FD for ; Mon, 14 Jan 2013 03:31:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C968CBE3B; Mon, 14 Jan 2013 11:30:45 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rvssf8PJeBAi; Mon, 14 Jan 2013 11:30:41 +0000 (GMT) Received: from [IPv6:2001:770:10:203:fc59:2c8:a489:8ef3] (unknown [IPv6:2001:770:10:203:fc59:2c8:a489:8ef3]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B517DBE1E; Mon, 14 Jan 2013 11:30:35 +0000 (GMT) Message-ID: <50F3EC5C.3070109@cs.tcd.ie> Date: Mon, 14 Jan 2013 11:30:36 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "therightkey@ietf.org" References: <6.2.5.6.2.20130110065213.0ad01a90@resistor.net> In-Reply-To: <6.2.5.6.2.20130110065213.0ad01a90@resistor.net> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <6.2.5.6.2.20130110065213.0ad01a90@resistor.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SM Subject: [therightkey] Fwd: Re: Last Call: (Certificate Transparency) to Experimental RFC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 11:31:08 -0000 FYI. Some comments sent just to the IETF list. Please respond there. Thanks, S. -------- Original Message -------- Subject: Re: Last Call: (Certificate Transparency) to Experimental RFC Date: Thu, 10 Jan 2013 09:10:32 -0800 From: SM To: ietf@ietf.org At 11:33 20-12-2012, The IESG wrote: >The IESG has received a request from an individual submitter to consider >the following document: >- 'Certificate Transparency' > as Experimental RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2013-01-24. Exceptionally, comments may be In Section 1: "Certificate Transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, append-only, untrusted logs of all issued certificates." It seems that CAs are having trust issues. ETSI TS 102 042 audits looks like paperwork instead of assessing what could go wrong [1]. Isn't Certificate Transparency trying to mitigate the problem of CAs issuing fake certificates instead of "misissued" certificates? In Section 3: "Logs MUST NOT impose any conditions on copying data retrieved from the log." I am reading the above as meaning that the data retrieved is in the public domain. Is that correct? The wording could be improved as logs do not have any consciousness. In Section 3.1: "In order to enable attribution of each logged certificate to its issuer, the log SHALL publish a list of acceptable root certificates (this list might usefully be the union of root certificates trusted by major browser vendors)." Why is this a "SHALL" instead of a "MUST"? I suggest a better wording for "log" in the above as "log" is defined as "a single, ever-growing, append-only Merkle Tree of such certificates". There are other occurrences of "log" in the draft that should be reviewed. In Section 4: "Messages are sent as HTTPS GET or POST requests. Parameters for POSTs and all responses are encoded as JSON objects. I suggest adding a reference for JSON objects. "It must map one-to-one to a known public key (how this mapping is distributed is out of scope for this document)." This looks like a requirement. "A compliant v1 implementation MUST NOT expect this to be 0 (i.e. v1)." What happens if the v1 implementation gets a zero? In Section 7.3: "Violation of the append-only property is detected by global gossiping, i.e., everyone auditing logs comparing their versions of the latest signed tree heads." In my humble opinion that's a practical approach. Section 7 is about security and privacy considerations. I didn't see any privacy considerations in Section 7. I don't think that it is really needed as the document is about publicly auditable logs. If there is any concern about information disclosure it could be mentioned that Certificate Transparency is for public end-entities. Regards, -sm 1. Confirm that there are automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks in 2011) From benl@google.com Mon Jan 14 06:38:19 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC5921F86F8 for ; Mon, 14 Jan 2013 06:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnxElO6OdBDj for ; Mon, 14 Jan 2013 06:38:19 -0800 (PST) Received: from mail-wi0-x229.google.com (wi-in-x0229.1e100.net [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id EB4F821F858A for ; Mon, 14 Jan 2013 06:38:18 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id hq12so1320359wib.0 for ; Mon, 14 Jan 2013 06:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YlwDiyN3XCYFkKreTjtU0GUr5gHzPBFdSzfZ96NxeNo=; b=ouN1X9mUV9XA5zsfu+jbXH0/fWzhfq0oEU1YGv/cJOMOFWFVoLXTIel15x7O8fc830 Ld4hcENzKpPcMIRD0cjUHPx1CQ4s7fAYD+wUrzTGP9KEin6v7L7FUhbSlH0vBNAU93wJ zHAUHKaGPcsn63HhJBxXugsAsRKtpNOAXdgGtWqJLmMoQTVJVKvBv2cs/wuYP0vFiQ1v oyepmsEmAI+IAB24WvWtASknPfeSQQe0LwhxOn8gt3Sy4gb5kr7OUG8AUed2qAauiWWB oaM6SipN2FkcSm8yJubnfZxGXWb9tYXKftL+6EzFOVX7rIzqfuXuAxAo4VG8CUaoRjaU v5GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=YlwDiyN3XCYFkKreTjtU0GUr5gHzPBFdSzfZ96NxeNo=; b=RXIcW8ZWGy7gRG9ZO8+uhreUq8fV7VBeQ77+0X/OZg3gS4gy0gK74cErFnCEdRfg+M usbV0OosWpEL+inp0DqfUjomEyrgNSxHghm9mbP5ArJcKbvY2T1s9IDIn7VCuYGjB4Iu IfV6/wt7MjWfnmQ+tEI1n2VSoFd8bWK++oHwkhHX2eelFVjN2coX7BsOYy7t9JtiFeTX Bt4XWoGOMqtV+WnFfN1LHGk3ENh7/7okvoghDc5ge6tutFRUNDHXOdEXIzyH6HxagGzb zqAKMhHlYd3PawrxeIDn4ORGOJDICYzhyZkkdGG3UDMkkl0hjaN0UPPYWERY/Xohy9Ht R38g== MIME-Version: 1.0 Received: by 10.180.97.68 with SMTP id dy4mr12889651wib.7.1358174297945; Mon, 14 Jan 2013 06:38:17 -0800 (PST) Received: by 10.194.29.195 with HTTP; Mon, 14 Jan 2013 06:38:17 -0800 (PST) In-Reply-To: <50F3EC5C.3070109@cs.tcd.ie> References: <6.2.5.6.2.20130110065213.0ad01a90@resistor.net> <50F3EC5C.3070109@cs.tcd.ie> Date: Mon, 14 Jan 2013 14:38:17 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell , IETF Discussion List Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlloSkkIAL8a0Wn7y432nIYWhMVMx+rHYNGTqLwAifVX/KNIDNuOMoDE+BKRGOMz7gWVxxWyN5XMgXNTsd/QCta2mVyDkvuF+fdpA1OkTR4RQ/HMZLwVUG8eGOgMo/f5zw8aJ7u+ydasDA4gp8IdAYv/d5jq/Zrat5pOYzWvnYc5+dwmLJmOc/EO251Cf/aF99nRiZg Cc: SM , "therightkey@ietf.org" Subject: Re: [therightkey] Fwd: Re: Last Call: (Certificate Transparency) to Experimental RFC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:38:20 -0000 On 14 January 2013 11:30, Stephen Farrell wrote: > > FYI. Some comments sent just to the IETF list. Please > respond there. > > Thanks, > S. > > > -------- Original Message -------- > Subject: Re: Last Call: (Certificate > Transparency) to Experimental RFC > Date: Thu, 10 Jan 2013 09:10:32 -0800 > From: SM > To: ietf@ietf.org > > At 11:33 20-12-2012, The IESG wrote: >>The IESG has received a request from an individual submitter to consider >>the following document: >>- 'Certificate Transparency' >> as Experimental RFC >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send substantive comments to the >>ietf@ietf.org mailing lists by 2013-01-24. Exceptionally, comments may be > > In Section 1: > > "Certificate Transparency aims to mitigate the problem of misissued > certificates by providing publicly auditable, append-only, untrusted > logs of all issued certificates." > > It seems that CAs are having trust issues. ETSI TS 102 042 audits > looks like paperwork instead of assessing what could go wrong > [1]. Isn't Certificate Transparency trying to mitigate the problem > of CAs issuing fake certificates instead of "misissued" certificates? Is there a difference, when you get down to it? > > In Section 3: > > "Logs MUST NOT impose any conditions on copying data retrieved from > the log." > > I am reading the above as meaning that the data retrieved is in the > public domain. Is that correct? Yes. This is necessary for auditing/monitoring. > The wording could be improved as > logs do not have any consciousness. I have changed it to "Log operators..." > > In Section 3.1: > > "In order to enable attribution of each logged certificate to its > issuer, the log SHALL publish a list of acceptable root certificates > (this list might usefully be the union of root certificates trusted > by major browser vendors)." > > Why is this a "SHALL" instead of a "MUST"? MUST and SHALL are equivalent. > I suggest a better > wording for "log" in the above as "log" is defined as "a single, > ever-growing, append-only Merkle Tree of such certificates". There > are other occurrences of "log" in the draft that should be reviewed. What wording do you suggest that would be better? > In Section 4: > > "Messages are sent as HTTPS GET or POST requests. Parameters for > POSTs and all responses are encoded as JSON objects. > > I suggest adding a reference for JSON objects. There will be in the next version. > "It must map one-to-one to a known public key (how this > mapping is distributed is out of scope for this document)." > > This looks like a requirement. If it were a requirement it would say MUST - but in any case, it is gone in the next version. > "A compliant v1 implementation MUST NOT expect this to > be 0 (i.e. v1)." > > What happens if the v1 implementation gets a zero? I don't understand the question. > In Section 7.3: > > "Violation of the append-only property is detected by global gossiping, > i.e., everyone auditing logs comparing their versions of the latest > signed tree heads." > > In my humble opinion that's a practical approach. > > Section 7 is about security and privacy considerations. I didn't see > any privacy considerations in Section 7. Good point, I have renamed it. > I don't think that it is > really needed as the document is about publicly auditable logs. If > there is any concern about information disclosure it could be > mentioned that Certificate Transparency is for public end-entities. > > Regards, > -sm > > 1. Confirm that there are automatic blocks in place for high-profile > domain names (including those targeted in the DigiNotar and Comodo > attacks in 2011) > > > > > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From stephen.farrell@cs.tcd.ie Mon Jan 14 09:49:57 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6FD21F8901 for ; Mon, 14 Jan 2013 09:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.767 X-Spam-Level: X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujE9rg90elg5 for ; Mon, 14 Jan 2013 09:49:57 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAC321F8890 for ; Mon, 14 Jan 2013 09:49:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9E02FBE47 for ; Mon, 14 Jan 2013 17:49:21 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHWJoe8jY-nc for ; Mon, 14 Jan 2013 17:49:16 +0000 (GMT) Received: from [IPv6:2001:770:10:203:fc59:2c8:a489:8ef3] (unknown [IPv6:2001:770:10:203:fc59:2c8:a489:8ef3]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1EDD3BE35 for ; Mon, 14 Jan 2013 17:49:16 +0000 (GMT) Message-ID: <50F4451C.9080209@cs.tcd.ie> Date: Mon, 14 Jan 2013 17:49:16 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "therightkey@ietf.org" References: <20130114170944.18576.71566.idtracker@ietfa.amsl.com> In-Reply-To: <20130114170944.18576.71566.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <20130114170944.18576.71566.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [therightkey] Fwd: updated by Pearl Liang X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:49:58 -0000 Hi, IANA have a couple of questions [1] as to what they would do if this becomes and RFC. Probably best to figure on this list and make any changes at the end of IETF LC. S [1] http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/history/ -------- Original Message -------- Subject: updated by Pearl Liang Date: Mon, 14 Jan 2013 09:09:44 -0800 From: DraftTracker Mail System To: Stephen Farrell Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/ A new comment added by Pearl Liang From Jeff.Hodges@KingsMountain.com Mon Jan 21 19:12:03 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02ED221F85A2 for ; Mon, 21 Jan 2013 19:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzksIyQ9ruuk for ; Mon, 21 Jan 2013 19:12:02 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id B0B5221F8588 for ; Mon, 21 Jan 2013 19:11:51 -0800 (PST) Received: (qmail 27349 invoked by uid 0); 22 Jan 2013 03:11:27 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 22 Jan 2013 03:11:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=yoBVQjVkIn6KnMFBJ7sv9gF6m0/KqEfO9qov+J5ANWQ=; b=HB2hMVNSqDNBPY9m04qaCrxdjsPdzf5OPOIAI6jZ3VNBJ5whKH8OyuSl5NlbE/cRxQ8BXkbOG1OWSJzgxlIuCfrmmHWvvHT7RA6xnnOvHIMWyOBaAmjuy3y+F0GWFN+D; Received: from [24.4.122.173] (port=35782 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1TxUGj-0008Uo-JY; Mon, 21 Jan 2013 20:11:25 -0700 Message-ID: <50FE035C.4010808@KingsMountain.com> Date: Mon, 21 Jan 2013 19:11:24 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: Emilia Kasper , "therightkey@ietf.org" , IETF Discussion List , Adam Langley Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 03:12:03 -0000 apologies for latency, many meetings and a conference in the last couple of weeks. BenL replied: > On 1 January 2013 21:50, =JeffH wrote: [ in the below discussion: "the spec", "this spec" refers to draft-laurie-pki-sunlight-05. "TLS-CT client" refers to a TLS client capable of processing CT information that is included in the TLS handshake in any of the specified manners. "ok" means in general: "ok, will check this in next rev of the spec..". ] >> >> comments on draft-laurie-pki-sunlight-05 >> >> substantive comments (in somewhat arbitrary order) >> -------------------------------------------------- >> [ I demoted the comments wrt "JSON object" terminology and put them down at the end of this msg ] >> Also, the syntax for GETS isn't fully specified. Are the URL parameters to >> be encoded as (order independent) key-value pairs, or just as >> order-dependent values? Which separator character is to be used between >> parameters? RFC3986 should be cited. > > RFC 3986 says nothing about parameter format, though correct, it doesn't, and I wasn't trying to imply that it did, sorry. I was just trying to say that RFC3986 should be cited in this spec because this spec normatively employs URLs, but perhaps referencing RFC2616 HTTP is better because it defines "http_URL". > - is there a > standard reference for that? I've refereced HTML 4.01, but perhaps > there's a better one? hm, AFAICT, there is not a standard for URI query component formating and thus parameter encoding, so this spec will have to explicitly specify something. Section 3.4 of RFC3986 gives allowed chars for the query component, but that's about it. Have you mocked up code that parses the log client messages? If so, what query component syntax does it handle? >> 2. "4. Client Messages" doesn't define error handling, i.e., responses to >> inputs the log service doesn't understand and/or is unable to parse, and/or >> have other errors. If the log service is to simply return a 4xx or 5xx error >> code, this should at least be mentioned. > > For now, I will specify 4xx/5xx. We may have more to say once we've > gained some experience. Ok. >> 3. There appear to be three defined methods for TLS servers to provide TLS >> clients with CT data, in S3.2. For this experiment, which approach is >> mandatory to implement for servers and clients? Or, is it the case that >> participating TLS clients (ie web browsers etc) implement all three methods, >> and TLS servers can choose any of them? > > The latter. That should be made very clear. Is the reason for doing so to obtain operational experience wrt the three defined methods such that they perhaps can be narrowed down in the future, or is the expectation that TLS-CT clients will need to support all three methods in perpetuity? >> 4. "Leaf Hash" as used in S4.5 appears to be formally undefined. It >> apparently would be: >> >> SHA-256(0x00 || MerkleTreeLeaf) >> >> ..it should also be noted in S3.3. > > You are right. :) >> 5. The recursive equations in S2.1 describe how to calculate a Merkle Tree >> Hash (MTH) (aka "root hash"), and thus as a side effect generate a Merkle >> Tree, for a given set of input data. However, there doesn't seem to be a >> defined algorithm (or even hints, really) for adding further inputs to an >> existing tree. Even though this may be reasonably left as an exercise for >> implementers, it should probably be discussed to some degree in the spec. >> E.g., note that leaf hashes are "frozen" and various interior tree node >> hashes become "frozen" as the tree grows. Is it not sub-optimal to employ >> the obvious default brute-force mechanism of rebuilding a tree entirely from >> scratch when new inputs are available? Would not a recursive algorithm for >> adding new inputs to an existing tree be straightforward to provide? > > I dunno about straightforward. yeah, agreed. > I'll think about it. ok. At least providing some hints would be useful it seems. >> 6. Signed tree heads (STHs) are denoted in terms of "tree size" (number of >> entries), but SCTs are denoted in terms of a timestamp. Should there be a >> log client message supporting the return of the nearest STH (and thus tree >> size) to a given timestamp? > > I'm not sure why? Any STH (that includes that SCT) will do. Hm, it was sort of a gut feel that it might be useful, but perhaps not. S5.2. Auditor says.. A certificate accompanied by an SCT can be verified against any STH dated after the SCT timestamp + the Maximum Merge Delay by requesting a Merkle Audit Proof using Section 4.5. S4.5 get-proof-by-hash stipulates tree_size as an input, but if a log auditor doesn't already have tree_size, then I suppose it first calls S4.3 get-sth, which will return a timestamp and a tree_size, which if generated max merge delay (MMD) after the SCT was gen'd, ought to be sufficient, yes? I don't see in the spec where/how MMD is published. Does MMD vary per log service? The latter isn't stipulated in the spec it seems AFAICT ? >> 7. S3 paragraph 2 states that "TLS clients MUST reject certificates that do >> not have a valid SCT for the end-entity certificate" (i.e., hard-fail). >> Presummably this requirement is only for TLS clients participating in the CT >> experiment and that understand this protocol. > > Of course - what other way could it be? In other words, all RFCs can > only say what implementations that conform with them do. > >> This, or whatever the >> requirement actually is, should be further explained. I guess what I was getting at is that CT-conformant TLS clients should be differentiated from non-CT-conformant ones. Stipulating a name for CT-conformant TLS clients would clarify this (seems to me), e.g. "TLS-CT client" or something similar. >> For example, does the simple presence of SCT(s) in the TLS handshake serve >> to signal to participating TLS clients that hard-fail is expected if there >> are any issues with CT validation? > > We are not saying what action a client should take when it rejects a > certificate, as is, I believe the usual practice. Ok. >> 8. The spec implies, but doesn't clearly describe, especially in S3.1, that >> the hashes are "labels" for tree entries, and that given a leaf hash, the >> log implementation should be able to look up and present the LogEntry data >> defined in that section. > > We actually only require an entry to be retrievable by hash (in > effect) for the message in 4.7, which we (at least currently) label as > a debugging message - so I am not sure that logs really are required > to be able to do that - certainly the system would work fine if they > couldn't, I believe (other than being unable to provide the debugging > data). I think what I was getting at was that this is stated at the end of S3.2.. The leaves of the Merkle Tree are the hashes of the corresponding "MerkleTreeLeaf" structures. ..but it is somewhat confusing because (abstractly) each leaf also contains (or has a reference to) the LogEntry data (that's defined back in S3.1) ...if I understand this correctly. >> >> Various overall comments: >> -------------------------- >> >> O-1. The phrase "this experiment" is used in S2.1 -- should describing this >> as an experiment be more explicitly done in the abstract and introduction >> sections? What about the document title? > > The plan is this will be an Experimental RFC, which seems clear enough to me? well, lots of people don't perceive the difference between the various RFC tracks, and I'd be inclined to make it abundantly pedantically clear that this spec is documenting a particular actual experiment (modulo what the sponsoring AD thinks/advises (hi Stephen :) ) >> O-3. The bare term "client" is used in various places where either the term >> "log client" or "TLS client" is being implied -- these should be made >> explicit. Also the roles of log clients and TLS clients should be more >> thoroughly presented/explored, in part because they can intersect. > > Section 5 "Clients" is an attempt to document the various client > roles, one or more of which may be embodied by any particular client > implementation, rather than try to deal with this intersection. > > I have gone over mentions of "client" elsewhere to try to deal with > your point, though. Sometimes it just means "any client" so not all > instances have been changed. ok. >> O-4. These things seem to be duplicate names: >> >> "root hash" and "Merkle Tree Hash (MTH)" > > Yes, > >> >> "Tree Head Signature" and "Signed Tree Head (STH)" > > These are not the same - you are probably confused by the > digitally-signed struct, which is only used as input for a signature > and never appears in its own right. However, we haven't been super > clear about what's going on here and I've tried to clean that up. ok. >> O-6. I found the "history tree" paper (aka "[1]", cited here as >> [CrosbyWallach]) helpful in understanding how such trees are constructed, >> perhaps it should be more prominently mentioned. Plus the differences >> between the two algorithms should perhaps be more explicitly mentioned. E.g. >> in [CrosbyWallach] version-n tree stores n+1 inputs, while in CT a version-n >> tree (D[n]) stores n inputs. >> >> [CrosbyWallach] >> >> >> O-7. The note mentioning "dummy leaves" in [CrosbyWallach] seems misleading. >> The difference is AFAICT that in [CrosbyWallach] all nodes at layer 1 and >> above (leaf entries are at layer 0), are "interior nodes", and have hashes >> created using 0x01. Thus in a tree with an odd number of entries (ie leaf >> nodes at layer 0), there will be one leaf node under an interior node having >> only that one child. It's not that there is a "dummy leaf", it's that such >> an interior node's hash is constructed from just one child rather than two. > > Not sure I really agree with this, but in any case I have reworded it > slightly. I've also changed the reference to be a "proper" one, shown > at the end of the I-D. ok. >> While in CT, if the input set is an odd number of entries, then the hash of >> the final single leaf is at layer 1, and is calculated as a leaf hash using >> 0x00. Thus CT "interior nodes" always have two children, but if the tree has >> an odd number of entries, the rightmost hash at layer 1 ("j" in the "binary >> Merkle tree with 7 leaves" figure) is a leaf node hash rather than an >> interior node hash. >> >> >> O-8. [CrosbyWallach] discusses auditing and gossiping and could be cited as >> a source for further discussion on those topics. >> >> >> O-9. The notion of "commitments" isn't well defined, and where "add a >> commitment to D[k:n]" couldn't "add an interior/intermediate node to >> D[k:n}" be used? >> >> Is not the term "commitment" used in [CrosbyWallach] equivalent to the >> sha256_root_hash (an STH component) in the spec? >> >> [CrosbyWallach] uses the term "interior node(s)" while the spec uses >> "intermediate nodes" (in one place). > > CT is not actually derived from [CrosbyWallach], we just mention it as > a useful reference. yeah, it is useful, it would've been much harder to figure out the spec without it. Is there an existing paper that the spec is based more closely on? The differences between the spec and [CrosbyWallach] doesn't seem to be that large, and so if there aren't more closely matching paper(s) to cite (?), it may be worth summarizing the differences between the spec and [CrosbyWallach] e.g. in an appendix. > "commitment" is a term of cryptographic art. so it is, but its definitions in the literature seem to vary somewhat depending on context. IIUC, the spec uses "commitment" to refer to the hash labels of intermediate nodes ('interior nodes' in [CrosbyWallach]) as well as the root hash, yes? In S2.1.1, where it says.. We prove that the left subtree entries D[0:k] are consistent and add a commitment to D[k:n]: ..it's not clear just what "add a commitment" means. add it (an intermediate-node hash?) to the list of hashes that the recursive algorthm is constructing? Overall, I'm finding S2.1.1 pretty difficult to parse and sort out. E.g., it isn't clear to me how/why/when the apparently boolean 3d parameter of SUBPROOF is either true or false, and whether there's an implied "if b then ... else ..." in there somewhere. >> O-10. The recursive algorithms in S2 are dense and take effort to work >> through, perhaps adding simplistic example code (in an appendix) which >> implements, and/or actually working through the algorithms to arrive at some >> of the audit paths and consistency proofs in S2.1.3, would be helpful. > > We have actual working code - would a reference to that be better? I don't know if it would be better (I've compiled it and am poking through the code). I sorta think pseudo code in an appendix that would generate the trees in S2.1.3. would be helpful. >> I desk-checked S2.1, and it seems correct, but didn't do S2.1.1 or S2.1.2. >> The examples in S2.1.3 appear nominally correct but I didn't desk check >> them. >> >> Should there be a reference to >> ? And/or a note >> regarding available code and to contact the authors for more information? >> (as is done in RFC 2154) > > I couldn't find such a thing in RFC 2154. see end of S2 on page 4 of RFC2154. > My only concern about such a > reference is whether it would live as long as the RFC does :-) hence the desire to have pseudo code in spec :) >> O-11. S3.3 should mention the Maximum Merge Delay MMD where it says >> "periodically append". Also, in S3.3, "Signed Merkle Tree Update" should be >> a "Tree Head Signature" aka "signed tree head (STH)"? > > I just removed that, as it is immediately repeated in the next section. Ok. >> O-12. S3.3, S3.4, S4.4, S4.5, and S4.7 mention the notion of logs >> "publishing" STHs, but no mechanism is described for explicitly >> "publishing". Is this meant to mean only that a "published" STH is available >> for retrieval by clients using the "Retrieve Latest Signed Tree Head" log >> client message? >> >> Or, would there be a use case, eg introducing an existing log service to a >> log monitor, for requesting (or being able to enumerate) all published STHs >> from the log? > > I don't believe there is: the latest STH tells you everything you need > to know at that point. I have removed mention of publishing. ok. >> >> >> O-14. Detailed comments on S2... >> ------------------------------ >> >>> 2. Cryptographic components >>> >>> >>> 2.1. Merkle Hash Trees >>> >>> >>> Logs use a binary Merkle hash tree for efficient auditing. The >>> hashing algorithm is SHA-256 (note that this is fixed for this >>> experiment but it is anticipated that each log would be able to >>> specify a hash algorithm). The input to the Merkle tree hash is a >>> list of data entries; these entries will be hashed to form the leaves >>> of the Merkle hash tree. The output is a single 32-byte root hash. >>> Given an ordered list of n inputs, D[n] = {d(0), d(1), ..., d(n-1)}, >>> the Merkle Tree Hash (MTH) is thus defined as follows: >>> >>> The hash of an empty list is the hash of an empty string: >>> >>> MTH({}) = SHA-256(). >> >> >> This MTH({}) construct doesn't appear to be used anywhere else in the spec >> (yes?), and so does it really need mentioning? > > If it is not defined, then we cannot represent an empty tree. yeah, I agree from a mathematical completeness perspective. but I still found it sort of distracting in that I don't know that it's actually germane from an implementor's perspective. maybe it is because >>> The hash of a list with one entry is: >>> >>> MTH({d(0)}) = SHA-256(0x00 || d(0)). >> >> >> The immediately above equation is for leaf entries (yes?), > > Yes. > >> where in this >> notation n = 1, perhaps it should be stated explicitly: >> >> When n = 1, a leaf entry is denoted, and D[1] = {d(0)}. The leaf hash >> (LH) for a leaf entry is calculated as: >> >> MTH(D[1]) = LH(D[1]) = SHA-256( 0x00 || d(0) ) > > Ugh. LH(D[1]) seems meaningless to me. A leaf hash is always of a "1 > entry tree". yeah, for those who have grokked this stuff. for others it isn't immediately obvious. also, the above comment was motivated in part due to the missing formal definition for "Leaf Hash" noted in item (4) above. even if the LH(D[1]) notation isn't used, some additional prose along the lines suggested above would be helpful to less initiated readers imv. >>> For n > 1, let k be the largest power of two smaller than n. >> >> >> The unqualified "power of two" phrase is arguably ambiguous. > > It is? uh, yeah. but "let k be a number which is the largest power of two such that..." isn't. >> Suggested rephrase for this where it occurs throughout section 2.. >> >> For n > 1, let k be a number which is the largest power of two >> such that k = 2^i, 0 <= i < n, and k < n. > > If we're going to go down that path, then it should say: > > For n > 1, let k be the largest number such that k = 2^i and k < n. > > or > > For n > 1, let k = 2^i s.t. k < n and 2k >= n. > > surely? well, yes (i prefer the former), but i think it's also important to explicitly state 0 <= i < n > >>> The Merkle Tree Hash of an n-element list D[n] is then defined >>> recursively as >> >> >> The above statement applies to the combination of the n = 1 equation above >> and the equation below, and so should perhaps be moved up above the n = 1 >> equation. > > ? It says n > 1, so doesn't apply to n = 1? oh yeah huh. in any case, I found the prose separation of the "list with one entry" and the "n > 1" case to be confusing because the former is part of the recursive definition of MTH(), yes? >>> MTH(D[n]) = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n])), >>> >>> where || is concatenation and D[k1:k2] denotes the length (k2 - k1) >>> list {d(k1), d(k1+1),..., d(k2-1)}. >> >> >> The above phrase doesn't parse well and is somewhat ambiguous, here it is >> extracted for clarity: >> >> "D[k1:k2] denotes the length (k2 - k1) list {d(k1), d(k1+1),..., d(k2-1)}" >> >> >> How about rephrasing it along the lines of this: >> >> D[k1:k2] denotes a sublist {d(k1), d(k1+1),..., d(k2-1)}, having >> (k2 - k1) elements, of the original input list D[n]. When (k2 - k1) >> is 1, a leaf hash is calculated. > > We tried lots of different ways of saying this and they were all a > little messy. Yours mixes concerns and is rather verbose, so not > convinced it is actually an improvement. well, the way it's presently said in the spec is (to me) pretty darn hard to understand. which concerns are missed in the suggested reformulation? I tend to think concocting something not so terse would be a service to the reader/implementer. > >> >> >> (Note that the hash calculation >>> >>> for leaves and nodes differ. This domain separation is required to >>> give second preimage resistance.) >>> >>> Note that we do not require the length of the input list to be a >>> power of two. The resulting Merkle tree may thus not be balanced, >>> however, its shape is uniquely determined by the number of leaves. >>> [This Merkle tree is essentially the same as the history tree [1] >>> proposal, except our definition omits dummy leaves.] >> >> >> I suggest re-writing the first above Note along with the next paragraph in >> light of all above comments on S2 and [CrosbyWallach]. > > It was already partly rewritten as a result of above comments, so > let's see how you like the next version? ok. > >> O-15. Some comments on S3: >> ------------------------------------ >> >>> 3. Log Format >> >> >> this section isn't just about "format" of log - it's also about log >> behavior/operation > > Good point. > >> >> >>> Anyone can submit certificates to certificate logs for public >>> auditing, however, since certificates will not be accepted by clients >>> unless logged, it is expected that certificate owners or their CAs >>> will usually submit them. A log is a single, ever-growing, append- >>> only Merkle Tree of such certificates. >>> >>> When a valid certificate is submitted to a log, the log MUST >>> immediately return a Signed Certificate Timestamp (SCT). The SCT is >>> the log's promise to incorporate the certificate in the Merkle Tree >>> within a fixed amount of time known as the Maximum Merge Delay (MMD). >>> If the log has previously seen the certificate, it MAY return the >>> same SCT as it returned before. >> >> >> What if the submitted end entity cert is the same, but the certificate chain >> is different (yet valid)? > > The purpose of the chain is to: > > a) Prevent spam, and > > b) Identify who to blame in the event of a misissue. > > Alternate chains presumably don't actually change the direct blame, > and so I see no reason to do other than what the I-D says - i.e. > return the same SCT as before. ok. tho i wonder if there's any value in caching the alternate chain or the new portions thereof. >>> TLS servers MUST present an SCT from >>> one or more logs to the client together with the certificate. TLS >>> clients MUST reject certificates that do not have a valid SCT for the >>> end-entity certificate. >> >> >> [ see comment (7) above ] >> >> >>> Periodically, each log appends all its new entries to the Merkle >>> Tree, and signs the root of the tree. Clients and auditors can thus >> >> >> Should "Clients and auditors" actually be "TLS Clients, log monitors, and >> log auditors" ? > > Bearing in mind that these are actually roles rather than distinct > entities, it should probably just say "auditors". I dunno, that may loose some readers. in any case, the distinction between roles and distinct entities should probably be mentioned/discussed e.g. in the Introduction or thereabouts. >>> 3.1. Log Entries >>> >>> >>> Anyone can submit a certificate to any log. In order to enable >>> attribution of each logged certificate to its issuer, the log SHALL >>> publish a list of acceptable root certificates (this list might >>> usefully be the union of root certificates trusted by major browser >>> vendors). Each submitted certificate MUST be accompanied by all >>> additional certificates required to verify the certificate chain up >>> to an accepted root certificate. The root certificate itself MAY be >>> omitted from this list. >>> >>> Alternatively, (root as well as intermediate) Certificate Authorities >> >> >> Additionally? which manner is the experiment going to operate, or is it TBD >> ? > > Not sure what you mean? The log will accept either type of submission. oh, sorry, I meant s/Alternatively/Additionally/ >>> may submit a certificate to logs prior to issuance. To do so, a >>> Certificate Authority constructs a Precertificate by adding a special >>> critical poison extension (OID 1.3.6.1.4.1.11129.2.4.3, whose >>> extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)) to the >>> leaf TBSCertificate (this extension is to ensure that the >> >> >> leaf == end entity ? >> >> s/leaf certificate/end entity certificate/g ? > > Yes. > >>> Precertificate cannot be validated by a standard X.509v3 client), and >>> signing the resulting TBSCertificate [RFC5280] with either >> >> >> >>> o a special-purpose (Extended Key Usage: Certificate Transparency, >>> OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing Certificate. >>> The Precertificate Signing Certificate MUST be certified by the CA >>> certificate that will ultimately sign the leaf TBSCertificate >> >> >> "sign the leaf TBSCertificate" means to say "sign the actual >> issued-to-the-customer TBSCertificate component of the End Entity >> certificate" ? > > Well, it means something like that, I have added some words. ok >>> (note that the log may relax standard validation rules to allow >>> this, so long as the final signed certificate will be valid), >>> >>> o or, the CA certificate that will sign the final certificate. >> >> >> "final certificate" is the "issued-to-the-customer End Entity certificate" ? > > I have changed this to "issued certificate". ok, tho should it be "issued end entity certificate" ? >>> Structure of the Signed Certificate Timestamp: >> >> >> The SCT discussion here should probably be its own subsection. > > OK. > >> >> >>> >>> enum { certificate_timestamp(0), tree_hash(1), 255 } >>> SignatureType; >>> >>> enum { v1(0), 255 } >>> Version; >> >>> >>> >>> struct { >>> opaque key_id[32]; >>> } LogID; >>> >>> opaque CtExtensions<0..2^16-1>; >>> >>> "key_id" is the SHA-256 hash of the log's public key, calculated over >>> the DER encoding of the key represented as SubjectPublicKeyInfo. >> >> >> I'd place the above paragraph regarding "key_id" down below the >> SignedCertificateTimestamp definition. >> >> >>> struct { >>> Version sct_version; >>> LogID id; >>> uint64 timestamp; >>> CtExtensions extensions; >>> digitally-signed struct { >>> Version sct_version; >>> SignatureType signature_type = certificate_timestamp; >>> uint64 timestamp; >>> LogEntryType entry_type; >>> select(entry_type) { >>> case x509_entry: ASN.1Cert; >>> case precert_entry: ASN.1Cert; >>> } signed_entry; >>> CtExtensions extensions; >>> }; >>> } SignedCertificateTimestamp; >>> >>> The encoding of the digitally-signed element is defined in [RFC5246]. >> >> >> I would add a few words here summarizing that what happens here is that the >> digitally-signed struct here is replaced in the actual serialized binary >> structure by a struct DigitallySigned and cross-ref to S4.7 of RFC5246. > > Except it isn't :-) ok, then I don't understand what's going on here. RFC5246 S4.7 sez... A digitally-signed element is encoded as a struct DigitallySigned: struct { SignatureAndHashAlgorithm algorithm; opaque signature<0..2^16-1>; } DigitallySigned; ..and I take the "digitally-signed struct" within SignedCertificateTimestamp to be a "digitally-signed element". Please help me understand what am I missing? > > And we already reference RFC5246. we (IETF spec editors/authors) reasonably often reference particular sections of other RFCs in order to aid the reader. this is a sufficiently subtle construct to merit such an explicit ref (to S4.7 of RFC5246 if I'm correct) in my view. >> O-15. Some comments on S4: >> --------------------------- >> >> >>> 4. Client Messages >> >> >> title should be "Log Client Messages" ? > > Yes. > >>> Messages are sent as HTTPS GET or POST requests. Parameters for >>> POSTs and all responses are encoded as JSON objects. Parameters for >> >> >> s/JSON objects/JSON texts/ > > I don't agree with this. See above. see below. >>> inclusion in the TLS handshake are not required to verify it, we >> >> >> s/the TLS handshake/subsequent TLS handshakes/ ? >>> do not assume they know the ID of the log. >>> >>> timestamp The SCT timestamp, in decimal. >>> >>> extensions An opaque type for future expansion. It is likely that >>> not all participants will need to understand data in this field. >>> Logs should set this to the empty string. Clients should decode >>> the base64 encoded data and include it in the SCT. >>> >>> signature The SCT signature, base64 encoded. >> >> >> "The SCT signature" means a SignedCertificateTimestamp structure ? > > No, the signature that is a component of the structure. Oh, you mean this.. digitally-signed struct { Version sct_version; SignatureType signature_type = certificate_timestamp; uint64 timestamp; LogEntryType entry_type; select(entry_type) { case x509_entry: ASN.1Cert; case precert_entry: ASN.1Cert; } signed_entry; CtExtensions extensions; }; ..which automagically transforms to struct { SignatureAndHashAlgorithm algorithm; opaque signature<0..2^16-1>; } DigitallySigned; ..if I understand RFC5246 correctly? If not, please direct us to the correct formulation :) >>> If the "sct_version" is not v1, then a v1 client may be unable to >>> verify the signature. It MUST NOT construe this as an error. [Note: >>> log clients don't need to be able to verify this structure, only TLS >>> clients do - if we were to serve the structure binary, then we could >>> completely change it without requiring an upgrade to v1 clients]. >> >> >> Does this "if we were to serve the structure binary...." statement mean to >> say that since v1 log clients don't need to be able to verify the SCT >> signature over the various returned data items, that this operation could >> instead return an opaque binary blob? > > Indeed. Ok, then perhaps it could use some added text to more explicitly state that? > >> O-16. Some comments on S5: >> --------------------------- >> >> >>> 5. Clients >>> >>> >>> There are various different functions clients of logs might perform. >> >> >> Perhaps this section should be entitled "Log Client Roles" ? > > Since you persuaded me to include TLS clients, no :-) ok. > >> this section doesn't mention the role of a (CA) log client that submits >> "certs and cert chains" to logs. Even though the latter role is mentioned >> elsewhere in the spec it should perhaps be mentioned here also. > > OK. ok :) >>> 5.1. Monitor >>> >>> >>> Monitors watch logs and check that they behave correctly. They also >>> watch for certificates of interest. >> >> >> "Monitor" should be "Log Monitor" ? > > There's no other kind of monitor :-) in the explicit context of this spec, agreed. but in general I favor/advocate creation and use of more fully descriptive words/phrases so at least one is more likely to find them with a search when you're wondering what sort of "monitor" someone down the road is yammering on about. [ I would add a terminology section to the spec ] >>> 5.2. Auditor >>> >>> >>> Auditors take partial information about a log as input and verify >>> that this information is consistent with other partial information >>> they have. An auditor might be an integral component of a TLS >>> client, it might be a standalone service or it might be a secondary >>> function of a monitor. >> >> >> "Auditor" should be "Log Auditor" ? > > And there's no other kind of auditor. see above :) e.g. in the overall webpki world, there /are/ other forms of auditors (e.g. the ones noted here ) and so it's worth using a more descriptive term, imv. >>> 8. Efficiency Considerations >>> >>> >>> The Merkle tree design serves the purpose of keeping communication >>> overhead low. >>> >>> Auditing logs for integrity does not require third parties to >>> maintain a copy of each entire log. The Signed Tree Heads can be >>> updated as new entries become available, without recomputing entire >>> trees. Third party auditors need only fetch the Merkle consistency >>> proofs against a log's existing STH to efficiently verify the append- >>> only property of updates to their Merkle Trees, without auditing the >>> entire tree. >> >> >> The above could be explained in more detail, and S5.1 should be >> cross-referenced. Is the last sentence above essentially a summary of step >> #8 in S5.1? Or are there differences? > > It is a summary of 5.1 ok, but it'd be helpful to state that and crossref S5.1. wrt he JSON stuff... >> 1. The client messages S4 don't explicitly lay out the syntax for request >> messages or responses. E.g., for S4.1 "Add Chain to Log", is the input a >> stand-alone JSON text array, or a JSON text object containing a JSON text >> array? >> >> The term "JSON object" as used in the first paragraph is ambiguous and >> perhaps what is mean is simply "JSON texts" or "JSON text objects or JSON >> text arrays". RFC4627 clearly defines "JSON text", and should be cited. But >> RFC4627 is a little ambiguous itself regarding "JSON object" and so I >> suggest these definitions: >> >> JSON text object: A JSON text matching the "object" ABNF production >> in Section 2.2 of [RFC4627]. >> >> JSON text array: A JSON text matching the "array" ABNF production >> in Section 2.3 of [RFC4627]. > > I agree that RFC 4627 should be cited and I will correct that. ok. > The > rest of this confuses me: JSON is a textual representation of > structured data, as it states in the RFC. It defines an object quite > clearly > > " An object is an unordered collection of zero or more name/value > pairs, where a name is a string and a value is a string, number, > boolean, null, object, or array." well, yes, but that's in just the introduction of RFC 4627. > Defining a "JSON text object" seems pointless to me - clearly a JSON > object is an object as defined by JSON, surely? Introducing another > term seems like to add confusion rather than remove it. note that "JSON text" is very explicitly defined in RFC4627 at the beginning of S2 as.. A JSON text is a sequence of tokens. The set of tokens includes six structural characters, strings, numbers, and three literal names. A JSON text is a serialized object or array. JSON-text = object / array the reason I flagged this issue is that I just recently reviewed a different internet-draft where they'd confused a JSON object -- in the sense of a JSON text matching the object production of S2.2 RFC4627 -- and a "JSON object" in the sense of an abstract programming construct, and they didn't understand that in the protocol on-the-wire world a JSON object /is a string/ (i.e. it is string-serialized according to the grammar of RFC4627). It seems the term "JSON object" is ambiguous depending on whether you're looking at it from a programming perspective or an on-the-wire protocol perspective (eg see which talks about "internal form" and "external form" (ugh)), hence my (perhaps feeble) attempt to invent a more explicit term for the on-the-wire protocol form. So maybe a more palatable definition would be.. JSON object: A JSON text matching the "object" ABNF production in Section 2.2 of [RFC4627]. ? --- end From Jeff.Hodges@KingsMountain.com Mon Jan 21 19:14:13 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DD821F85C3 for ; Mon, 21 Jan 2013 19:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeZRy8PiKoIv for ; Mon, 21 Jan 2013 19:14:12 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 7401A11E80A3 for ; Mon, 21 Jan 2013 19:14:12 -0800 (PST) Received: (qmail 19589 invoked by uid 0); 22 Jan 2013 03:13:49 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 22 Jan 2013 03:13:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=0OVOjhUFygbG1sjeZM/WAbkccP04Y6DMUydnaLIKPlo=; b=ouGqfJhUKVW1kVmelcmHdMkdsuoND4iJQ1c2FOqYj8RJ4+oMFf8WkHaUfObdTyP0LampHL2hr6CL4VK7dJ7udLoapd3Hn5zNln/UjMVgDxLyGdtPAbJQZ1zY7Z29Zzh0; Received: from [24.4.122.173] (port=35794 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1TxUJ3-0002en-0o; Mon, 21 Jan 2013 20:13:49 -0700 Message-ID: <50FE03EC.9070005@KingsMountain.com> Date: Mon, 21 Jan 2013 19:13:48 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "therightkey@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: Eliot Lear Subject: [therightkey] fwd: apps area review of draft-laurie-pki-sunlight-05 (Eliot's version) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 03:14:13 -0000 ------- Forwarded Message Date: Thu, 10 Jan 2013 13:50:07 +0100 From: Eliot Lear To: draft-laurie-pki-sunlight-05.all@tools.ietf.org, "apps-discuss@ietf.org" , "'IESG'" Subject: [apps-discuss] apps area review of draft-laurie-pki-sunlight-05 = (Eliot 's version) Gents, Thanks for contributing an experimental doc to the IETF. I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see =E2=80=8B http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-laurie-pki-sunlight-5 Title: Certificate Transparency Reviewer: Eliot Lear Review Date: 10 Jan 2012 IETF Last Call Date: 20 Dec. 2012 Summary: This document requires relatively minor revision prior to publication. Noting that its intended status is experimental, I've focused on clarity of what problem is being solved and the clarity of how it is being solved so that the experiment can be performed and appropriate analysis performed. In particular there seem to be two goals: for an owner to monitor what certs have been signed for a given subject, and for an auditor to review ALL certs on a log, perhaps relevant to a particular CA or multiple CAs. Anyway, get more clear please in the beginning. Major issues: Note: I haven't tested your formal assertions in Section 3. That's for implementers of your specification. Introduction: I would prefer to see a clearer statement of the problem, such that it is clear that the complexity of Merkle trees is warranted. In the absence of such a statement, a reference to something would suffice. In particular, how large a data set would alternatively be returned in a linear fashion? What is being optimized, and what is being traded off? I don't expect this is a major effort to correct, but it will be a major flaw if it is not corrected (thus listed here). Please include a reference to what you mean by Log or define it formally.= Minor issues: Abstract: Do you really mean "log signatures" in your last paragraph? What if the log itself has its private key stolen? "Misissued" is not a word. This might seem like a nit but you make it quite hard for non-native speakers to understand what you are trying to say when they can't use a dictionary to figure it out. Introduction Consider including an Existing Work subsection. Section 2.1.1: In other words, the audit path consists of the list of missing nodes required to compute the nodes leading from a leaf to Did you really mean "missing nodes" or just "nodes" or "internal/interior nodes"? In that section, more clearly define "m". 3. Log Format Anyone can submit certificates to certificate logs for public auditing, however, since certificates will not be accepted by clients= unless logged, it is expected that certificate owners or their CAs will usually submit them. This might be clear if we understood more clearly what problem you were solving. Also, fix the run-on sentence. Section 3.1: Anyone can submit a certificate to any log. In order to enable attribution of each logged certificate to its issuer, the log SHALL publish a list of acceptable root certificates (this list might usefully be the union of root certificates trusted by major browser vendors). There is an implication that really authorization occurs through the accepted list of CAs. I don't know that you need to or want to state the first sentence. Rather you've provided a RESTful interface. Why not allow for appropriate HTTP/TLS authentication and leave it to deployments? Section 4 Please indicate the appropriate MIME type for responses (e.g., Accept:) as well as for your POSTs. Nits: 1. Informal introduction Introduction is enough, unless you are going to have both a formal introduction AND an informal introduction... Please add a citation for Merkle Trees. Here's one: Merkle, R. "Secrecy, authentication and public key systems / A certified digital signature". Ph.D. Dissertation, Stanford University, 1979. Section 3 and elsewhere Your formal description language requires a reference. ------- End of Forwarded Message From Jeff.Hodges@KingsMountain.com Tue Jan 22 08:48:46 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B78C21F8A51 for ; Tue, 22 Jan 2013 08:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeLheicUVYW4 for ; Tue, 22 Jan 2013 08:48:45 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 53B4F21F8A4F for ; Tue, 22 Jan 2013 08:48:45 -0800 (PST) Received: (qmail 1204 invoked by uid 0); 22 Jan 2013 16:48:22 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy11.bluehost.com with SMTP; 22 Jan 2013 16:48:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=tDssty3QCuVJuGuHuFt7oBfVhuqn2uZSC7+0MyaTjJE=; b=a5yi8/cnBrJHrlRD+sB/KY/j+Hp6RGYJJ4it2yo4cfbbR5ETiTjluSDE5+DQbMkl1gN65A+TP3GHQmfdH0aWwKerTPTpcFFRS3fHfdxcjpAgYhQAzNyheJ5lklDqJoiX; Received: from [216.113.168.128] (port=25325 helo=[10.244.137.234]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1Txh1J-0000MI-Aw for therightkey@ietf.org; Tue, 22 Jan 2013 09:48:21 -0700 Message-ID: <50FEC2D4.1030008@KingsMountain.com> Date: Tue, 22 Jan 2013 08:48:20 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: IETF PKI next gen discussion list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [therightkey] fyi: APPSDIR review of draft-laurie-pki-sunlight-05 (Alexey Melnikov) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:48:46 -0000 ------- Forwarded Message Date: Mon, 21 Jan 2013 18:40:56 +0000 From: Alexey Melnikov To: apps-discuss@ietf.org, draft-laurie-pki-sunlight.all@tools.ietf.= org cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-laurie-pki-sunlight-05 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see =E2=80=8B http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-laurie-pki-sunlight-05 Title: Certificate Transparency Reviewer: Alexey Melnikov Review Date: 2013-01-21 IETF Last Call Date: 2013-01-24 IESG Telechat Date: unknown Summary: This draft is nearly ready for publication as an Experimental RFC. I think a revision should be able to address my issues (and issues raised by Eliot earlier). Major Issues: none Minor Issues: 1) There are no references for SHA-256/TLS/RSA in the document. They are Normative and should be added. 2) Section 4 needs references for JSON, base64 and HTTP. 3) Section 4.1: it would be good to have an example. 4) In 4.5/4.6: are indexes 0-based or 1-based? _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------- End of Forwarded Message From Jeff.Hodges@KingsMountain.com Tue Jan 22 13:38:56 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F6921F854E for ; Tue, 22 Jan 2013 13:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk2HTl50tT1L for ; Tue, 22 Jan 2013 13:38:56 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 43AEA21F8818 for ; Tue, 22 Jan 2013 13:38:45 -0800 (PST) Received: (qmail 21460 invoked by uid 0); 22 Jan 2013 21:38:22 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 22 Jan 2013 21:38:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=bXYQYAUl85CLIDTEGI5w0JXfgsjXGlL38dzkx6Mx0ks=; b=Vc2wqFd9NoiO5lK/r8laPByequdVd3xD/LstqnTmJtPE0TpFjWSX/j6G8EZnbWTnXXyvp6w3tISfSR+eKVN4SrTovEJ/V9b1B1QTmTKPI8d5WPvk1g5iV91zaN3B+v0P; Received: from [216.113.168.128] (port=53674 helo=[10.244.137.234]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1TxlXx-0007dD-MJ; Tue, 22 Jan 2013 14:38:21 -0700 Message-ID: <50FF06CD.2050002@KingsMountain.com> Date: Tue, 22 Jan 2013 13:38:21 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Eliot Lear Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: draft-laurie-pki-sunlight-05.all@tools.ietf.org, therightkey@ietf.org, The IESG , Apps Discuss Subject: Re: [therightkey] "mis-issued" was: apps area review of draft-laurie-pki-sunlight-05 (Eliot's version) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 21:38:56 -0000 > "Misissued" is not a word. but "mis-issued" is a legit contraction, so perhaps it's simply misspelled (and a definition should probably be provided). "mis-issue" and "mis-issued" refer to the situation where a CA issues a cert for a given subject (i.e. domain name) when they should not have. C.f. Diginotar. See also: https://tools.ietf.org/html/draft-ietf-pkix-caa-15 HTH, =JeffH From Jeff.Hodges@KingsMountain.com Tue Jan 22 13:45:08 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E99221F86BE for ; Tue, 22 Jan 2013 13:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.321 X-Spam-Level: X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp9IVfpHYIaW for ; Tue, 22 Jan 2013 13:45:08 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id E26CC21F86CC for ; Tue, 22 Jan 2013 13:45:06 -0800 (PST) Received: (qmail 29779 invoked by uid 0); 22 Jan 2013 21:44:44 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 22 Jan 2013 21:44:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=lwSoGqHLxupsI90ovAAsHrAfEGeCuidxYDle7sxcHCs=; b=pd4sLwgQ4tDxn7GNmWoMwmHb3QQZjClIufO96kqe0VlMeC/lITVTMIy6V3HJUULc7AVcFcdNEwg9tDwl/92DVwl4hMzEmm6wdgn35RPiufTIjnZTTHb/3iUE2P2OKNzi; Received: from [216.113.168.128] (port=45136 helo=[10.244.137.234]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1Txle7-0007BP-NF; Tue, 22 Jan 2013 14:44:43 -0700 Message-ID: <50FF084B.5040508@KingsMountain.com> Date: Tue, 22 Jan 2013 13:44:43 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: Emilia Kasper , "therightkey@ietf.org" , IETF Discussion List , Adam Langley Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05 - "acceptable root certificates" ? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 21:45:08 -0000 >>> 3.1. Log Entries >>> >>> Anyone can submit a certificate to any log. In order to enable >>> attribution of each logged certificate to its issuer, the log SHALL >>> publish a list of acceptable root certificates (this list might >>> usefully be the union of root certificates trusted by major browser >>> vendors). Each submitted certificate MUST be accompanied by all >>> additional certificates required to verify the certificate chain up >>> to an accepted root certificate. The root certificate itself MAY be >>> omitted from this list. a question I neglected to add here is: how do log services publish their lists of "acceptable root certificates" ? =JeffH From trevp@trevp.net Tue Jan 22 15:07:20 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FE621F85AF for ; Tue, 22 Jan 2013 15:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DvI6q13tP85 for ; Tue, 22 Jan 2013 15:07:19 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 50DDD21F84E2 for ; Tue, 22 Jan 2013 15:07:17 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id dq12so289298wgb.24 for ; Tue, 22 Jan 2013 15:07:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=wCj3Dv8i6rIvOt8bIdn1zvQXrIDkOLbwmOcAxys778c=; b=XQ3ZhXkI3i+IHBrhq3YAxbqeewzLeifm6+NWcmqDvXxDISltSXPrb5ib8HbqV4DOUJ BhjZEQfQpbpbFDybwdD6CXDz+YhfaXJR140AlFhsiNRvd/nj/KX9dnsC9h7JVWIfn1JG rJ3/Qe+BYO0IR7pTrnBMOKU78JjLSZgILpqgjLtUyIkWnIeFIw2M4ZX13o0I5yfFwBsf zQrE/oC9vmIV1dQS0c5rpY2xCzstIvZmPTM+wAWmqfMWxA0a3uhvARm5rm9vuwjDPa8F dHQEbPQxojOtK7/Vs8UnVrnsYdtU9ZPVDV+DdWvXYa5rQEvcEsmcWB0O5qv6eqVt86S/ 6xYQ== MIME-Version: 1.0 X-Received: by 10.180.99.72 with SMTP id eo8mr23976901wib.34.1358896035783; Tue, 22 Jan 2013 15:07:15 -0800 (PST) Received: by 10.216.242.141 with HTTP; Tue, 22 Jan 2013 15:07:15 -0800 (PST) X-Originating-IP: [166.137.215.1] Date: Tue, 22 Jan 2013 15:07:15 -0800 Message-ID: From: Trevor Perrin To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmdkulJGSMv5UPZob0uVVKZq4UMS49ZRAZpLEZnRLOmngiyxDjs6v/q/RynTwD8y4ENyUjL Subject: [therightkey] CT Qs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:07:20 -0000 Hi, Some questions, based on draft-05: (1) Is there going to be a DNS-based protocol for retrieving audit proofs? (2) Why are the RFC 5878 / RFC 4680 Authorization Extension and SupplementalData mechanisms used to convey the SCT, instead of defining a new TLS Extension? (RFC 5878 is an Experimental-track TLS Extension; CT adds a new extension value to it to signal that an SCT is included in an RFC 4680 SupplementalData handshake message; this seems more complex than just putting the SCT directly in a TLS Extension). (3) Some things about "precertificates" are unclear to me, in draft-05: - If the precert is signed by the "CA certificate that will sign the final certificate", as described in the second bullet in 3.1, does this CA cert also need to contain the "Certificate Transparency" EKU extension from the first bullet? - In the SCT for a precertificate, what exactly does the log sign? Is it the TBSCertificate including the poison extension, or is the log expected to remove the poison extension prior to signing? - How exactly does a TLS client verify an SCT for a precert? Does the client need to remove the SCTs and recalculate the original TBSCertificate's ASN.1 to verify? - Related to previous: why is it necessary for SCTs and MerkleTreeLeafs to have different cases for precerts and certs? Could the signature be calculated on a "normalized" form of the TBSCertificate which is the same for certs and precerts (i.e. the TBSCertificate with poison and SCT extensions removed?) (4) Why is the SCT's timestamp and CtExtensions included in the MerkleTreeLeaf? If the Merkle Tree was built directly on hash(cert) leaves instead of hash(SCT fields), then the audit path mechanism could be deployed earlier / independently from SCTs, i.e. browsers could retrieve and check audit paths for certs regardless of whether the TLS server had presented an SCT. Perhaps CT doesn't envision that use case, but it seems potentially useful. So I'm wondering if it might be worth decoupling the SCTs from the merkle trees to provide more deployment flexibility. Trevor From benl@google.com Tue Jan 22 16:19:27 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398BD21F8B11 for ; Tue, 22 Jan 2013 16:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Td1w8naDc9fR for ; Tue, 22 Jan 2013 16:19:26 -0800 (PST) Received: from mail-bk0-f51.google.com (mail-bk0-f51.google.com [209.85.214.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0214621F89E9 for ; Tue, 22 Jan 2013 16:19:25 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id y8so1683534bkt.38 for ; Tue, 22 Jan 2013 16:19:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hABf/aKM0AZb72/6HTVNZMh1+y/LmirkAfBAA9xwd/U=; b=G+FCvo9E8nJEl5t8hSWbnZZ9IyiE/xHid+LeYTenamfF8hmztVUe5H/5IlJJAYXJ7D 0wFwCwHHw1yptzu93tZ0Q2PJJD21IU7mbbWpbkKpm5DkWboS0zIoxxUV80iC0hnq0rlK ZOPtgx7bKOlLxZnOL407CsM8KpT7SuuD+h0d5EyPn5lcSMa08c9mi9nq6DJAflOAkMOT QBY8Ige8A0z1XUX5iN31wLOvoFYqjwIkUsh8JomoPL9SeBRd3OVkqv1fn4QvDaAnATIs I+N6+XyL8PVzwFvUf8TlMieeyMSD03AtEfYsIrlJRMHOydzw5Un+hw8AeejiZRjimoD9 6JfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=hABf/aKM0AZb72/6HTVNZMh1+y/LmirkAfBAA9xwd/U=; b=FqgmEVJT0eF5zDSGYJ3yE75DKtjqS39WYRchfydOOuIG+anSOT4RjzFBCuJesEY3Sj QlUiPEJgA3CIao6TSJ4gwlCEKAEe7wXrnRkuJJ1cO9MkqjKqZWo0Zag6p4yd4uJeX5Kb jOVgZu4frUhpl2euC4T0sg+Fuc58fmJhTuyRgst4gwz4u9IwykpoOifo612eI2dzVldG zWAiTEBcY1VdZQr8si8wCKMlxfJ0E2EWfxovCrWCF5FJvb4PyDnOE2vN+YCwWnzVuCh5 72v8DFwiX4QmBQQRKzgWXOwqOIzJRykk/GwliGeSgkvrHftKy02KXZsTJvDZBCMofIVC 5LcA== MIME-Version: 1.0 X-Received: by 10.204.147.18 with SMTP id j18mr6243275bkv.79.1358900364729; Tue, 22 Jan 2013 16:19:24 -0800 (PST) Received: by 10.204.36.210 with HTTP; Tue, 22 Jan 2013 16:19:24 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Jan 2013 00:19:24 +0000 Message-ID: From: Ben Laurie To: Trevor Perrin Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnoH8MzK2Io8eLkS8m0pqqO7Wfg/iZL0re7nkwO87ahyFoVRKeNLmR+70HvCsWItAoTq9EG+wwwYvPSXb8YdD/fmGwjBI8460iCsBstU450K2Mb3pOZUCjjc5Eur1OSuMliGU+VO3NB3I3UXRDQDlG+/lLCqoQZ2TsFTLORH2wKzSu9PGY71SFEV5O3XVWnt2Tc5BBt Cc: "therightkey@ietf.org" Subject: Re: [therightkey] CT Qs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 00:19:27 -0000 On 22 January 2013 23:07, Trevor Perrin wrote: > Hi, > > Some questions, based on draft-05: > > (1) Is there going to be a DNS-based protocol for retrieving audit proofs? Yes. Not in this I-D. > (2) Why are the RFC 5878 / RFC 4680 Authorization Extension and > SupplementalData mechanisms used to convey the SCT, instead of > defining a new TLS Extension? (RFC 5878 is an Experimental-track TLS > Extension; CT adds a new extension value to it to signal that an SCT > is included in an RFC 4680 SupplementalData handshake message; this > seems more complex than just putting the SCT directly in a TLS > Extension). At the time the mechanism was defined, Experimental track was more standardised than what we were defining. We could indeed contemplate defining our own extension if we go beyond Experimental ourselves. > > (3) Some things about "precertificates" are unclear to me, in draft-05: > - If the precert is signed by the "CA certificate that will sign the > final certificate", as described in the second bullet in 3.1, does > this CA cert also need to contain the "Certificate Transparency" EKU > extension from the first bullet? > - In the SCT for a precertificate, what exactly does the log sign? > Is it the TBSCertificate including the poison extension, or is the log > expected to remove the poison extension prior to signing? This is more clearly explained in the next revision. > - How exactly does a TLS client verify an SCT for a precert? Does > the client need to remove the SCTs and recalculate the original > TBSCertificate's ASN.1 to verify? Yes. > - Related to previous: why is it necessary for SCTs and > MerkleTreeLeafs to have different cases for precerts and certs? Could > the signature be calculated on a "normalized" form of the > TBSCertificate which is the same for certs and precerts (i.e. the > TBSCertificate with poison and SCT extensions removed?) We did consider that, but it is not what the code does currently. There's no particular reason it could not be done that way, as far as I currently know. > (4) Why is the SCT's timestamp and CtExtensions included in the > MerkleTreeLeaf? If the Merkle Tree was built directly on hash(cert) > leaves instead of hash(SCT fields), then the audit path mechanism > could be deployed earlier / independently from SCTs, i.e. browsers > could retrieve and check audit paths for certs regardless of whether > the TLS server had presented an SCT. Perhaps CT doesn't envision that > use case, but it seems potentially useful. So I'm wondering if it > might be worth decoupling the SCTs from the merkle trees to provide > more deployment flexibility. I think there are two semi-separate issues here: 1. The log must be held to a promise to include a cert within a certain time, which is why it signs an SCT. I think it is correct that you could construct a working system that then built a Merkle tree on the cert alone (I may have missed an attack, though[1]), but I don't think this actually has any advantage over a tree built on the SCT (see point 2), given that you have to make an SCT anyway. 2. If you built a Merkle tree based on the cert alone, what would the correct action of a client which saw a cert with no SCT be? Sure, it could check the log and see it was not in it - but then what? It can't reject it, perhaps it is the first CT-enabled client to see the cert (or one of the first). The fact it lacks an SCT shows it hasn't participated in voluntary logging. So the correct action is to log it, and obtain an SCT for it (which can later be shown if the log fails to include the cert). So why not just always attempt to log it? If its already there you'll (probably) get an SCT in the past. Otherwise, monitors can pick it up and take appropriate action. BTW, I am not against logs providing a way (e.g. via DNS) to pre-check whether a cert exists in the log before attempting to log it, but I don't think that needs to be part of the CT spec. In any case, we are not primarily attempting to build a system that solves a half-way problem - we want full deployment of CT. [1] There are, of course, distinct weaknesses compared to a system built on SCTs - for example, the tree is no longer self-timestamping and so claims about timing become more difficult to substantiate. > > > Trevor > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From trevp@trevp.net Wed Jan 23 11:25:48 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F71A21F87D1 for ; Wed, 23 Jan 2013 11:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkVkddJZM2Wg for ; Wed, 23 Jan 2013 11:25:48 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8324D21F87C6 for ; Wed, 23 Jan 2013 11:25:47 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id 16so2146534wgi.27 for ; Wed, 23 Jan 2013 11:25:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=zAPp7pCadxsFGtGf6f4Sb9ozFmyIPTTKT8fdUkkisUA=; b=TSKBnQd43H5aacf+2M+oS/1Jt6od4TnUoE/+fIX6Wom3R6KlvJI5Wa6uPBUUnqT0gU ajWhiK4AcNMJ/mkAGy1TDJf2edqk2/bDE5xdKZvrvQhfZoGz51n4ARqbYbA2yAYVAcER RvW4+rJw939wSpPcwVVkDfGjgCMMmj88L2/LjPzNBVPZyT4YmTc7tZq3ih90oC1yAAW4 vj6RtdN3CeawguAaD1bEYOf+gUS+4CUOfHm3r18R54LNtrr3fdqpJl5G5iFQTC6Gcsbp aWiOwN/872lUG3gKKYWLkmIsjnfI/JUlby4OTxw86b/pvBa1pp2WI6xyM+V1Bk06OBKJ cq3g== MIME-Version: 1.0 X-Received: by 10.194.236.166 with SMTP id uv6mr4664441wjc.34.1358969146498; Wed, 23 Jan 2013 11:25:46 -0800 (PST) Received: by 10.216.242.141 with HTTP; Wed, 23 Jan 2013 11:25:46 -0800 (PST) X-Originating-IP: [166.137.215.1] In-Reply-To: References: Date: Wed, 23 Jan 2013 11:25:46 -0800 Message-ID: From: Trevor Perrin To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlmveTcGL0m7dL5cBmdEklzMsa4CmlsAhpVN9hBsIBckZfK/pt4PoeJODEvpWDxDXrcVY0G Cc: "therightkey@ietf.org" Subject: Re: [therightkey] CT Qs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 19:25:48 -0000 On Tue, Jan 22, 2013 at 4:19 PM, Ben Laurie wrote: > On 22 January 2013 23:07, Trevor Perrin wrote: > >> (2) Why are the RFC 5878 / RFC 4680 Authorization Extension and >> SupplementalData mechanisms used to convey the SCT, instead of >> defining a new TLS Extension? [...] > > At the time the mechanism was defined, Experimental track was more > standardised than what we were defining. We could indeed contemplate > defining our own extension if we go beyond Experimental ourselves. Defining your own TLS Extension seems simpler, why not do it from the start? I'd be curious if potential implementors have an opinion. The difference is roughly: WITH A CT TLS EXTENSION: - ClientHello contains a TLS extension to indicate CT support - ServerHello contains a TLS extension with: - 2 byte length of SignedCertificateTimestampList - sequence of: - 2 byte length of SCT - SCT WITH THE 5878 TLS EXTENSION: - ClientHello contains a TLS extension with a list of single-byte values, one of which indicates CT support - ServerHello contains a TLS extension with a list of single-byte values, one of which indicates SCTs are present - Following ServerHello is an RFC 4680 SupplementalData message: - 3 byte length - sequence of SupplementalDataEntry, each with: - 2 byte type - 2 byte length - (if type = "authz_data", then the body of this entry is): - 2 byte length - sequence of AuthorizationDataEntry, each with: - 1 byte type (which may indicate an SCT is present) - (length field for SCT? unclear in draft-05) - SCT (I think this is right but the structures in 5878 section 3 don't actually match 4680 (errata?), nor does draft-05 define the encoding of an SCT into an AuthorizationDataEntry, so I'm not sure.) Anyways, 5878/4680 seem like unnecessary layers of parsing. >> - Related to previous: why is it necessary for SCTs and >> MerkleTreeLeafs to have different cases for precerts and certs? Could >> the signature be calculated on a "normalized" form of the >> TBSCertificate which is the same for certs and precerts (i.e. the >> TBSCertificate with poison and SCT extensions removed?) > > We did consider that, but it is not what the code does currently. > There's no particular reason it could not be done that way, as far as > I currently know. It would seem simpler, since clients would not need separate code paths for precerts and "fully-logged" certs. Also, this would simplify the data structures since you could eliminate the "entry_type" from the LogEntry, SCT, and MerkleTreeLeaf. Related comment: There should probably be Security Considerations about logging TBSCertificates, since I think there are some subtle issues that arise from logging TBSCertificates if you're using revocation systems based on the full certificate (like OCSP, CRLsets, etc.). For example, a rogue CA could potentially issue a rogue sub CA with the same name as some existing CA, and this rogue sub CA could issue rogue certs with TBSCertificates that match existing certificates. If such a rogue certificate was issued that matched a revoked cert for which an attacker had compromised the private key, the rogue cert could be used with the revoked cert's SCT, but might not itself be revoked (since revocation methods like OCSP and CRLsets scope revocations to the issuer's key hash). So, revocation systems would need to be cognizant of this risk and revoke the TBSCertificate, it seems? >> (4) Why is the SCT's timestamp and CtExtensions included in the >> MerkleTreeLeaf? If the Merkle Tree was built directly on hash(cert) >> leaves instead of hash(SCT fields), then the audit path mechanism >> could be deployed earlier / independently from SCTs, [...] > 2. If you built a Merkle tree based on the cert alone, what would the > correct action of a client which saw a cert with no SCT be? Sure, it > could check the log and see it was not in it - but then what? It can't > reject it, perhaps it is the first CT-enabled client to see the cert > (or one of the first). The fact it lacks an SCT shows it hasn't > participated in voluntary logging. So the correct action is to log it, > and obtain an SCT for it Or just report it to someone you trust who logs it for you - the browser doesn't need the SCT in this case. > So why not just always attempt to log it? It's more efficient if the browser could fetch an audit proof without also needing an SCT, and it would be simpler if Merkle Tree Leaves were just defined like: struct { Version version; opaque tbscertificate<1...65535>; } } MerkleTreeLeaf; I guess these aren't the strongest arguments, but I don't see that this simplication loses anything important. > In any case, we are not primarily attempting to build a system that > solves a half-way problem - we want full deployment of CT. Sure, but if it's going to take awhile to get SCTs universally deployed, it would be nice to get some of the benefits of CT earlier. That's why I like the idea of using scanning and online checks to populate logs until SCTs are ubiquitous (at which point the CAs and TLS servers will have assumed the responsibility of populating logs). > [1] There are, of course, distinct weaknesses compared to a system > built on SCTs - for example, the tree is no longer self-timestamping > and so claims about timing become more difficult to substantiate. I don't see the weakness - the log is ordered, periodically signed with a timestamp (TreeHeadSignature), and monitored, so won't you have good timing data for log entries regardless? Trevor From stephen.farrell@cs.tcd.ie Thu Jan 24 03:08:39 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B327121F8941 for ; Thu, 24 Jan 2013 03:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLdOVLdV5jkA for ; Thu, 24 Jan 2013 03:08:38 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E9D7E21F86CC for ; Thu, 24 Jan 2013 03:08:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5C787BE38 for ; Thu, 24 Jan 2013 11:08:16 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAeFQQWTgb3D for ; Thu, 24 Jan 2013 11:08:15 +0000 (GMT) Received: from [IPv6:2001:770:10:203:810d:eba8:c654:6e65] (unknown [IPv6:2001:770:10:203:810d:eba8:c654:6e65]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 153DDBDC7 for ; Thu, 24 Jan 2013 11:08:15 +0000 (GMT) Message-ID: <51011620.9050407@cs.tcd.ie> Date: Thu, 24 Jan 2013 11:08:16 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "therightkey@ietf.org" References: <20121220193358.31474.25301.idtracker@ietfa.amsl.com> <50D38475.9080701@cs.tcd.ie> In-Reply-To: <50D38475.9080701@cs.tcd.ie> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [therightkey] Fwd: Last Call: (Certificate Transparency) to Experimental RFC X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 11:08:39 -0000 Hi all, IETF last call on this is done. There were a bunch of comments and I believe Ben is preparing an update to handle those and some discussion is still ongoing. Once that's done and we have a version that addresses the comments received (*) then my plan is to put this on an IESG telechat agenda. Cheers, S. (*) Note "addressed" != "accepted as-is" its just fine if the authors argue convincingly to not accept a comment. On 12/20/2012 09:34 PM, Stephen Farrell wrote: > > FYI. Slightly longer than normal IETF LC give the holidays. > > S > > > -------- Original Message -------- > Subject: Last Call: (Certificate > Transparency) to Experimental RFC > Date: Thu, 20 Dec 2012 11:33:58 -0800 > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce > > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Certificate Transparency' > as Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-01-24. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The aim of Certificate Transparency is to have every public end- > entity (for example, web servers) and intermediate TLS certificate > issued by a known Certificate Authority recorded in one or more > certificate logs. In order to detect misissuance of certificates, > all logs are publicly auditable. In particular, domain owners or > their agents will be able to monitor logs for certificates issued on > their own domain. > > To protect clients from unlogged misissued certificates, each log > signs all certificates it records, and clients can choose not to > trust certificates that are not accompanied by an appropriate log > signature. For privacy and performance reasons log signatures are > embedded in the TLS handshake via the TLS authorization extension, in > a stapled OCSP extension, or in the certificate itself via an X.509v3 > certificate extension. > > To ensure a globally consistent view of any particular log, each log > also provides a global signature over the entire log. Any > inconsistency of logs can be detected through cross-checks on the > global signature. Consistency between any pair of global signatures, > corresponding to snapshots of a particular log at different times, > can be efficiently shown. > > Logs are only expected to certify that they have seen a certificate, > and thus we do not specify any revocation mechanism for log > signatures in this document. Logs are append-only, and log > signatures do not expire. > > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > From ekasper@google.com Thu Jan 24 04:10:13 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BFC21F899F for ; Thu, 24 Jan 2013 04:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMZn7TCACUOQ for ; Thu, 24 Jan 2013 04:10:12 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 92B9C21F8995 for ; Thu, 24 Jan 2013 04:10:11 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hm11so364036wib.2 for ; Thu, 24 Jan 2013 04:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Hk67/BpMtfARVH8sKWQ252LEQASGIx7RTiZmksp4LDU=; b=kGHhbFrT94qeogUxGMjuis/0LfRvOJQ6W+7TW7G0+SaJ80g2y/6LF28WcHO22TQRkh 4RnVSS+ku5/h28ULppfl8v5Pw+iJA/XlU26lPo3UaOS5al1dw0EX6vyHnjvh3vwkcTJi 55PWwoGTtx3smjzVp8h9lRdMn0/V+HVcRCBzH9h48bd3vwVlRMoX08B3DxeeJYgi7aWx WofeaNKmykY7okat0lauI2JTUGs40gTEKYt+VQoN0h/QPxWqrSPd5TwimZpYKbgNbGDe oCsKh5t0L/IucUV1HEwyTY+KOHc2cwr0Qrvp5YoXOXRcpYL+xcKHRypV1PfK+/MTZmTY mvSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Hk67/BpMtfARVH8sKWQ252LEQASGIx7RTiZmksp4LDU=; b=fMdx25xaxyHdRedJV6Qk7+yX8K999ykZTRsYW4VUsEH1P3IhVmXiTB1uQUaV7Uk0BL 5gD5tGWdkQkvZZWHW3VKAFd0QD9pCMxNipkrBxyA9/DLprOiqSW3AuatmdEUk3Mtt7sn Lzgw3nnVgcZWBXTVsmXJbiVl9GCMkNEt81UWoKhRgIl7YmdtLaWyL0Bvpe9bAe4Buq4U 2Dv/5aa7gwWWBPv/kPx5mekjc3XZ9kOuzhkJWRsjp7TGx/vAPoeG0kJtM08QfJN9eecC IXmJrBcdUULxZ13fzkLILmnIU1SsrHm37/SUWt8MNd71Bd51mV9Kwlj71WVBRP5wOkrX NhqA== MIME-Version: 1.0 X-Received: by 10.180.78.137 with SMTP id b9mr2690547wix.30.1359029410523; Thu, 24 Jan 2013 04:10:10 -0800 (PST) Received: by 10.194.87.162 with HTTP; Thu, 24 Jan 2013 04:10:10 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Jan 2013 13:10:10 +0100 Message-ID: From: Emilia Kasper To: Trevor Perrin Content-Type: multipart/alternative; boundary=f46d0435c03c40e94304d407b197 X-Gm-Message-State: ALoCoQlF+dhXY4HgpxaaPbot4h9B0WzQhIC7duUQK3ERQPsjNoxQH6AlgTzSOlH9cG9TRKna6njBcaa24EINm0vLT2L3Z0ytHMXf/FckW2HuM/b7uy1oUWKyWW0kIO6Sp+FwaENSOGIy9AWlsryodeiS4anVDNU/jhV6Vtou4LDwv2dOBVt7sQydaapyK/noEE7wSOWNonp2 Cc: "therightkey@ietf.org" , Ben Laurie Subject: Re: [therightkey] CT Qs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 12:10:13 -0000 --f46d0435c03c40e94304d407b197 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 23, 2013 at 8:25 PM, Trevor Perrin wrote: > On Tue, Jan 22, 2013 at 4:19 PM, Ben Laurie wrote: > > On 22 January 2013 23:07, Trevor Perrin wrote: > > > >> (2) Why are the RFC 5878 / RFC 4680 Authorization Extension and > >> SupplementalData mechanisms used to convey the SCT, instead of > >> defining a new TLS Extension? > [...] > > > > At the time the mechanism was defined, Experimental track was more > > standardised than what we were defining. We could indeed contemplate > > defining our own extension if we go beyond Experimental ourselves. > > Defining your own TLS Extension seems simpler, why not do it from the > start? > I'd be curious if potential implementors have an opinion. The > difference is roughly: > We've already implemented 5878 for OpenSSL and Apache. The wider benefit of a more general mechanism is that adding new types of authorization data (Revocation Transparency?) will in the future not require upgrading servers again. > WITH A CT TLS EXTENSION: > - ClientHello contains a TLS extension to indicate CT support > - ServerHello contains a TLS extension with: > - 2 byte length of SignedCertificateTimestampList > - sequence of: > - 2 byte length of SCT > - SCT > > WITH THE 5878 TLS EXTENSION: > - ClientHello contains a TLS extension with a list of single-byte > values, one of which indicates CT support > - ServerHello contains a TLS extension with a list of single-byte > values, one of which indicates SCTs are present > - Following ServerHello is an RFC 4680 SupplementalData message: > - 3 byte length > - sequence of SupplementalDataEntry, each with: > - 2 byte type > - 2 byte length > - (if type = "authz_data", then the body of this entry is): > - 2 byte length > - sequence of AuthorizationDataEntry, each with: > - 1 byte type (which may indicate an SCT is present) > - (length field for SCT? unclear in draft-05) > - SCT > > (I think this is right but the structures in 5878 section 3 don't > actually match 4680 (errata?), nor does draft-05 define the encoding > of an SCT into an AuthorizationDataEntry, so I'm not sure.) > > Anyways, 5878/4680 seem like unnecessary layers of parsing. > > > >> - Related to previous: why is it necessary for SCTs and > >> MerkleTreeLeafs to have different cases for precerts and certs? Could > >> the signature be calculated on a "normalized" form of the > >> TBSCertificate which is the same for certs and precerts (i.e. the > >> TBSCertificate with poison and SCT extensions removed?) > > > > We did consider that, but it is not what the code does currently. > > There's no particular reason it could not be done that way, as far as > > I currently know. > > It would seem simpler, since clients would not need separate code > paths for precerts and "fully-logged" certs. Also, this would > simplify the data structures since you could eliminate the > "entry_type" from the LogEntry, SCT, and MerkleTreeLeaf. > Not strongly opposed to it, though it would leverage the re-signing attack you describe below to existing certificates, too. > Related comment: There should probably be Security Considerations > about logging TBSCertificates, since I think there are some subtle > issues that arise from logging TBSCertificates if you're using > revocation systems based on the full certificate (like OCSP, CRLsets, > etc.). > > For example, a rogue CA could potentially issue a rogue sub CA with > the same name as some existing CA, and this rogue sub CA could issue > rogue certs with TBSCertificates that match existing certificates. If > such a rogue certificate was issued that matched a revoked cert for > which an attacker had compromised the private key, the rogue cert > could be used with the revoked cert's SCT, but might not itself be > revoked (since revocation methods like OCSP and CRLsets scope > revocations to the issuer's key hash). > > So, revocation systems would need to be cognizant of this risk and > revoke the TBSCertificate, it seems? > A little far-fetched as an attack - but yes. CAs can include an Authority KeyID extension in new (TBS)Certificates logged by CT, to protect against this. > > >> (4) Why is the SCT's timestamp and CtExtensions included in the > >> MerkleTreeLeaf? If the Merkle Tree was built directly on hash(cert) > >> leaves instead of hash(SCT fields), then the audit path mechanism > >> could be deployed earlier / independently from SCTs, > [...] > > 2. If you built a Merkle tree based on the cert alone, what would the > > correct action of a client which saw a cert with no SCT be? Sure, it > > could check the log and see it was not in it - but then what? It can't > > reject it, perhaps it is the first CT-enabled client to see the cert > > (or one of the first). The fact it lacks an SCT shows it hasn't > > participated in voluntary logging. So the correct action is to log it, > > and obtain an SCT for it > > Or just report it to someone you trust who logs it for you - the > browser doesn't need the SCT in this case. > > > > So why not just always attempt to log it? > > It's more efficient if the browser could fetch an audit proof without > also needing an SCT, and it would be simpler if Merkle Tree Leaves > were just defined like: > > struct { > Version version; > opaque tbscertificate<1...65535>; > } > } MerkleTreeLeaf; > > I guess these aren't the strongest arguments, but I don't see that > this simplication loses anything important. > We don't know what the CT extensions will be yet but I imagine we'll want to have them included in the tree, so that monitors can examine them. Also, the SCT timestamps serve as a hint for the location of the entry in the tree - makes it easier to design efficient privacy-friendly client protocols (briefly mentioned in Sect. 7.3 of the current draft version). Best, Emilia > > In any case, we are not primarily attempting to build a system that > > solves a half-way problem - we want full deployment of CT. > > Sure, but if it's going to take awhile to get SCTs universally > deployed, it would be nice to get some of the benefits of CT earlier. > That's why I like the idea of using scanning and online checks to > populate logs until SCTs are ubiquitous (at which point the CAs and > TLS servers will have assumed the responsibility of populating logs). > > > [1] There are, of course, distinct weaknesses compared to a system > > built on SCTs - for example, the tree is no longer self-timestamping > > and so claims about timing become more difficult to substantiate. > > I don't see the weakness - the log is ordered, periodically signed > with a timestamp (TreeHeadSignature), and monitored, so won't you have > good timing data for log entries regardless? > > > Trevor > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > --f46d0435c03c40e94304d407b197 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jan 23, 2013 at 8:25 PM, Trevor Perrin &l= t;trevp@trevp.net&= gt; wrote:
On Tue, Jan 22, 2013 at 4:19 PM, Ben La= urie <benl@google.c= om> wrote:
> On 22 January 2013 23:07, Trevor Perrin <trevp@trevp.net> wrote:
>
>> (2) Why are the RFC 5878 / RFC 4680 Authorization Exten= sion and
>> SupplementalData mechanisms used to convey the SCT, instead of
>> defining a new TLS Extension?
[...]
>
> At the time the mechanism was defined, Experimental track was more
> standardised than what we were defining. We could indeed contemplate > defining our own extension if we go beyond Experimental ourselves.

Defining your own TLS Extension seems simpler, why not do it from the= start?

I'd be curious if potential implementors have an opinion. =A0The
difference is roughly:

We've alread= y implemented 5878 for OpenSSL and Apache. The wider benefit of a more gene= ral mechanism is that adding new types of authorization data (Revocation Tr= ansparency?) will in the future not require upgrading servers again.


WITH A CT TLS EXTENSION:
=A0- ClientHello contains a TLS extension to indicate CT support
=A0- ServerHello contains a TLS extension with:
=A0 =A0- 2 byte length of SignedCertificateTimestampList
=A0 =A0- sequence of:
=A0 =A0 =A0- 2 byte length of SCT
=A0 =A0 =A0- SCT

WITH THE 5878 TLS EXTENSION:
=A0- ClientHello contains a TLS extension with a list of single-byte
values, one of which indicates CT support
=A0- ServerHello contains a TLS extension with a list of single-byte
values, one of which indicates SCTs are present
=A0- Following ServerHello is an RFC 4680 SupplementalData message:
=A0 =A0- 3 byte length
=A0 =A0- sequence of SupplementalDataEntry, each with:
=A0 =A0 =A0- 2 byte type
=A0 =A0 =A0- 2 byte length
=A0 =A0 =A0- (if type =3D "authz_data", then the body of this ent= ry is):
=A0 =A0 =A0 =A0- 2 byte length
=A0 =A0 =A0 =A0- sequence of AuthorizationDataEntry, each with:
=A0 =A0 =A0 =A0 =A0- 1 byte type (which may indicate an SCT is present)
=A0 =A0 =A0 =A0 =A0- (length field for SCT? =A0unclear in draft-05)
=A0 =A0 =A0 =A0 =A0- SCT

(I think this is right but the structures in 5878 section 3 don't
actually match 4680 (errata?), nor does draft-05 define the encoding
of an SCT into an AuthorizationDataEntry, so I'm not sure.)

Anyways, 5878/4680 seem like unnecessary layers of parsing.


>> =A0- Related to previous: why is it necessary for SCTs and
>> MerkleTreeLeafs to have different cases for precerts and certs? = =A0Could
>> the signature be calculated on a "normalized" form of th= e
>> TBSCertificate which is the same for certs and precerts (i.e. the<= br> >> TBSCertificate with poison and SCT extensions removed?)
>
> We did consider that, but it is not what the code does currently.
> There's no particular reason it could not be done that way, as far= as
> I currently know.

It would seem simpler, since clients would not need separate code
paths for precerts and "fully-logged" certs. =A0Also, this would<= br> simplify the data structures since you could eliminate the
"entry_type" from the LogEntry, SCT, and MerkleTreeLeaf.

Not strongly opposed to it, though it would lev= erage the re-signing attack you describe below to existing certificates, to= o.
=A0
Related comment: There should probably be Security Considerations
about logging TBSCertificates, since I think there are some subtle
issues that arise from logging TBSCertificates if you're using
revocation systems based on the full certificate (like OCSP, CRLsets,
etc.).

For example, a rogue CA could potentially issue a rogue sub CA with
the same name as some existing CA, and this rogue sub CA could issue
rogue certs with TBSCertificates that match existing certificates. =A0If such a rogue certificate was issued that matched a revoked cert for
which an attacker had compromised the private key, the rogue cert
could be used with the revoked cert's SCT, but might not itself be
revoked (since revocation methods like OCSP and CRLsets scope
revocations to the issuer's key hash).

So, revocation systems would need to be cognizant of this risk and
revoke the TBSCertificate, it seems?

A little far-fetched as an attack - but yes. CAs can include an Authori= ty KeyID extension in new (TBS)Certificates logged by CT, to protect agains= t this.



>> (4) Why is the SCT's timestamp and CtExtensions included in th= e
>> MerkleTreeLeaf? =A0If the Merkle Tree was built directly on hash(c= ert)
>> leaves instead of hash(SCT fields), then the audit path mechanism<= br> >> could be deployed earlier / independently from SCTs,
[...]
> 2. If you built a Merkle tree based on the cert alone, what would= the
> correct action of a client which saw a cert with no SCT be? Sure, it > could check the log and see it was not in it - but then what? It can&#= 39;t
> reject it, perhaps it is the first CT-enabled client to see the cert > (or one of the first). The fact it lacks an SCT shows it hasn't > participated in voluntary logging. So the correct action is to log it,=
> and obtain an SCT for it

Or just report it to someone you trust who logs it for you - the
browser doesn't need the SCT in this case.


> So why not just always attempt to log it?

It's more efficient if the browser could fetch an audit proof wit= hout
also needing an SCT, and it would be simpler if Merkle Tree Leaves
were just defined like:

=A0 =A0 =A0 =A0struct {
=A0 =A0 =A0 =A0 =A0 =A0Version version;
=A0 =A0 =A0 =A0 =A0 =A0opaque tbscertificate<1...65535>;
=A0 =A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0} MerkleTreeLeaf;

I guess these aren't the strongest arguments, but I don't see that<= br> this simplication loses anything important.

=
We don't know what the CT extensions will be yet but I imagi= ne we'll want to have them included in the tree, so that monitors can e= xamine them.

Also, the SCT timestamps serve as a hint fo= r the location of the entry in the tree - makes it easier to design efficie= nt privacy-friendly client protocols (briefly mentioned in Sect. 7.3 of the= current draft version).

Best,
Emilia


> In any case, we are not primarily attempting to build a system that > solves a half-way problem - we want full deployment of CT.

Sure, but if it's going to take awhile to get SCTs universally deployed, it would be nice to get some of the benefits of CT earlier.
That's why I like the idea of using scanning and online checks to
populate logs until SCTs are ubiquitous (at which point the CAs and
TLS servers will have assumed the responsibility of populating logs).

> [1] There are, of course, distinct weaknesses compared to a system
> built on SCTs - for example, the tree is no longer self-timestamping > and so claims about timing become more difficult to substantiate.

I don't see the weakness - the log is ordered, periodically signe= d
with a timestamp (TreeHeadSignature), and monitored, so won't you have<= br> good timing data for log entries regardless?


Trevor
_______________________________________________
therightkey mailing list
therightkey@ietf.= org
https://www.ietf.org/mailman/listinfo/therightkey

--f46d0435c03c40e94304d407b197-- From lear@cisco.com Tue Jan 22 22:07:33 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8014121F84B6; Tue, 22 Jan 2013 22:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwTlCSAhVloE; Tue, 22 Jan 2013 22:07:32 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB2921F84C9; Tue, 22 Jan 2013 22:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=628; q=dns/txt; s=iport; t=1358921252; x=1360130852; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IHpHzkU+hCIrY7Uh9MmT8geXRf+ityodLsHjvNCKE3M=; b=T71PQBPfoRrGXp8eB/xIi1qETAOzAXHzbe++T3ZzHEoHK//pUIHBOkfS Vi37TW6H7PETlU4vQwCylcrCLDk6B2okcKra5Fg0s7R1sCIVScwUSQDJN 2qhdh48ZfNdUrNzcCBNHyc0FYbsn2/4VQaJZu7BxqXR2ZAZ0aYQYm1Rd9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFANp8/1CQ/khR/2dsb2JhbABEhX5Ht2UWc4IeAQEBBCNVARALGAICBRYLAgIJAwIBAgFFBg0BBwEBiBUMqhWSZwSBI48AgRMDlgyQSYJ2 X-IronPort-AV: E=Sophos;i="4.84,520,1355097600"; d="scan'208";a="11265509" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 23 Jan 2013 06:07:30 +0000 Received: from dhcp-10-55-93-149.cisco.com (dhcp-10-55-93-149.cisco.com [10.55.93.149]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0N67Ujq027905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2013 06:07:30 GMT Message-ID: <50FF7E24.3070908@cisco.com> Date: Wed, 23 Jan 2013 07:07:32 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: =JeffH References: <50FF06CD.2050002@KingsMountain.com> In-Reply-To: <50FF06CD.2050002@KingsMountain.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 24 Jan 2013 08:06:01 -0800 Cc: draft-laurie-pki-sunlight-05.all@tools.ietf.org, therightkey@ietf.org, The IESG , Apps Discuss Subject: Re: [therightkey] "mis-issued" was: apps area review of draft-laurie-pki-sunlight-05 (Eliot's version) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 06:07:33 -0000 Defining it on first use is fine. That would also go with explaining the use-case for this experiment better. Just keep in mind your non-native readers. On 1/22/13 10:38 PM, =JeffH wrote: > > "Misissued" is not a word. > > but "mis-issued" is a legit contraction, so perhaps it's simply > misspelled (and a definition should probably be provided). > > "mis-issue" and "mis-issued" refer to the situation where a CA issues > a cert for a given subject (i.e. domain name) when they should not > have. C.f. Diginotar. > > See also: https://tools.ietf.org/html/draft-ietf-pkix-caa-15 > > HTH, > > =JeffH > > From stephen.farrell@cs.tcd.ie Thu Jan 24 11:12:32 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DAA21F84F2 for ; Thu, 24 Jan 2013 11:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29HcvbQE6Dip for ; Thu, 24 Jan 2013 11:12:31 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 81F8121F84D7 for ; Thu, 24 Jan 2013 11:12:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5B62BBE56 for ; Thu, 24 Jan 2013 19:12:09 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GM-Cp9i536LC for ; Thu, 24 Jan 2013 19:12:05 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.41.6.39]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A70CDBE49 for ; Thu, 24 Jan 2013 19:12:05 +0000 (GMT) Message-ID: <51018785.9040905@cs.tcd.ie> Date: Thu, 24 Jan 2013 19:12:05 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "therightkey@ietf.org" References: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [therightkey] Fwd: [secdir] dir review of draft-laurie-pki-sunlight-05 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 19:12:33 -0000 Forwarding. S -------- Original Message -------- Subject: [secdir] dir review of draft-laurie-pki-sunlight-05 Date: Thu, 24 Jan 2013 14:06:33 -0500 From: Jeffrey Hutzelman To: iesg@ietf.org, secdir@ietf.org, draft-laurie-pki-sunlight.all@tools.ietf.org CC: jhutz@cmu.edu I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes an experimental protocol for publicly logging the existence of certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority activity and notice the issuance of suspect certificates, as well as to audit the logs themselves. The intent is that eventually clients would refuse to honor certificates which do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Overall, the approach used here looks reasonable. However, I have a few specific comments, and also recommend that the security area directors pay special attention to this document, as it has the potential to have far-reaching effects if the experiment is successful. The abstract for this document is four paragraphs and takes up an entire page. It could be a lot shorter. For example, I think my one-paragraph summary above is sufficient to fill the role of an abstract, which is to allow the reader to find out what a document is about and decide whether he wants to read it. This document makes extensive use of RFC2119 requirements language, but the body of the document does not contain text incorporating the meanings of these terms. Instead, the usual text is hidden in a "Requirements Language" section which appears just below the abstract, outside the main body of the document. This should be moved into the document proper. For describing its messages and data structures, this document makes extensive use of a language which is unfamiliar to me and for which no reference is given. I can make some guesses as to what it means, but guesswork does not make for interoperable implementations. I'm concerned that this document attempts to specify operational policy, particularly for operators of logs. As the saying goes, "MUST is for implementors"; statements like "Anyone can submit a certificate to any log" are inappropriate for protocol specifications. In practice, it seems likely that log operators will establish policies regarding both who may submit certificates and which certificates they will accept, and no amount of MUST in a protocol spec is going to change that. Similarly, as an anti-spam measure, this document proposes that logs accept only certificates which chain back to a known CA, and requires that logs validate each submitted certificate before appending it to the log. This sounds good, but it's not the only possible mechanism, and so I think MUST is too strong here. Additionally, there is no discussion of the security implications if a client depends on a log to do this and the log does not actually do so. Rather than requiring that logs validate every submitted certificate, the document should only RECOMMEND that they do so, and make clear that clients MUST NOT depend on such validation having been done. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From trevp@trevp.net Thu Jan 24 13:18:32 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DDC21F85E2 for ; Thu, 24 Jan 2013 13:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=-1.428, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cb+BEaVFqZCz for ; Thu, 24 Jan 2013 13:18:31 -0800 (PST) Received: from mail-wi0-x22a.google.com (wi-in-x022a.1e100.net [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 29F3E21F85C2 for ; Thu, 24 Jan 2013 13:18:30 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq7so895475wib.1 for ; Thu, 24 Jan 2013 13:18:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=lIpEeejI9GX7si06j0/oetJjCCor1OyndbUMBDdybpo=; b=EBFjX6MTP3uPSaTIYaaB0kvoxCOUtLd2qsm5WIb8kkHNChWQp1DpEhbDUEbkC3dd1C 0wapep7ZIiNIN9lEbleKh0xjIf47p6YETAJbR59ps4Kn6HZDkwOZr5k9a8Q3XRdb4DNs TFhwoCdFSDtMv3DGXUtVXApD5mpyEX/5WVVYTcrcI0OJd9ryKzwzKxyl2H9df4b4SXT8 iNnoU1lZZgaHU1Xc68qarW/Xs1ZnaMhe1eCUWJCVZQbwTyD+lCqQ1kA6G1sWaB2WurWO LHGPLA3/oqPCNbLfoGTQ6GT5Khg26g6nmbMc2jLqqUggD8Wae4C0YcELEkg3UUiM91DT 8cCw== MIME-Version: 1.0 X-Received: by 10.181.13.75 with SMTP id ew11mr5408632wid.9.1359062310202; Thu, 24 Jan 2013 13:18:30 -0800 (PST) Received: by 10.216.242.141 with HTTP; Thu, 24 Jan 2013 13:18:29 -0800 (PST) X-Originating-IP: [166.137.212.37] In-Reply-To: References: Date: Thu, 24 Jan 2013 13:18:29 -0800 Message-ID: From: Trevor Perrin To: Emilia Kasper Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmoUzmKgsdRIC78wnwQqBpWUsdH9nNZ1yEXYxv+cvh0WJgS7qZf7uczi6Zo4d/2f7q0VOsP Cc: "therightkey@ietf.org" , Ben Laurie Subject: Re: [therightkey] CT Qs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 21:18:32 -0000 Hi Emilia, I'll comment on 5878 separately, to your other points: On Thu, Jan 24, 2013 at 4:10 AM, Emilia Kasper wrote: >> >> >> - Related to previous: why is it necessary for SCTs and >> >> MerkleTreeLeafs to have different cases for precerts and certs? Could >> >> the signature be calculated on a "normalized" form of the >> >> TBSCertificate which is the same for certs and precerts (i.e. the >> >> TBSCertificate with poison and SCT extensions removed?) >> > >> > We did consider that, but it is not what the code does currently. >> > There's no particular reason it could not be done that way, as far as >> > I currently know. >> >> It would seem simpler, since clients would not need separate code >> paths for precerts and "fully-logged" certs. Also, this would >> simplify the data structures since you could eliminate the >> "entry_type" from the LogEntry, SCT, and MerkleTreeLeaf. > > > Not strongly opposed to it, though it would leverage the re-signing attack > you describe below to existing certificates, too. I guess, though a rogue CA #2 could submit precerts for existing certs, thus exposing them to this attack from other rogue CAs... even more far-fetched, I admit, but I tentatively think there should be a better solution to that attack in general, as opposed to just partly limiting who is exposed to it. >> Related comment: There should probably be Security Considerations >> about logging TBSCertificates, since I think there are some subtle >> issues that arise from logging TBSCertificates if you're using >> revocation systems based on the full certificate (like OCSP, CRLsets, >> etc.). >> >> For example, a rogue CA could potentially issue a rogue sub CA with >> the same name as some existing CA, and this rogue sub CA could issue >> rogue certs with TBSCertificates that match existing certificates. If >> such a rogue certificate was issued that matched a revoked cert for >> which an attacker had compromised the private key, the rogue cert >> could be used with the revoked cert's SCT, but might not itself be >> revoked (since revocation methods like OCSP and CRLsets scope >> revocations to the issuer's key hash). >> >> So, revocation systems would need to be cognizant of this risk and >> revoke the TBSCertificate, it seems? > > > A little far-fetched as an attack - but yes. CAs can include an Authority > KeyID extension in new (TBS)Certificates logged by CT, to protect against > this. I think the Authority Key Identifier is matched against whatever Subject Key Identifier is declared in the issuing CA cert. So, I *think* it can be chosen by an attacker to match a target TBSCertificate, and doesn't help here? Maybe there should be some other X.509v3 critical extension, allowing the TBSCertificate to contain a reference to the issuer's public key? That might be easier than modifying revocation systems? >> It's more efficient if the browser could fetch an audit proof without >> also needing an SCT, and it would be simpler if Merkle Tree Leaves >> were just defined like: >> >> struct { >> Version version; >> opaque tbscertificate<1...65535>; >> } >> } MerkleTreeLeaf; >> >> I guess these aren't the strongest arguments, but I don't see that >> this simplication loses anything important. > > > We don't know what the CT extensions will be yet but I imagine we'll want to > have them included in the tree, so that monitors can examine them. > > Also, the SCT timestamps serve as a hint for the location of the entry in > the tree - makes it easier to design efficient privacy-friendly client > protocols (briefly mentioned in Sect. 7.3 of the current draft version). Hmm. You could always define a new leaf type if you need extensibility, and having clients lookup entries based on time ranges (or leaf_index ranges) doesn't seem to require actually hashing the SCT's timestamp into the leaf. So I'm not convinced you're gaining anything worth the loss in simplicity and flexibility of a simpler leaf based directly on certificates. But it's a design decision, there's arguments both ways... Trevor From trevp@trevp.net Thu Jan 24 16:26:45 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2196B11E80D1 for ; Thu, 24 Jan 2013 16:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.776, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAqmjIHZiK53 for ; Thu, 24 Jan 2013 16:26:44 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 51AEB11E8099 for ; Thu, 24 Jan 2013 16:26:44 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id 15so3144967wgd.28 for ; Thu, 24 Jan 2013 16:26:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:cc:content-type:x-gm-message-state; bh=y5wqiQe2yNYKNMtWnqGFIAS3Jze8Dhtufk/YMglNpMA=; b=EY2wLUjw/+Qjj7B5ZRPXd47qbsg8AxbPHom0LgOng27+8baZ6v+iJRnncxKRsDk2Up 6nzXBzK/hEe8nGWyxfrPSE42gZfXDDjs1zq5vpqi4YSRHOAONemiGdz1JK2/l3hnibbH DP6w3LK4UN/2v1Cq7vtPFJK0QmUk8JJ6ORGNov9ydufP6lNYw+E4WWWRfofTXMid9/yQ My5N68GRkNuuqxJb1zNewAXuI6V8WvP4aWmc/NwwYWbiplx0r0tCUstVZyoF2DUrGC+B rPl01gB63wkwGNzqc8FeSr4gECnTV8k5eyWjOdKXSxcujVrBJARz0tdmykiUOJwUeTq+ 1TKQ== MIME-Version: 1.0 X-Received: by 10.194.108.101 with SMTP id hj5mr6066413wjb.6.1359073603361; Thu, 24 Jan 2013 16:26:43 -0800 (PST) Received: by 10.216.242.141 with HTTP; Thu, 24 Jan 2013 16:26:43 -0800 (PST) X-Originating-IP: [166.137.212.37] Date: Thu, 24 Jan 2013 16:26:43 -0800 Message-ID: From: Trevor Perrin To: Emilia Kasper Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnecrgXX9t4+TsKmHuLk614EXTDtMaW4txXyO6lmxkDFaGdUrUyE1aVKkVCMHUJFOkFBuPh Cc: "therightkey@ietf.org" , Ben Laurie Subject: [therightkey] CT and RFC 5878 (was Re: CT Qs) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 00:26:45 -0000 On Thu, Jan 24, 2013 at 4:10 AM, Emilia Kasper wrote: > On Wed, Jan 23, 2013 at 8:25 PM, Trevor Perrin wrote: >> >> Defining your own TLS Extension seems simpler, why not do it from the >> start? To expand on this: RFC 5878 seems unnecessary for server-provided data such as CT's SignedCertificateTimestamps (or similar things like TACK [1]). TLS already has an extension mechanism. 5878 uses this extension mechanism to add a new extension mechanism. But the new mechanism seems pointlessly redundant, complex, and not widely implemented. It's also poorly designed and specified: * 5878 builds on the SupplementalData TLS handshake message defined in 4680. But 5878's extension of 4680 appears wrong: The "SupplementalData" structure in 5878 does not match the same-named structure in 4680. I think 5878 is trying to extend 4680's SupplementalDataEntry, but it's still wrong (missing supp_data_length). * 5878's AuthorizationDataEntry has no overall length field, thus is not generically parseable (it can only be handled by a parser which knows the structure corresponding to each authz_format it encounters). The OpenSSL implementation [2] attempts to parse it by assuming every AuthorizationDataEntry contains a 2-byte overall length field following the 1-byte type, but this is incorrect (see URLandHash in 5878). The claim is: > We've already implemented 5878 for OpenSSL and Apache. The wider benefit of > a more general mechanism is that adding new types of authorization data > (Revocation Transparency?) will in the future not require upgrading servers > again. But this isn't an inherent virtue of 5878, it's due to the CT team adding functionality to OpenSSL and Apache that allows specifying server responses in a data file [3]. The server can parse the data file and return whichever responses the client asks for, without needing code changes to know their meaning. That's a great mechanism, but why not apply it to TLS Extensions? Then we could deploy CT's timestamps (or other server auth data) without needing server code changes *or* 5878. That would be the best of both worlds, wouldn't it? Trevor [1] http://tools.ietf.org/html/draft-perrin-tls-tack [2] For OpenSSL, see ssl_rsa.c:authz_validate(), and incorrect comment in ssl_locl.h: /* authz/authz_length contain authz data for this certificate. The data * is in wire format, specifically it's a series of records like: * uint8_t authz_type; // (RFC 5878, AuthzDataFormat) * uint16_t length; * uint8_t data[length]; */ [3] OpenSSL's SSL_CTX_use_authz_file(), Apache's SSLRSAAuthzFile directive From benl@google.com Fri Jan 25 03:16:22 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2338A21F8833 for ; Fri, 25 Jan 2013 03:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pP5e4xOBHDv2 for ; Fri, 25 Jan 2013 03:16:20 -0800 (PST) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBA421F87FA for ; Fri, 25 Jan 2013 03:16:19 -0800 (PST) Received: by mail-bk0-f50.google.com with SMTP id jf3so155126bkc.23 for ; Fri, 25 Jan 2013 03:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=edE3TD/MdoX82Lxo2iSlEi38ZQHJETgOfhu6MXeHQwE=; b=g3DCoBN1LO3Wjn+E9GbHLFJkWG98v1MjHHMSmLfxMle+wXbMiZpeoSzCR8W7nub3Ku iMf3UAa2mdP4f6Dj8X+aDUt7eFNLk9JHN97NJWLu96nE/D1HiSBWy3LeezMMIVFl3q/4 3b/3vOQSNgG+1xfLx8cSpbugjNohb/79OA8wNgsnqnPQcSeZXys4O4z8YuAh+j8FLfq4 A4WzndNZDCoKwnsEAOStG4I5JN6Bc+1H0A/97oWrzY0SJSVKeuV1TMBQgglFWQQZyRnB BMl4VtTUdD0sqYTYwaDmroWBd84UBwNOP2ytB34MSMP7cCOxFBqrdvTkC3bkSQnVw4Cf W4rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=edE3TD/MdoX82Lxo2iSlEi38ZQHJETgOfhu6MXeHQwE=; b=Qtx5iLmQlFIv2yKIEbSTsZ1XOYZhM0/FTXysNgqRdYNZf6k1oc89RSoHvnwiGSHFAH IOym/iWvS9CJWbHmct7vyrUXZmXkTcBN2Bj4Xt0XnkrvSlE3Xr3EFxBE8AqEUPwONnmK oDcvzYVPuoL3A0LMzNzguerCc4vUgW7mcVH2OOdUXICJRn8DHUYoifYbWUz8umx+i/e9 3xkKjTKf5qgtvCcNq11P8wdYyLoIOqDKQqJhamWj6bVJ1cQt7wOZ5O/lgnSkRt0yckhf 5eNBnxfIO7unYuWjd7IAx0mwClCGbo4npw8LIp6mIr+RjsMZvNHN/PczYT7pTvqm92q+ GzeQ== MIME-Version: 1.0 X-Received: by 10.204.141.4 with SMTP id k4mr1735727bku.60.1359112578417; Fri, 25 Jan 2013 03:16:18 -0800 (PST) Received: by 10.204.38.198 with HTTP; Fri, 25 Jan 2013 03:16:18 -0800 (PST) Date: Fri, 25 Jan 2013 11:16:18 +0000 Message-ID: From: Ben Laurie To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkndjOQDR48JDhg14TX5kOL3d+4lhnvkKMf4obn63wqWloyVLo+kVFSAtHXZJjetgTrXcswzcpkQILzgzmHcLfUkoFkGBwbSlRrUQIAO9bl13G96/iBgbHt0FJ3sSoeiYdZdErvl41wdmou6hDmHkaiqmNcqqAbsPn5TAVG0VLKJchlC9vYCFgBnWSSczBhnNHf/Ufv Cc: Emilia Kasper , "therightkey@ietf.org" , IETF Discussion List , Adam Langley Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 11:16:22 -0000 Apologies for responding to recent comments in random order: I'm travelling and have accumulated something of a backlog. On 22 January 2013 03:11, =JeffH wrote: > apologies for latency, many meetings and a conference in the last couple of > weeks. > > BenL replied: >> On 1 January 2013 21:50, =JeffH wrote: > > [ in the below discussion: > > "the spec", "this spec" refers to draft-laurie-pki-sunlight-05. > > "TLS-CT client" refers to a TLS client capable of processing CT information > that is included in the TLS handshake in any of the specified manners. > > "ok" means in general: "ok, will check this in next rev of the spec..". > > ] > > >>> >>> comments on draft-laurie-pki-sunlight-05 >>> >>> substantive comments (in somewhat arbitrary order) >>> -------------------------------------------------- >>> > > [ I demoted the comments wrt "JSON object" terminology and put them down at > the end of this msg ] > > >>> Also, the syntax for GETS isn't fully specified. Are the URL parameters >>> to >>> be encoded as (order independent) key-value pairs, or just as >>> order-dependent values? Which separator character is to be used between >>> parameters? RFC3986 should be cited. >> >> RFC 3986 says nothing about parameter format, though > > correct, it doesn't, and I wasn't trying to imply that it did, sorry. I was > just trying to say that RFC3986 should be cited in this spec because this > spec normatively employs URLs, but perhaps referencing RFC2616 HTTP is > better because it defines "http_URL". ok. >> - is there a >> standard reference for that? I've refereced HTML 4.01, but perhaps >> there's a better one? > > hm, AFAICT, there is not a standard for URI query component formating and > thus parameter encoding, so this spec will have to explicitly specify > something. Section 3.4 of RFC3986 gives allowed chars for the query > component, but that's about it. > > Have you mocked up code that parses the log client messages? If so, what > query component syntax does it handle? I have specified the "standard" format via HTML 4.01. >>> 3. There appear to be three defined methods for TLS servers to provide >>> TLS >>> clients with CT data, in S3.2. For this experiment, which approach is >>> mandatory to implement for servers and clients? Or, is it the case that >>> participating TLS clients (ie web browsers etc) implement all three >>> methods, >>> and TLS servers can choose any of them? >> >> The latter. > > That should be made very clear. Is the reason for doing so to obtain > operational experience wrt the three defined methods such that they perhaps > can be narrowed down in the future, or is the expectation that TLS-CT > clients will need to support all three methods in perpetuity? I think I made that clear. The reason three methods exist are as follows (I don't intend to get into this in the RFC, but for your edification): 1. TLS extension is the right way to do it, but requires a server s/w change - this adds many years to full deployment. 2. So, alternatives must be provided. One is to put the stuff in the certificate, but... 3. ... some CAs have said they'd rather not gate issuance on the log, so alternatively, wedge the stuff in an OCSP response (which must be stapled - servers exist that support this option already). >>> 5. The recursive equations in S2.1 describe how to calculate a Merkle >>> Tree >>> Hash (MTH) (aka "root hash"), and thus as a side effect generate a Merkle >>> Tree, for a given set of input data. However, there doesn't seem to be a >>> defined algorithm (or even hints, really) for adding further inputs to an >>> existing tree. Even though this may be reasonably left as an exercise for >>> implementers, it should probably be discussed to some degree in the spec. >>> E.g., note that leaf hashes are "frozen" and various interior tree node >>> hashes become "frozen" as the tree grows. Is it not sub-optimal to employ >>> the obvious default brute-force mechanism of rebuilding a tree entirely >>> from >>> scratch when new inputs are available? Would not a recursive algorithm >>> for >>> adding new inputs to an existing tree be straightforward to provide? >> >> I dunno about straightforward. > > yeah, agreed. > > >> I'll think about it. > > ok. At least providing some hints would be useful it seems. We do provide working code :-) >>> 6. Signed tree heads (STHs) are denoted in terms of "tree size" (number >>> of >>> entries), but SCTs are denoted in terms of a timestamp. Should there be >>> a >>> log client message supporting the return of the nearest STH (and thus >>> tree >>> size) to a given timestamp? >> >> I'm not sure why? Any STH (that includes that SCT) will do. > > Hm, it was sort of a gut feel that it might be useful, but perhaps not. > > S5.2. Auditor says.. > > A certificate accompanied by an SCT can be verified against any STH > dated after the SCT timestamp + the Maximum Merge Delay by requesting > a Merkle Audit Proof using Section 4.5. > > S4.5 get-proof-by-hash stipulates tree_size as an input, but > if a log auditor doesn't already have tree_size, then I suppose it first > calls S4.3 get-sth, which will return a timestamp and a tree_size, which if > generated max merge delay (MMD) after the SCT was gen'd, ought to be > sufficient, yes? Yes. > I don't see in the spec where/how MMD is published. Does MMD vary per log > service? The latter isn't stipulated in the spec it seems AFAICT ? We have not really figured out how MMD is specified. I suspect it is something that will be agreed between browser vendors and logs. >>> 7. S3 paragraph 2 states that "TLS clients MUST reject certificates that >>> do >>> not have a valid SCT for the end-entity certificate" (i.e., hard-fail). >>> Presummably this requirement is only for TLS clients participating in the >>> CT >>> experiment and that understand this protocol. >> >> Of course - what other way could it be? In other words, all RFCs can >> only say what implementations that conform with them do. >> >>> This, or whatever the >>> requirement actually is, should be further explained. > > I guess what I was getting at is that CT-conformant TLS clients should be > differentiated from non-CT-conformant ones. Stipulating a name for > CT-conformant TLS clients would clarify this (seems to me), e.g. "TLS-CT > client" or something similar. I understand what you're getting at, but not why. CT conformant TLS clients obey all the MUSTs and non-conformant ones do not. That is what MUST means. >>> 8. The spec implies, but doesn't clearly describe, especially in S3.1, >>> that >>> the hashes are "labels" for tree entries, and that given a leaf hash, the >>> log implementation should be able to look up and present the LogEntry >>> data >>> defined in that section. >> >> We actually only require an entry to be retrievable by hash (in >> effect) for the message in 4.7, which we (at least currently) label as >> a debugging message - so I am not sure that logs really are required >> to be able to do that - certainly the system would work fine if they >> couldn't, I believe (other than being unable to provide the debugging >> data). > > I think what I was getting at was that this is stated at the end of S3.2.. > > The leaves of the Merkle Tree are the hashes of the corresponding > "MerkleTreeLeaf" structures. > > ..but it is somewhat confusing because (abstractly) each leaf also contains > (or has a reference to) the LogEntry data (that's defined back in S3.1) > ...if I understand this correctly. I suppose this reflects our own confusion :-) A LogEntry shows that someone we know can be blamed for the creation of the certificate - perhaps indirectly. This is desirable because: a) We want to limit spam, and b) If someone starts misissuing, we probably want to know who that is... However, this information is not need to _fix_ the misissuance, it turns out. It also is not necessarily the information TLS clients may see (because of cross-signing). So, I think we;re a bit ambivalent about the precise role of this information. >>> While in CT, if the input set is an odd number of entries, then the hash >>> of >>> the final single leaf is at layer 1, and is calculated as a leaf hash >>> using >>> 0x00. Thus CT "interior nodes" always have two children, but if the tree >>> has >>> an odd number of entries, the rightmost hash at layer 1 ("j" in the >>> "binary >>> Merkle tree with 7 leaves" figure) is a leaf node hash rather than an >>> interior node hash. >>> >>> >>> O-8. [CrosbyWallach] discusses auditing and gossiping and could be cited >>> as >>> a source for further discussion on those topics. >>> >>> >>> O-9. The notion of "commitments" isn't well defined, and where "add a >>> commitment to D[k:n]" couldn't "add an interior/intermediate node to >>> D[k:n}" be used? >>> >>> Is not the term "commitment" used in [CrosbyWallach] equivalent to the >>> sha256_root_hash (an STH component) in the spec? >>> >>> [CrosbyWallach] uses the term "interior node(s)" while the spec uses >>> "intermediate nodes" (in one place). >> >> CT is not actually derived from [CrosbyWallach], we just mention it as >> a useful reference. > > yeah, it is useful, it would've been much harder to figure out the spec > without it. Is there an existing paper that the spec is based more closely > on? No, we started afresh :-) > The differences between the spec and [CrosbyWallach] doesn't seem to be that > large, and so if there aren't more closely matching paper(s) to cite (?), it > may be worth summarizing the differences between the spec and > [CrosbyWallach] e.g. in an appendix. > > >> "commitment" is a term of cryptographic art. > > so it is, but its definitions in the literature seem to vary somewhat > depending on context. IIUC, the spec uses "commitment" to refer to the hash > labels of intermediate nodes ('interior nodes' in [CrosbyWallach]) as well > as the root hash, yes? > > In S2.1.1, where it says.. > > We prove that the left subtree entries D[0:k] are consistent > and add a commitment to D[k:n]: > > ..it's not clear just what "add a commitment" means. add it (an > intermediate-node hash?) to the list of hashes that the recursive algorthm > is constructing? > > Overall, I'm finding S2.1.1 pretty difficult to parse and sort out. > > E.g., it isn't clear to me how/why/when the apparently boolean 3d parameter > of SUBPROOF is either true or false, and whether there's an implied "if b > then ... else ..." in there somewhere. Its reasonably hard to define this thing rigorously, and so I'm not surprised you find it hard to follow - but as I think I've said before, we did try various different phrasings and did not find an easier one. Suggestions welcome. >>> O-10. The recursive algorithms in S2 are dense and take effort to work >>> through, perhaps adding simplistic example code (in an appendix) which >>> implements, and/or actually working through the algorithms to arrive at >>> some >>> of the audit paths and consistency proofs in S2.1.3, would be helpful. >> >> We have actual working code - would a reference to that be better? > > I don't know if it would be better (I've compiled it and am poking through > the code). I sorta think pseudo code in an appendix that would generate the > trees in S2.1.3. would be helpful. I suspect this is more relevant to a non experimental RFC - right now I have no evidence that anyone is planning to actually write code other than us - AFAIK, so far everyone who has played with it has used our code. >>> O-14. Detailed comments on S2... >>> ------------------------------ >>> >>>> 2. Cryptographic components >>>> >>>> >>>> 2.1. Merkle Hash Trees >>>> >>>> >>>> Logs use a binary Merkle hash tree for efficient auditing. The >>>> hashing algorithm is SHA-256 (note that this is fixed for this >>>> experiment but it is anticipated that each log would be able to >>>> specify a hash algorithm). The input to the Merkle tree hash is a >>>> list of data entries; these entries will be hashed to form the leaves >>>> of the Merkle hash tree. The output is a single 32-byte root hash. >>>> Given an ordered list of n inputs, D[n] = {d(0), d(1), ..., d(n-1)}, >>>> the Merkle Tree Hash (MTH) is thus defined as follows: >>>> >>>> The hash of an empty list is the hash of an empty string: >>>> >>>> MTH({}) = SHA-256(). >>> >>> >>> This MTH({}) construct doesn't appear to be used anywhere else in the >>> spec >>> (yes?), and so does it really need mentioning? >> >> If it is not defined, then we cannot represent an empty tree. > > yeah, I agree from a mathematical completeness perspective. but I still > found it sort of distracting in that I don't know that it's actually germane > from an implementor's perspective. maybe it is because > > >>>> The hash of a list with one entry is: >>>> >>>> MTH({d(0)}) = SHA-256(0x00 || d(0)). >>> >>> >>> The immediately above equation is for leaf entries (yes?), >> >> Yes. >> >>> where in this >>> notation n = 1, perhaps it should be stated explicitly: >>> >>> When n = 1, a leaf entry is denoted, and D[1] = {d(0)}. The leaf hash >>> (LH) for a leaf entry is calculated as: >>> >>> MTH(D[1]) = LH(D[1]) = SHA-256( 0x00 || d(0) ) >> >> Ugh. LH(D[1]) seems meaningless to me. A leaf hash is always of a "1 >> entry tree". > > yeah, for those who have grokked this stuff. for others it isn't immediately > obvious. also, the above comment was motivated in part due to the missing > formal definition for "Leaf Hash" noted in item (4) above. even if the > LH(D[1]) notation isn't used, some additional prose along the lines > suggested above would be helpful to less initiated readers imv. > > > >>>> For n > 1, let k be the largest power of two smaller than n. >>> >>> >>> The unqualified "power of two" phrase is arguably ambiguous. >> >> It is? > > uh, yeah. > > but "let k be a number which is the largest power of two such that..." > isn't. > > >>> Suggested rephrase for this where it occurs throughout section 2.. >>> >>> For n > 1, let k be a number which is the largest power of two >>> such that k = 2^i, 0 <= i < n, and k < n. >> >> If we're going to go down that path, then it should say: >> >> For n > 1, let k be the largest number such that k = 2^i and k < n. >> >> or >> >> For n > 1, let k = 2^i s.t. k < n and 2k >= n. >> >> surely? > > well, yes (i prefer the former), but i think it's also important to > explicitly state 0 <= i < n Why? Its weird! its also not generally true - e.g. n=2 and i=1. >>>> The Merkle Tree Hash of an n-element list D[n] is then defined >>>> recursively as >>> >>> >>> The above statement applies to the combination of the n = 1 equation >>> above >>> and the equation below, and so should perhaps be moved up above the n = 1 >>> equation. >> >> ? It says n > 1, so doesn't apply to n = 1? > > oh yeah huh. > > in any case, I found the prose separation of the "list with one entry" and > the "n > 1" case to be confusing because the former is part of the recursive > definition of MTH(), yes? OK, so D[0] = {} and D[1] = {d[0]} and we should make that more explicit as you say which I expect will make this a lot clearer. > > >>>> MTH(D[n]) = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n])), >>>> >>>> where || is concatenation and D[k1:k2] denotes the length (k2 - k1) >>>> list {d(k1), d(k1+1),..., d(k2-1)}. >>> >>> >>> The above phrase doesn't parse well and is somewhat ambiguous, here it is >>> extracted for clarity: >>> >>> "D[k1:k2] denotes the length (k2 - k1) list {d(k1), d(k1+1),..., >>> d(k2-1)}" >>> >>> >>> How about rephrasing it along the lines of this: >>> >>> D[k1:k2] denotes a sublist {d(k1), d(k1+1),..., d(k2-1)}, having >>> (k2 - k1) elements, of the original input list D[n]. When (k2 - k1) >>> is 1, a leaf hash is calculated. >> >> We tried lots of different ways of saying this and they were all a >> little messy. Yours mixes concerns and is rather verbose, so not >> convinced it is actually an improvement. > > well, the way it's presently said in the spec is (to me) pretty darn hard to > understand. > > which concerns are missed in the suggested reformulation? I said "mixes" :-) That is, it mixes the hashing up with the definition of the list. Other than that, I'm OK with the rephrasing. >>>> Anyone can submit certificates to certificate logs for public >>>> auditing, however, since certificates will not be accepted by clients >>>> unless logged, it is expected that certificate owners or their CAs >>>> will usually submit them. A log is a single, ever-growing, append- >>>> only Merkle Tree of such certificates. >>>> >>>> When a valid certificate is submitted to a log, the log MUST >>>> immediately return a Signed Certificate Timestamp (SCT). The SCT is >>>> the log's promise to incorporate the certificate in the Merkle Tree >>>> within a fixed amount of time known as the Maximum Merge Delay (MMD). >>>> If the log has previously seen the certificate, it MAY return the >>>> same SCT as it returned before. >>> >>> >>> What if the submitted end entity cert is the same, but the certificate >>> chain >>> is different (yet valid)? >> >> The purpose of the chain is to: >> >> a) Prevent spam, and >> >> b) Identify who to blame in the event of a misissue. >> >> Alternate chains presumably don't actually change the direct blame, >> and so I see no reason to do other than what the I-D says - i.e. >> return the same SCT as before. > > ok. tho i wonder if there's any value in caching the alternate chain or the > new portions thereof. Logs are free to keep additional information, of course :-) We probably will. Its not clear that its particularly useful. >>>> TLS servers MUST present an SCT from >>>> one or more logs to the client together with the certificate. TLS >>>> clients MUST reject certificates that do not have a valid SCT for the >>>> end-entity certificate. >>> >>> >>> [ see comment (7) above ] >>> >>> >>>> Periodically, each log appends all its new entries to the Merkle >>>> Tree, and signs the root of the tree. Clients and auditors can thus >>> >>> >>> Should "Clients and auditors" actually be "TLS Clients, log monitors, and >>> log auditors" ? >> >> Bearing in mind that these are actually roles rather than distinct >> entities, it should probably just say "auditors". > > I dunno, that may loose some readers. in any case, the distinction between > roles and distinct entities should probably be mentioned/discussed e.g. in > the Introduction or thereabouts. Yeah. > > > > >>>> 3.1. Log Entries >>>> >>>> >>>> Anyone can submit a certificate to any log. In order to enable >>>> attribution of each logged certificate to its issuer, the log SHALL >>>> publish a list of acceptable root certificates (this list might >>>> usefully be the union of root certificates trusted by major browser >>>> vendors). Each submitted certificate MUST be accompanied by all >>>> additional certificates required to verify the certificate chain up >>>> to an accepted root certificate. The root certificate itself MAY be >>>> omitted from this list. >>>> >>>> Alternatively, (root as well as intermediate) Certificate Authorities >>> >>> >>> Additionally? which manner is the experiment going to operate, or is it >>> TBD >>> ? >> >> Not sure what you mean? The log will accept either type of submission. > > oh, sorry, I meant s/Alternatively/Additionally/ Probably the other way round? In any case, as I said, the log will accept either type - some CAs seem to prefer one, some the other. >>>> Structure of the Signed Certificate Timestamp: >>> >>> >>> The SCT discussion here should probably be its own subsection. >> >> OK. >> >>> >>> >>>> >>>> enum { certificate_timestamp(0), tree_hash(1), 255 } >>>> SignatureType; >>>> >>>> enum { v1(0), 255 } >>>> Version; >>> >>>> >>>> >>>> struct { >>>> opaque key_id[32]; >>>> } LogID; >>>> >>>> opaque CtExtensions<0..2^16-1>; >>>> >>>> "key_id" is the SHA-256 hash of the log's public key, calculated over >>>> the DER encoding of the key represented as SubjectPublicKeyInfo. >>> >>> >>> I'd place the above paragraph regarding "key_id" down below the >>> SignedCertificateTimestamp definition. >>> >>> >>>> struct { >>>> Version sct_version; >>>> LogID id; >>>> uint64 timestamp; >>>> CtExtensions extensions; >>>> digitally-signed struct { >>>> Version sct_version; >>>> SignatureType signature_type = certificate_timestamp; >>>> uint64 timestamp; >>>> LogEntryType entry_type; >>>> select(entry_type) { >>>> case x509_entry: ASN.1Cert; >>>> case precert_entry: ASN.1Cert; >>>> } signed_entry; >>>> CtExtensions extensions; >>>> }; >>>> } SignedCertificateTimestamp; >>>> >>>> The encoding of the digitally-signed element is defined in [RFC5246]. >>> >>> >>> I would add a few words here summarizing that what happens here is that >>> the >>> digitally-signed struct here is replaced in the actual serialized binary >>> structure by a struct DigitallySigned and cross-ref to S4.7 of RFC5246. >> >> Except it isn't :-) > > ok, then I don't understand what's going on here. RFC5246 S4.7 sez... > > A digitally-signed element is encoded as a struct DigitallySigned: > > struct { > SignatureAndHashAlgorithm algorithm; > opaque signature<0..2^16-1>; > } DigitallySigned; > > > ..and I take the "digitally-signed struct" within SignedCertificateTimestamp > to be a "digitally-signed element". Please help me understand what am I > missing? We've actually significantly revamped this whole thing, so hopefully you'll find it clearer in the next version. >>>> 5.1. Monitor >>>> >>>> >>>> Monitors watch logs and check that they behave correctly. They also >>>> watch for certificates of interest. >>> >>> >>> "Monitor" should be "Log Monitor" ? >> >> There's no other kind of monitor :-) > > in the explicit context of this spec, agreed. but in general I > favor/advocate creation and use of more fully descriptive words/phrases so > at least one is more likely to find them with a search when you're wondering > what sort of "monitor" someone down the road is yammering on about. > > [ I would add a terminology section to the spec ] > >>>> 5.2. Auditor >>>> >>>> >>>> Auditors take partial information about a log as input and verify >>>> that this information is consistent with other partial information >>>> they have. An auditor might be an integral component of a TLS >>>> client, it might be a standalone service or it might be a secondary >>>> function of a monitor. >>> >>> >>> "Auditor" should be "Log Auditor" ? >> >> And there's no other kind of auditor. > > see above :) > > e.g. in the overall webpki world, there /are/ other forms of auditors (e.g. > the ones noted here ) and > so it's worth using a more descriptive term, imv. > > >>>> 8. Efficiency Considerations >>>> >>>> >>>> The Merkle tree design serves the purpose of keeping communication >>>> overhead low. >>>> >>>> Auditing logs for integrity does not require third parties to >>>> maintain a copy of each entire log. The Signed Tree Heads can be >>>> updated as new entries become available, without recomputing entire >>>> trees. Third party auditors need only fetch the Merkle consistency >>>> proofs against a log's existing STH to efficiently verify the append- >>>> only property of updates to their Merkle Trees, without auditing the >>>> entire tree. >>> >>> >>> The above could be explained in more detail, and S5.1 should be >>> cross-referenced. Is the last sentence above essentially a summary of >>> step >>> #8 in S5.1? Or are there differences? >> >> It is a summary of 5.1 > > ok, but it'd be helpful to state that and crossref S5.1. Actually, its the auditor not the monitor, but I have referenced it now. > wrt he JSON stuff... > >>> 1. The client messages S4 don't explicitly lay out the syntax for request >>> messages or responses. E.g., for S4.1 "Add Chain to Log", is the input a >>> stand-alone JSON text array, or a JSON text object containing a JSON text >>> array? >>> >>> The term "JSON object" as used in the first paragraph is ambiguous and >>> perhaps what is mean is simply "JSON texts" or "JSON text objects or JSON >>> text arrays". RFC4627 clearly defines "JSON text", and should be cited. >>> But >>> RFC4627 is a little ambiguous itself regarding "JSON object" and so I >>> suggest these definitions: >>> >>> JSON text object: A JSON text matching the "object" ABNF production >>> in Section 2.2 of [RFC4627]. >>> >>> JSON text array: A JSON text matching the "array" ABNF production >>> in Section 2.3 of [RFC4627]. >> >> I agree that RFC 4627 should be cited and I will correct that. > > ok. > >> The >> rest of this confuses me: JSON is a textual representation of >> structured data, as it states in the RFC. It defines an object quite >> clearly >> >> " An object is an unordered collection of zero or more name/value >> pairs, where a name is a string and a value is a string, number, >> boolean, null, object, or array." > > well, yes, but that's in just the introduction of RFC 4627. > >> Defining a "JSON text object" seems pointless to me - clearly a JSON >> object is an object as defined by JSON, surely? Introducing another >> term seems like to add confusion rather than remove it. > > note that "JSON text" is very explicitly defined in RFC4627 at the beginning > of S2 as.. > > A JSON text is a sequence of tokens. The set of tokens includes six > structural characters, strings, numbers, and three literal names. > > A JSON text is a serialized object or array. > > JSON-text = object / array > > the reason I flagged this issue is that I just recently reviewed a different > internet-draft where they'd confused a JSON object -- in the sense of a JSON > text matching the object production of S2.2 RFC4627 -- and a "JSON object" > in the sense of an abstract programming construct, and they didn't > understand that in the protocol on-the-wire world a JSON object /is a > string/ (i.e. it is string-serialized according to the grammar of RFC4627). > > It seems the term "JSON object" is ambiguous depending on whether you're > looking at it from a programming perspective or an on-the-wire protocol > perspective (eg see > which talks about "internal form" and "external form" (ugh)), hence my > (perhaps feeble) attempt to invent a more explicit term for the on-the-wire > protocol form. > > So maybe a more palatable definition would be.. > > JSON object: A JSON text matching the "object" ABNF production > in Section 2.2 of [RFC4627]. ok > > ? > > > --- > end > > > > > > > > From ekasper@google.com Fri Jan 25 08:55:20 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5853F21F8858 for ; Fri, 25 Jan 2013 08:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.749 X-Spam-Level: X-Spam-Status: No, score=-102.749 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g46GfOcvAigi for ; Fri, 25 Jan 2013 08:55:19 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2575921F854E for ; Fri, 25 Jan 2013 08:55:18 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id 8so368035wgl.30 for ; Fri, 25 Jan 2013 08:55:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iZkvx37WVHOBfGbBq8IhlDeqE0H3jHssjSQqF9AeK9M=; b=fhT3MNlUCrgNH5EiggoJnoMlW1/EZE/gfyiZxBmqTwBo99HAEEmRdDGwd7T2D3hwhC WlbPnxQadw/ZtvD59YfxJmbpKjSwdWwQXPHSu4v+ekUVsi8TSt0/9yMON8u5SDx199Qb H93GPX4x+6erkNIjnflYTPpEn85PZp6G+91Alf+W+iZSyvKjDaVwyPml37TQee0FYR53 BDF1oY7qy5tw322BsiaK5yLfz1PuGfufedtfv4L3naTBnAnwlOXpIXbw4L2//pbUKDYQ RjAvLbvB8iZDWceUMf+5XCueDEsqwQ1Mn/dwC7rGjbTzu2NClbc2t7BQ+S0myRfoOuaK ci6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=iZkvx37WVHOBfGbBq8IhlDeqE0H3jHssjSQqF9AeK9M=; b=mPpQaJarhH1bgzgLWnCA4IZGbnJ479OUJVGdtu+yLbFTM/NTUuRRxlLde+D1JhcWUS zEDYQ87KjDCkrmm8fboaFU78+3YrYIaUkWh8wek+1a9Jm77KfBU9BpP5xIZArv1SBn/E TNjABC9JChn9riEQtnyDBCW9yCqAlZlnffr3bCFfbQtsaV0bpbkK/GWcXfUn7g8BHn8U lJwxNWMBjuQuPbwElxOj8+Z+DqTrnfxAxAlNPVu6UDay/kXBwO4P946DKHuUPwnOSBnX b8l4m9lFIcnRXZllvi2ZshJojB9t10UKsTUu4UuD14OlkFB5Sqimr6lLCmVqpjooslga xC1A== MIME-Version: 1.0 X-Received: by 10.180.19.136 with SMTP id f8mr9885799wie.0.1359132918137; Fri, 25 Jan 2013 08:55:18 -0800 (PST) Received: by 10.194.51.231 with HTTP; Fri, 25 Jan 2013 08:55:18 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Jan 2013 17:55:18 +0100 Message-ID: From: Emilia Kasper To: Trevor Perrin Content-Type: multipart/alternative; boundary=bcaec53d5aa3c9c1ff04d41fca70 X-Gm-Message-State: ALoCoQlxCLI3Y57I+t3I0YQ+X6J+5+Z/8A3dsXDHVUcfM8Er4hMDCb9NfzT5IboTITkqQNZYrIt3fQAlwmzL2ADDtEax0ZuFHo+iVbxBbJVHm/ThNiwzW5qOMIHRBbaNeYSCBOM38V+FnDke/vw0dTN8lpU2i2Sy2jI/ovN1T2WlWMfPjamKYPiVXddI0zqDnxqQm+VCIw8T Cc: "therightkey@ietf.org" , Ben Laurie Subject: Re: [therightkey] CT and RFC 5878 (was Re: CT Qs) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 16:55:20 -0000 --bcaec53d5aa3c9c1ff04d41fca70 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 25, 2013 at 1:26 AM, Trevor Perrin wrote: > On Thu, Jan 24, 2013 at 4:10 AM, Emilia Kasper wrote: > > On Wed, Jan 23, 2013 at 8:25 PM, Trevor Perrin wrote: > >> > >> Defining your own TLS Extension seems simpler, why not do it from the > >> start? > > > To expand on this: RFC 5878 seems unnecessary for server-provided > data such as CT's SignedCertificateTimestamps (or similar things like > TACK [1]). > > TLS already has an extension mechanism. 5878 uses this extension > mechanism to add a new extension mechanism. But the new mechanism > seems pointlessly redundant, complex, and not widely implemented. > It's also poorly designed and specified: > > * 5878 builds on the SupplementalData TLS handshake message defined > in 4680. But 5878's extension of 4680 appears wrong: The > "SupplementalData" structure in 5878 does not match the same-named > structure in 4680. I think 5878 is trying to extend 4680's > SupplementalDataEntry, but it's still wrong (missing > supp_data_length). > > * 5878's AuthorizationDataEntry has no overall length field, thus is > not generically parseable (it can only be handled by a parser which > knows the structure corresponding to each authz_format it encounters). > The OpenSSL implementation [2] attempts to parse it by assuming every > AuthorizationDataEntry contains a 2-byte overall length field > following the 1-byte type, but this is incorrect (see URLandHash in > 5878). > Thanks, you're correct - we didn't get it quite right on first attempt. We'll look into it. > > The claim is: > > > We've already implemented 5878 for OpenSSL and Apache. The wider benefit > of > > a more general mechanism is that adding new types of authorization data > > (Revocation Transparency?) will in the future not require upgrading > servers > > again. > > But this isn't an inherent virtue of 5878, it's due to the CT team > adding functionality to OpenSSL and Apache that allows specifying > server responses in a data file [3]. The server can parse the data > file and return whichever responses the client asks for, without > needing code changes to know their meaning. > > That's a great mechanism, but why not apply it to TLS Extensions? > Then we could deploy CT's timestamps (or other server auth data) > without needing server code changes *or* 5878. > > That would be the best of both worlds, wouldn't it? > I'm not sure I follow; do you mean specifying TLS extension data in a data file? Surely that doesn't work for arbitrary extensions... Emilia > > Trevor > > > [1] http://tools.ietf.org/html/draft-perrin-tls-tack > > [2] For OpenSSL, see ssl_rsa.c:authz_validate(), and incorrect comment > in ssl_locl.h: > > /* authz/authz_length contain authz data for this certificate. The > data > * is in wire format, specifically it's a series of records like: > * uint8_t authz_type; // (RFC 5878, AuthzDataFormat) > * uint16_t length; > * uint8_t data[length]; */ > > [3] OpenSSL's SSL_CTX_use_authz_file(), Apache's SSLRSAAuthzFile directive > --bcaec53d5aa3c9c1ff04d41fca70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jan 25, 2013 at 1:26 AM, Trevor Perrin &l= t;trevp@trevp.net&= gt; wrote:
On Thu, Jan 24, 2013 at 4:10 AM, Emilia Kasp= er <ekasper@goog= le.com> wrote:
> On Wed, Jan 23, 2013 at 8:25 PM, Trevor Perrin <trevp@trevp.net> wrote:
>>
>> Defining your own TLS Extension seems simpler, why not do it from = the
>> start?


To expand on this: =A0RFC 5878 seems unnecessary for server-provided
data such as CT's SignedCertificateTimestamps (or similar things like TACK [1]).

TLS already has an extension mechanism. =A05878 uses this extension
mechanism to add a new extension mechanism. =A0But the new mechanism
seems pointlessly redundant, complex, and not widely implemented.
It's also poorly designed and specified:

=A0* 5878 builds on the SupplementalData TLS handshake message defined
in 4680. =A0But 5878's extension of 4680 appears wrong: =A0The
"SupplementalData" structure in 5878 does not match the same-name= d
structure in 4680. =A0I think 5878 is trying to extend 4680's
SupplementalDataEntry, but it's still wrong (missing
supp_data_length).

=A0* 5878's AuthorizationDataEntry has no overall length field, thus is=
not generically parseable (it can only be handled by a parser which
knows the structure corresponding to each authz_format it encounters).
=A0The OpenSSL implementation [2] attempts to parse it by assuming every AuthorizationDataEntry contains a 2-byte overall length field
following the 1-byte type, but this is incorrect (see URLandHash in
5878).

Thanks, you're correct= - we didn't get it quite right on first attempt. We'll look into i= t.
=A0

The claim is:

> We've already implemented 5878 for OpenSSL and Apache. The wider b= enefit of
> a more general mechanism is that adding new types of authorization dat= a
> (Revocation Transparency?) will in the future not require upgrading se= rvers
> again.

But this isn't an inherent virtue of 5878, it's due to the CT team<= br> adding functionality to OpenSSL and Apache that allows specifying
server responses in a data file [3]. =A0The server can parse the data
file and return whichever responses the client asks for, without
needing code changes to know their meaning.

That's a great mechanism, but why not apply it to TLS Extensions?
Then we could deploy CT's timestamps (or other server auth data)
without needing server code changes *or* 5878.

That would be the best of both worlds, wouldn't it?

I'm not sure I follow; do you mean specifying TL= S extension data in a data file? Surely that doesn't work for arbitrary= extensions...

Emilia



Trevor


[1] http://tools.ietf.org/html/draft-perrin-tls-tack

[2] For OpenSSL, see ssl_rsa.c:authz_validate(), and incorrect comment
in ssl_locl.h:

=A0 =A0 =A0 =A0 /* authz/authz_length contain authz data for this certifica= te. The data
=A0 =A0 =A0 =A0 =A0* is in wire format, specifically it's a series of r= ecords like:
=A0 =A0 =A0 =A0 =A0* =A0 uint8_t authz_type; =A0// (RFC 5878, AuthzDataForm= at)
=A0 =A0 =A0 =A0 =A0* =A0 uint16_t length;
=A0 =A0 =A0 =A0 =A0* =A0 uint8_t data[length]; */

[3] OpenSSL's SSL_CTX_use_authz_file(), Apache's SSLRSAAuthzFile di= rective

--bcaec53d5aa3c9c1ff04d41fca70-- From trevp@trevp.net Fri Jan 25 09:32:41 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807B921F8521 for ; Fri, 25 Jan 2013 09:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHDc6ftwxwOs for ; Fri, 25 Jan 2013 09:32:40 -0800 (PST) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9579021F8778 for ; Fri, 25 Jan 2013 09:32:40 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id dr13so375866wgb.2 for ; Fri, 25 Jan 2013 09:32:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ofNHKwgNzZg1XjxQYrwyKDLm4SkReRBXuavgZUoxBgc=; b=FmPk1qj+uE3IZLKc3Tcw/scZ7mexVqIL+mwIP4jZ/ssZFYBqfUqd4xUhCGmCuXoBVt 4q71yU4fffNnUUTe0Kd6bGgTGunOZpHCfdwQtHxnUO0M919Q1kLbKOb1adJCG3xUUPxf bkOY4vAbfge6wRpxnbg1FbwZkmD48yxfeecMnmL1f3SfOHeOS8M8ebYdmDmQ06Nu+Fa3 Gmrw7wo5tMjee1Q51EXiDeQqRjSJuW8u4SyrzOtWfKuHnRxxLdDm7B2T3BjkNlBK23/k AeqrWZihogfJYzDjk3fhfzurD2mOt0bdbIUsnSZkRYfxFtdk2bz/9MF3o1SV5J7xk9cw mFUQ== MIME-Version: 1.0 X-Received: by 10.180.90.106 with SMTP id bv10mr9941879wib.12.1359135153434; Fri, 25 Jan 2013 09:32:33 -0800 (PST) Received: by 10.216.242.141 with HTTP; Fri, 25 Jan 2013 09:32:33 -0800 (PST) X-Originating-IP: [166.137.212.37] In-Reply-To: References: Date: Fri, 25 Jan 2013 09:32:33 -0800 Message-ID: From: Trevor Perrin To: Emilia Kasper Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmq72MN/kVdmJ1yWH6iD5jAqkLrj4g/RDmeuVCstw+RdOP1MtV2re13/hQI8kyBXuX7adjx Cc: "therightkey@ietf.org" , Ben Laurie Subject: Re: [therightkey] CT and RFC 5878 (was Re: CT Qs) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 17:32:41 -0000 On Fri, Jan 25, 2013 at 8:55 AM, Emilia Kasper wrote: >> > We've already implemented 5878 for OpenSSL and Apache. The wider benefit >> > of >> > a more general mechanism is that adding new types of authorization data >> > (Revocation Transparency?) will in the future not require upgrading >> > servers >> > again. >> >> But this isn't an inherent virtue of 5878, it's due to the CT team >> adding functionality to OpenSSL and Apache that allows specifying >> server responses in a data file [3]. The server can parse the data >> file and return whichever responses the client asks for, without >> needing code changes to know their meaning. >> >> That's a great mechanism, but why not apply it to TLS Extensions? >> Then we could deploy CT's timestamps (or other server auth data) >> without needing server code changes *or* 5878. >> >> That would be the best of both worlds, wouldn't it? > > > I'm not sure I follow; do you mean specifying TLS extension data in a data > file? Yes, I think you could do something much like the authorization data file, except that the file would be a list of TLS Extension responses instead of 5878 responses. For any ClientHello extensions the server receives that have empty extension_data, the server would look through this extension file and add corresponding responses to its ServerHello. > Surely that doesn't work for arbitrary extensions... No, but it would work for simple TLS Extensions that are just stapling some data into the handshake. So, it would support things like CT's SignedCertificateTimestamps, TACK, or other things (you mentioned a "Revocation Transparency"; some sort of DNSSEC/DANE stapling; etc.) Anyways, I think this would be a fantastically useful mechanism that would ease the common burden of these various stapling proposals in a simple, clean way. If you're interested, I'd love to help with the implementation... Trevor From ekasper@google.com Fri Jan 25 10:02:18 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68CA21F8795 for ; Fri, 25 Jan 2013 10:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.75 X-Spam-Level: X-Spam-Status: No, score=-101.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdsCx0q+gZCB for ; Fri, 25 Jan 2013 10:02:17 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D288C21F873E for ; Fri, 25 Jan 2013 10:02:12 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq7so1685123wib.3 for ; Fri, 25 Jan 2013 10:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=so8q9W2L+hk7LyuoXsQM2eJd7P+AFciTL+Lz247/C8o=; b=a8KKuPSR3BwCHgqkGqL/C8s3IRcW37Jmklf7KeHOwaVZSxLfg1qW30NkAgfrG21cqO 8FtzR9nS77SFnpccV6lamTdPPFKUAYlOn5DMdvALRK1NnjsduDuKKTkwCMn8KAcGMBVg C1YV0hYuudTxKftjGaJJwJ8Md8jLRl+gsrnJQMXA6+lgjBqpa9CGj5L4kaxjOvEquHlN DKiJ1ZV8OisVpYhF+Iu0/OsXo6kpi6pPPRkEgJIyV0UMp+KbdR6gtWrZL+pqTTasL5cE CNYxvL3FpdVyeQE3DlPumadDHgQX//gzqVKyO9WMosN4ma/UXxBdIJ5zPv9D9yeNOCv7 TzFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=so8q9W2L+hk7LyuoXsQM2eJd7P+AFciTL+Lz247/C8o=; b=ZrLX0FsdoIFwTjD8oxNb0eNwc8s0VFUHt4yhf+d5Hb96wXT1Oh/VnG/h76v373J/m2 bEgofHG1s4syVv966Zu7GIUauzwxv8I5nS2MKQZkR8oafxkGVtQp32sUMIu4oAzE7X9/ Hzd2EGjixmngadbTLFTnbuENNQ9KtuXAgSmovwVuXWv7FCexYHGefQke/llw6avD5CNM 6WvtMvWYaPMQWqTo9mwQDuYXnB2gaOwrawYwHLBxSsbZDw07DWUU+j4eeK1hOIQgdgxF KsMopeYHgQ+xaAOdIJTJfNJjJ3/pT6HeVRQFUBfwt/O0eXbl6tiOu0xa4yfpPjJdLHb6 yTAw== MIME-Version: 1.0 X-Received: by 10.194.87.200 with SMTP id ba8mr10381816wjb.22.1359136931877; Fri, 25 Jan 2013 10:02:11 -0800 (PST) Received: by 10.194.51.231 with HTTP; Fri, 25 Jan 2013 10:02:11 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Jan 2013 19:02:11 +0100 Message-ID: From: Emilia Kasper To: Trevor Perrin Content-Type: multipart/alternative; boundary=089e010d8afe06952f04d420ba54 X-Gm-Message-State: ALoCoQnB1rbFQJDTvUdRd8H7UMJqCIuldaf+NJTbpXBtsGPiqfq4qIkL4ZOlAANn6nkg1u+QEuz0YaEGWfa3VLpbDFOWz3Ekjevpf0Mj5TzuY6lr0aECvEoV0Auk8utKQPPINUVGQGfIj3Oy/lvU9Tykf+o53c0cPz4+TWbGc7JZKb4idVn0AVvfuSvC42OyFeJM+uo/NQtJ Cc: "therightkey@ietf.org" , Ben Laurie Subject: Re: [therightkey] CT Qs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 18:02:18 -0000 --089e010d8afe06952f04d420ba54 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 24, 2013 at 10:18 PM, Trevor Perrin wrote: > Hi Emilia, > > I'll comment on 5878 separately, to your other points: > > On Thu, Jan 24, 2013 at 4:10 AM, Emilia Kasper wrote: > >> > >> >> - Related to previous: why is it necessary for SCTs and > >> >> MerkleTreeLeafs to have different cases for precerts and certs? > Could > >> >> the signature be calculated on a "normalized" form of the > >> >> TBSCertificate which is the same for certs and precerts (i.e. the > >> >> TBSCertificate with poison and SCT extensions removed?) > >> > > >> > We did consider that, but it is not what the code does currently. > >> > There's no particular reason it could not be done that way, as far as > >> > I currently know. > >> > >> It would seem simpler, since clients would not need separate code > >> paths for precerts and "fully-logged" certs. Also, this would > >> simplify the data structures since you could eliminate the > >> "entry_type" from the LogEntry, SCT, and MerkleTreeLeaf. > > > > > > Not strongly opposed to it, though it would leverage the re-signing > attack > > you describe below to existing certificates, too. > > I guess, though a rogue CA #2 could submit precerts for existing > certs, thus exposing them to this attack from other rogue CAs... even > more far-fetched, I admit, but I tentatively think there should be a > better solution to that attack in general, as opposed to just partly > limiting who is exposed to it. > > > >> Related comment: There should probably be Security Considerations > >> about logging TBSCertificates, since I think there are some subtle > >> issues that arise from logging TBSCertificates if you're using > >> revocation systems based on the full certificate (like OCSP, CRLsets, > >> etc.). > >> > >> For example, a rogue CA could potentially issue a rogue sub CA with > >> the same name as some existing CA, and this rogue sub CA could issue > >> rogue certs with TBSCertificates that match existing certificates. If > >> such a rogue certificate was issued that matched a revoked cert for > >> which an attacker had compromised the private key, the rogue cert > >> could be used with the revoked cert's SCT, but might not itself be > >> revoked (since revocation methods like OCSP and CRLsets scope > >> revocations to the issuer's key hash). > >> > >> So, revocation systems would need to be cognizant of this risk and > >> revoke the TBSCertificate, it seems? > > > > > > A little far-fetched as an attack - but yes. CAs can include an Authority > > KeyID extension in new (TBS)Certificates logged by CT, to protect against > > this. > > I think the Authority Key Identifier is matched against whatever > Subject Key Identifier is declared in the issuing CA cert. So, I > *think* it can be chosen by an attacker to match a target > TBSCertificate, and doesn't help here? > > Right... > Maybe there should be some other X.509v3 critical extension, allowing > the TBSCertificate to contain a reference to the issuer's public key? > That might be easier than modifying revocation systems? > What we could do, I think, is stick the TBSCertificate issuer's public key under the SCT signature. Keep in mind the goal, for us, is to bind the TBSCertificate that appears in the log to the certificate the TLS client sees. > > > >> It's more efficient if the browser could fetch an audit proof without > >> also needing an SCT, and it would be simpler if Merkle Tree Leaves > >> were just defined like: > >> > >> struct { > >> Version version; > >> opaque tbscertificate<1...65535>; > >> } > >> } MerkleTreeLeaf; > >> > >> I guess these aren't the strongest arguments, but I don't see that > >> this simplication loses anything important. > > > > > > We don't know what the CT extensions will be yet but I imagine we'll > want to > > have them included in the tree, so that monitors can examine them. > > > > Also, the SCT timestamps serve as a hint for the location of the entry in > > the tree - makes it easier to design efficient privacy-friendly client > > protocols (briefly mentioned in Sect. 7.3 of the current draft version). > > Hmm. You could always define a new leaf type if you need > extensibility, The extensions, as we proposed them, are meant to maintain backwards compatibility with old TLS-CT clients. > and having clients lookup entries based on time ranges > (or leaf_index ranges) doesn't seem to require actually hashing the > SCT's timestamp into the leaf. > So I'm not convinced you're gaining anything worth the loss in > simplicity and flexibility of a simpler leaf based directly on > certificates. > But it's a design decision, there's arguments both ways... > Sure. Cheers, Emilia > > > Trevor > --089e010d8afe06952f04d420ba54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jan 24, 2013 at 10:18 PM, Trevor Perrin &= lt;trevp@trevp.net= > wrote:
Hi Emilia,

I'll comment on 5878 separately, to your other points:

On Thu, Jan 24, 2013 at 4:10 AM, Emilia Kasper <ekasper@google.com> wrote:
>>
>> >> =A0- Related to previous: why is it necessary for SCTs an= d
>> >> MerkleTreeLeafs to have different cases for precerts and = certs? =A0Could
>> >> the signature be calculated on a "normalized" f= orm of the
>> >> TBSCertificate which is the same for certs and precerts (= i.e. the
>> >> TBSCertificate with poison and SCT extensions removed?) >> >
>> > We did consider that, but it is not what the code does curren= tly.
>> > There's no particular reason it could not be done that wa= y, as far as
>> > I currently know.
>>
>> It would seem simpler, since clients would not need separate code<= br> >> paths for precerts and "fully-logged" certs. =A0Also, th= is would
>> simplify the data structures since you could eliminate the
>> "entry_type" from the LogEntry, SCT, and MerkleTreeLeaf.=
>
>
> Not strongly opposed to it, though it would leverage the re-signing at= tack
> you describe below to existing certificates, too.

I guess, though a rogue CA #2 could submit precerts for existing
certs, thus exposing them to this attack from other rogue CAs... even
more far-fetched, I admit, but I tentatively think there should be a
better solution to that attack in general, as opposed to just partly
limiting who is exposed to it.


>> Related comment: There should probably be Security Considerations<= br> >> about logging TBSCertificates, since I think there are some subtle=
>> issues that arise from logging TBSCertificates if you're using=
>> revocation systems based on the full certificate (like OCSP, CRLse= ts,
>> etc.).
>>
>> For example, a rogue CA could potentially issue a rogue sub CA wit= h
>> the same name as some existing CA, and this rogue sub CA could iss= ue
>> rogue certs with TBSCertificates that match existing certificates.= =A0If
>> such a rogue certificate was issued that matched a revoked cert fo= r
>> which an attacker had compromised the private key, the rogue cert<= br> >> could be used with the revoked cert's SCT, but might not itsel= f be
>> revoked (since revocation methods like OCSP and CRLsets scope
>> revocations to the issuer's key hash).
>>
>> So, revocation systems would need to be cognizant of this risk and=
>> revoke the TBSCertificate, it seems?
>
>
> A little far-fetched as an attack - but yes. CAs can include an Author= ity
> KeyID extension in new (TBS)Certificates logged by CT, to protect agai= nst
> this.

I think the Authority Key Identifier is matched against whatever
Subject Key Identifier is declared in the issuing CA cert. =A0So, I
*think* it can be chosen by an attacker to match a target
TBSCertificate, and doesn't help here?


Right...
=A0
Maybe there should be some other X.509v3 critical extension, allowing
the TBSCertificate to contain a reference to the issuer's public key? That might be easier than modifying revocation systems?

What we could do, I think, is stick the TBSCertificate iss= uer's public key under the SCT signature. Keep in mind the goal, for us= , is to bind the TBSCertificate that appears in the log to the certificate = the TLS client sees.
=A0


>> It's more efficient if the browser could fetch an audit proof = without
>> also needing an SCT, and it would be simpler if Merkle Tree Leaves=
>> were just defined like:
>>
>> =A0 =A0 =A0 =A0struct {
>> =A0 =A0 =A0 =A0 =A0 =A0Version version;
>> =A0 =A0 =A0 =A0 =A0 =A0opaque tbscertificate<1...65535>;
>> =A0 =A0 =A0 =A0 =A0 =A0}
>> =A0 =A0 =A0 =A0} MerkleTreeLeaf;
>>
>> I guess these aren't the strongest arguments, but I don't = see that
>> this simplication loses anything important.
>
>
> We don't know what the CT extensions will be yet but I imagine we&= #39;ll want to
> have them included in the tree, so that monitors can examine them.
>
> Also, the SCT timestamps serve as a hint for the location of the entry= in
> the tree - makes it easier to design efficient privacy-friendly client=
> protocols (briefly mentioned in Sect. 7.3 of the current draft version= ).

Hmm. =A0You could always define a new leaf type if you need
extensibility,

The extensions, as we propos= ed them, are meant to maintain backwards compatibility with old TLS-CT clie= nts.
=A0
and having clients lookup entries based on time ranges
(or leaf_index ranges) doesn't seem to require actually hashing the
SCT's timestamp into the leaf.

So I'm not convinced you're gaining anything worth the loss in
simplicity and flexibility of a simpler leaf based directly on
certificates.

But it's a design decision, there's arguments both ways...

Sure.

Cheers,
Emilia


Trevor

--089e010d8afe06952f04d420ba54-- From trevp@trevp.net Sat Jan 26 08:53:03 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A05521F888B for ; Sat, 26 Jan 2013 08:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-1.262, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8iGYNkGwFYX for ; Sat, 26 Jan 2013 08:53:02 -0800 (PST) Received: from mail-we0-x230.google.com (we-in-x0230.1e100.net [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0A521F87E0 for ; Sat, 26 Jan 2013 08:53:01 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id s43so712856wey.35 for ; Sat, 26 Jan 2013 08:53:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Nfy4iItexFKK8n4EP1miYOwxXWErSoNccd5/n6XCC78=; b=TKZ5yR//pEdDERh94F34j4Kito956cJGjTyXjFMcziHrRySDKePoK8oMPFLsBW7N78 xAh2vLemN3ZboM1SIJ3rdqMzTW4a68RkWJYC0BaoQ/fPumWmrO0OmSsUBM3NIqe1S/mG PTqsAisWGmh4CJVLqaYG3BScjSfGaYSRE0oFRVfomyc/HWeOnqb7vAoFx4q4EDV55y9J yOO/CNDFr1Q1InUiJPLDfOTfG3DzgbVyW7H20RlTmSfGJCn4a1rhUT3IYhuhepGUdeZE kjbzAJDCoRbqCUuqrNzqjE2L//PQJVKdc53dwZpVL3omGifR6pvDKKK+fZ9AG9lkLk+c TfYg== MIME-Version: 1.0 X-Received: by 10.180.99.72 with SMTP id eo8mr2671740wib.34.1359219180973; Sat, 26 Jan 2013 08:53:00 -0800 (PST) Received: by 10.216.242.141 with HTTP; Sat, 26 Jan 2013 08:53:00 -0800 (PST) X-Originating-IP: [166.137.212.37] In-Reply-To: References: Date: Sat, 26 Jan 2013 08:53:00 -0800 Message-ID: From: Trevor Perrin To: Emilia Kasper Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlW6gqp2mnEYJrs9VBC4VHjQGx8+y85jhhnXms2Am4b+5XGe4WSROx3kO13CSlgQ9xpG8c3 Cc: "therightkey@ietf.org" , Ben Laurie Subject: Re: [therightkey] CT Qs X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 16:53:03 -0000 On Fri, Jan 25, 2013 at 10:02 AM, Emilia Kasper wrote: > > On Thu, Jan 24, 2013 at 10:18 PM, Trevor Perrin wrote: >> >> Maybe there should be some other X.509v3 critical extension, allowing >> the TBSCertificate to contain a reference to the issuer's public key? >> That might be easier than modifying revocation systems? > > What we could do, I think, is stick the TBSCertificate issuer's public key > under the SCT signature. Keep in mind the goal, for us, is to bind the > TBSCertificate that appears in the log to the certificate the TLS client > sees. I'd put it a bit differently: an end-entity cert or TBSCert is not a fully self-contained object, it depends on some context from its cert chain. So in addition to binding the end-entity cert or TBScert into the SCT and MerkleTreeLeaf, you may need to bind some of this context, to ensure that log monitors and TLS clients are seeing the same things. Issuer public keys are an important piece of context, because in some revocation protocols, like OCSP, they determine who can revoke the cert. So I think the TBSCert vs. full cert distinction is a bit of a red herring. Even if you bind a full cert, I think you still want to bind its issuer public key. Otherwise you're relying on the cert's signature to bind the issuer public key, which seems like an unusual, possibly unsafe use of crypto (though correct me if I'm wrong!) Anyways, is there other context from the cert chain that needs binding? What about: - Issuer keys or names from other certs in the chain? - The end-entity cert's signatureAlgorithm? - Name constraints? - Certificate policies? - Anything else? Trevor From benl@google.com Mon Jan 28 03:48:42 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDCD21F8865 for ; Mon, 28 Jan 2013 03:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.774 X-Spam-Level: X-Spam-Status: No, score=-102.774 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lgexIV46tqd for ; Mon, 28 Jan 2013 03:48:42 -0800 (PST) Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by ietfa.amsl.com (Postfix) with ESMTP id 802F221F881E for ; Mon, 28 Jan 2013 03:48:41 -0800 (PST) Received: by mail-bk0-f43.google.com with SMTP id jm19so776046bkc.16 for ; Mon, 28 Jan 2013 03:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=70DbQ3OA4E+UhSxHXFKvGu3iJhSXVNp5mnujsr4+e10=; b=GVoeiRV9Gga9RQxdLHkfg6X6sNecfF+EkY2B6ezRbi58x3hqQlfh53l9GfkLlh2wPm YXtdTogC4KnVzSyQKohycBOhfNtZhnJOJ1Bn3sPcnvvyzOmURPSLtouS6jNpY1yEX4RQ ur1r0H/ptZLZLjqe4hreEr+HTuDEKaK5J4DgKADkgfhwL5PYx5PK32iUBla1iZuUqO5N lNXB8SCTJmoqHxd3saKu5KU7UZsb2qDJJH4rBUPUWLW7PCB50YOMWL8M06bRIcEIeysK J3yNXk1joMtBTScGJQMZSaAPppBfqoIoKRmXT5X1bvHTFbqb7z9ySTcp6QKn5JWm/5B+ 6DAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=70DbQ3OA4E+UhSxHXFKvGu3iJhSXVNp5mnujsr4+e10=; b=KmTcM0zYr+wQIaV4wQVds3wMwjXqvkmv/X560AHsLczMlbDkTNKlwk+xTBaTLjn8Bn N76ubM1snU6wbhIOhH+AFph/YwAxM9ShExD2Atws1jrMyVtbvUW3CTXkyK/tHIN1urpV uYskmq7S290ERHRLovv/uvaYhsbO0bI6eyYlOpzTjNNRJZ2EOHLCfPow7a9fe8NtrzCi y+0Mp6NiP1oDdUVKivEWbk5x0erXt9WHJOjUualH7FRrPcMg//4iNhhQ8lo/AA4gVctw 9ywFA1ollGpNL5HC4fdYfMgtfGLctI/tf4B0MDVdWDSlwZZm4uVFcK9aWW1crTQlkP0X mfhg== MIME-Version: 1.0 X-Received: by 10.204.147.18 with SMTP id j18mr3878877bkv.79.1359373720433; Mon, 28 Jan 2013 03:48:40 -0800 (PST) Received: by 10.204.38.198 with HTTP; Mon, 28 Jan 2013 03:48:40 -0800 (PST) In-Reply-To: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> References: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> Date: Mon, 28 Jan 2013 11:48:40 +0000 Message-ID: From: Ben Laurie To: Jeffrey Hutzelman , "therightkey@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmtUcdVDiiTaKXDna/J2ha2DDtyS1isoV8osFk2xBiDq7Q6zxXJexAshbwn/om2XiWnCuwXSyTWHLGiFHxI1VddwYcWezR/Flq3Cv8sEGpkvhMKam8hjsy/EWeQFN5QSxbU1Tj/6IMCjYrUX7lEupKQ70gYMnxXoDrt6G9EZ3Jya2DkKAzPt4Vg3mozNqlW0fkoQMpP Cc: The IESG , draft-laurie-pki-sunlight.all@tools.ietf.org, secdir@ietf.org Subject: Re: [therightkey] dir review of draft-laurie-pki-sunlight-05 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 11:48:42 -0000 On 24 January 2013 19:06, Jeffrey Hutzelman wrote: > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > > This document describes an experimental protocol for publicly logging > the existence of certificates as they are issued or observed, in a manner > that allows anyone to audit certificate authority activity and notice the > issuance of suspect certificates, as well as to audit the logs themselves. > The intent is that eventually clients would refuse to honor certificates > which do not appear in a log, effectively forcing CAs to add all issued > certificates to the logs. > > Overall, the approach used here looks reasonable. However, I have a few > specific comments, and also recommend that the security area directors pay > special attention to this document, as it has the potential to have > far-reaching effects if the experiment is successful. > > > > The abstract for this document is four paragraphs and takes up an entire > page. It could be a lot shorter. For example, I think my one-paragraph > summary above is sufficient to fill the role of an abstract, which is to > allow the reader to find out what a document is about and decide whether > he wants to read it. Fair enough. I have copied your version. Thanks. > This document makes extensive use of RFC2119 requirements language, but > the body of the document does not contain text incorporating the meanings > of these terms. Instead, the usual text is hidden in a "Requirements > Language" section which appears just below the abstract, outside the main > body of the document. This should be moved into the document proper. Moved. > For describing its messages and data structures, this document makes > extensive use of a language which is unfamiliar to me and for which no > reference is given. I can make some guesses as to what it means, but > guesswork does not make for interoperable implementations. Oops. This is the language used by TLS. I will add a reference. > I'm concerned that this document attempts to specify operational policy, > particularly for operators of logs. As the saying goes, "MUST is for > implementors"; statements like "Anyone can submit a certificate to any > log" are inappropriate for protocol specifications. This is not a MUST, however - in any case, we've changed this language in the next version. > In practice, it > seems likely that log operators will establish policies regarding both > who may submit certificates and which certificates they will accept, and > no amount of MUST in a protocol spec is going to change that. > > Similarly, as an anti-spam measure, this document proposes that logs accept > only certificates which chain back to a known CA, and requires that logs > validate each submitted certificate before appending it to the log. This > sounds good, but it's not the only possible mechanism, and so I think MUST > is too strong here. I think you are right, I have changed this to MAY. > Additionally, there is no discussion of the security > implications if a client depends on a log to do this and the log does not > actually do so. Rather than requiring that logs validate every submitted > certificate, the document should only RECOMMEND that they do so, and make > clear that clients MUST NOT depend on such validation having been done. I've mentioned that normal validation should be done by the client. > > From benl@google.com Mon Jan 28 06:31:03 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD3221F8786 for ; Mon, 28 Jan 2013 06:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.864 X-Spam-Level: X-Spam-Status: No, score=-102.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtBAY3oyBBOQ for ; Mon, 28 Jan 2013 06:31:02 -0800 (PST) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id BC9DD21F86DE for ; Mon, 28 Jan 2013 06:31:02 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id c13so1323156vea.5 for ; Mon, 28 Jan 2013 06:31:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8gfAPF9sqJPIAMlTXTgXbYn6E3xyM+LLn1Dz8A8DO6M=; b=gMLw9sPFX3we3n04FhwzM2TRdKoUc4ZicPMMRXK2bHxgfg9IqwjsB/GzsJqKo3Tg17 vig8r54/Kpf8aBefi2jETJGv/mklcYM3USE4+Dtn15PNmS2IzwoD/wKv5W1EipeyJf2P eEAXIGBjLdRVJ4nJhZxcyLn2wr+4pQqhNpJW52EwHp0M3o08oRsaGbU0x541U9PoTRmv 4VeSTOI0vINxDbqkbYwr3d3hoyOiOaVkZcZbpLP2mErdCkXqaZP/i+8Yq+hkPYp4lLSf Z1dsADcOwEN0AT1VENhzrchQ5rJr2oLXZP9UxKENWVwWDd7vGdRpziCaUPvVect8gtFt y+DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=8gfAPF9sqJPIAMlTXTgXbYn6E3xyM+LLn1Dz8A8DO6M=; b=Onv3uBjgnZYd46+DUSDniJfKrcvuwC0E+AaU8/COjHBc9klpD8v9Ii9/S+2H9SSbzI K4+A4wijnAu3EIxvwzEgI5RG5JLsbHuyTXgput5mgqBAKSRVcFsbxN5j3+zFjcBKDw/7 dToS04UVgpDE1/q6eS56cBs/CwKohMEquoTpl0GzL8cJJhqpmmNrUNgfHGIq1Vit2nr8 sum+VC2yoFQeVK9vrbggtsOziW/XVbgpdN8UF9LMHbDfcnTFBQFtw9VdSYHH8mfxXIPQ I2/MM9695i5lDUFOttbg8rFYw0zQMdPBsP8xB6cS+hOj7P9UiJUMGuvtafg8WNmUEiYV rG6A== MIME-Version: 1.0 X-Received: by 10.220.226.70 with SMTP id iv6mr15103397vcb.9.1359383462040; Mon, 28 Jan 2013 06:31:02 -0800 (PST) Received: by 10.220.67.143 with HTTP; Mon, 28 Jan 2013 06:31:01 -0800 (PST) In-Reply-To: <50F4451C.9080209@cs.tcd.ie> References: <20130114170944.18576.71566.idtracker@ietfa.amsl.com> <50F4451C.9080209@cs.tcd.ie> Date: Mon, 28 Jan 2013 14:31:01 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlSBMqpi/2u5htUYEMEhPRS7Q02nF0GO+v9l/peWRUWgCMMCekubHN8ntkBPD/JcnAxUKdkuHrG+Q7vuU8mdJuprR4lVKxumdCgGdM0ECAq418pPFUeco5XS2cfJ+w9xH3xdhj8B9eW9kHUMywKSBxT+/6tROsOXDHreVmjBOmyRrystTD4FKP0BKMd4TxIiL3Q3y/5 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Fwd: updated by Pearl Liang X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 14:31:03 -0000 On 14 January 2013 17:49, Stephen Farrell wrote: > > Hi, > > IANA have a couple of questions [1] as to what they would do if > this becomes and RFC. > > Probably best to figure on this list and make any changes > at the end of IETF LC. I've made the trivial changes requested. > > S > > [1] http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/history/ > > > -------- Original Message -------- > Subject: updated by Pearl Liang > Date: Mon, 14 Jan 2013 09:09:44 -0800 > From: DraftTracker Mail System > To: Stephen Farrell > > > Please DO NOT reply to this email. > > I-D: > ID Tracker URL: http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/ > > A new comment added by Pearl Liang > > > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From Jeff.Hodges@KingsMountain.com Mon Jan 28 14:41:59 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0486321E8034 for ; Mon, 28 Jan 2013 14:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vsp+70wn5h-5 for ; Mon, 28 Jan 2013 14:41:57 -0800 (PST) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 977AD21F8740 for ; Mon, 28 Jan 2013 14:41:57 -0800 (PST) Received: (qmail 15020 invoked by uid 0); 28 Jan 2013 22:41:33 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy12.bluehost.com with SMTP; 28 Jan 2013 22:41:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=qihiElDa5DlHSFzyHAIanPS/t/9q8RVs+EvRYPh0P38=; b=sa9Zi75h1T7Sb4RDON5kQlvM1xm4oamsYHUcx4/9mFCIKnkOaCix3sFtvw2yeizwhVqlBGrdHwp9tYYblAaWA1AIsDe00X3G/uNzMPyP/qDnKhpGZuTH9fmKfMJHCPxY; Received: from [70.199.81.220] (port=63698 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1TzxON-0005Ps-Cx; Mon, 28 Jan 2013 15:41:32 -0700 Message-ID: <5106FE98.2020904@KingsMountain.com> Date: Mon, 28 Jan 2013 14:41:28 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.199.81.220 authed with jeff.hodges+kingsmountain.com} Cc: Emilia Kasper , "therightkey@ietf.org" , IETF Discussion List , Adam Langley Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05 - "acceptable root certificates" ? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 22:41:59 -0000 > Apologies for responding to recent comments in random order: I'm > travelling and have accumulated something of a backlog. no worries :) thx again for your thoughts. BenL replied: > On 22 January 2013 03:11, =JeffH wrote: >>> - is there a >>> standard reference for that? I've refereced HTML 4.01, but perhaps >>> there's a better one? >> >> hm, AFAICT, there is not a standard for URI query component formating and >> thus parameter encoding, so this spec will have to explicitly specify >> something. Section 3.4 of RFC3986 gives allowed chars for the query >> component, but that's about it. >> >> Have you mocked up code that parses the log client messages? If so, what >> query component syntax does it handle? > > I have specified the "standard" format via HTML 4.01. ok, i assume you're referring to section 17.13 "form submission" of HTML 4.01, and using the application/x-www-form-urlencoded content type, with the parameters appended to the url encoded according to S17.13.4 ? > >>>> 3. There appear to be three defined methods for TLS servers to provide >>>> TLS >>>> clients with CT data, in S3.2. For this experiment, which approach is >>>> mandatory to implement for servers and clients? Or, is it the case that >>>> participating TLS clients (ie web browsers etc) implement all three >>>> methods, >>>> and TLS servers can choose any of them? >>> >>> The latter. >> >> That should be made very clear. Is the reason for doing so to obtain >> operational experience wrt the three defined methods such that they perhaps >> can be narrowed down in the future, or is the expectation that TLS-CT >> clients will need to support all three methods in perpetuity? > > I think I made that clear. > > The reason three methods exist are as follows (I don't intend to get > into this in the RFC, but for your edification): > > 1. TLS extension is the right way to do it, but requires a server s/w > change - this adds many years to full deployment. > > 2. So, alternatives must be provided. One is to put the stuff in the > certificate, but... > > 3. ... some CAs have said they'd rather not gate issuance on the log, > so alternatively, wedge the stuff in an OCSP response (which must be > stapled - servers exist that support this option already). ok, thx for elucidation. >>>> 6. Signed tree heads (STHs) are denoted in terms of "tree size" (number >>>> of >>>> entries), but SCTs are denoted in terms of a timestamp. Should there be >>>> a >>>> log client message supporting the return of the nearest STH (and thus >>>> tree >>>> size) to a given timestamp? >>> >>> I'm not sure why? Any STH (that includes that SCT) will do. >> >> Hm, it was sort of a gut feel that it might be useful, but perhaps not. >> >> S5.2. Auditor says.. >> >> A certificate accompanied by an SCT can be verified against any STH >> dated after the SCT timestamp + the Maximum Merge Delay by requesting >> a Merkle Audit Proof using Section 4.5. >> >> S4.5 get-proof-by-hash stipulates tree_size as an input, but >> if a log auditor doesn't already have tree_size, then I suppose it first >> calls S4.3 get-sth, which will return a timestamp and a tree_size, which if >> generated max merge delay (MMD) after the SCT was gen'd, ought to be >> sufficient, yes? > > Yes. > >> I don't see in the spec where/how MMD is published. Does MMD vary per log >> service? The latter isn't stipulated in the spec it seems AFAICT ? > > We have not really figured out how MMD is specified. I suspect it is > something that will be agreed between browser vendors and logs. ok, tho specified in terms of an operational value agreed between browser vendors and logs is different than whatever mechanism a log service uses to "publish" its chosen MMD value, and log monitors/auditors will want to get the MMD value(s), yes? >>>> 7. S3 paragraph 2 states that "TLS clients MUST reject certificates that >>>> do >>>> not have a valid SCT for the end-entity certificate" (i.e., hard-fail). >>>> Presummably this requirement is only for TLS clients participating in the >>>> CT >>>> experiment and that understand this protocol. >>> >>> Of course - what other way could it be? In other words, all RFCs can >>> only say what implementations that conform with them do. >>> >>>> This, or whatever the >>>> requirement actually is, should be further explained. >> >> I guess what I was getting at is that CT-conformant TLS clients should be >> differentiated from non-CT-conformant ones. Stipulating a name for >> CT-conformant TLS clients would clarify this (seems to me), e.g. "TLS-CT >> client" or something similar. > > I understand what you're getting at, but not why. well, its a minor item, but the "why" is that when folks come across this spec (eg in searching for TLS specs), and in discussions in various fora, that there's a name for ct-capable TLS clients, since not all tls clients will be so capable. >> The differences between the spec and [CrosbyWallach] doesn't seem to be that >> large, and so if there aren't more closely matching paper(s) to cite (?), it >> may be worth summarizing the differences between the spec and >> [CrosbyWallach] e.g. in an appendix. >> >> >>> "commitment" is a term of cryptographic art. >> >> so it is, but its definitions in the literature seem to vary somewhat >> depending on context. IIUC, the spec uses "commitment" to refer to the hash >> labels of intermediate nodes ('interior nodes' in [CrosbyWallach]) as well >> as the root hash, yes? >> >> In S2.1.1, where it says.. >> >> We prove that the left subtree entries D[0:k] are consistent >> and add a commitment to D[k:n]: >> >> ..it's not clear just what "add a commitment" means. add it (an >> intermediate-node hash?) to the list of hashes that the recursive algorthm >> is constructing? >> >> Overall, I'm finding S2.1.1 pretty difficult to parse and sort out. >> >> E.g., it isn't clear to me how/why/when the apparently boolean 3d parameter >> of SUBPROOF is either true or false, and whether there's an implied "if b >> then ... else ..." in there somewhere. > > Its reasonably hard to define this thing rigorously, and so I'm not > surprised you find it hard to follow - but as I think I've said > before, we did try various different phrasings and did not find an > easier one. Suggestions welcome. ok. I suppose clarifying the use of the boolean 3d parameter of SUBPROOF is a place to start, tho I'm not sure of its use at this time, so don't feel able to suggest text :( (i haven't grokked the code on this point either..) >> I don't know if it would be better (I've compiled it and am poking through >> the code). I sorta think pseudo code in an appendix that would generate the >> trees in S2.1.3. would be helpful. > > I suspect this is more relevant to a non experimental RFC - I spose. > right now > I have no evidence that anyone is planning to actually write code > other than us - AFAIK, so far everyone who has played with it has used > our code. ok. >>>> Suggested rephrase for this where it occurs throughout section 2.. >>>> >>>> For n > 1, let k be a number which is the largest power of two >>>> such that k = 2^i, 0 <= i < n, and k < n. >>> >>> If we're going to go down that path, then it should say: >>> >>> For n > 1, let k be the largest number such that k = 2^i and k < n. >>> >>> or >>> >>> For n > 1, let k = 2^i s.t. k < n and 2k >= n. >>> >>> surely? >> >> well, yes (i prefer the former), but i think it's also important to >> explicitly state 0 <= i < n > > Why? Its weird! its also not generally true - e.g. n=2 and i=1. ok, what i was getting at is that in the latter statement.. For n > 1, let k = 2^i s.t. k < n and 2k >= n ..shouldn't the range of "i" also be specified? especially that it's lower bound is 0 <= i ? (i haven't stared at math texts for a while and don't recall whether they'd leave "i" only tacitly specified..) For n=2, k=1, i=0 yes? >>>>> MTH(D[n]) = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n])), >>>>> >>>>> where || is concatenation and D[k1:k2] denotes the length (k2 - k1) >>>>> list {d(k1), d(k1+1),..., d(k2-1)}. >>>> >>>> >>>> The above phrase doesn't parse well and is somewhat ambiguous, here it is >>>> extracted for clarity: >>>> >>>> "D[k1:k2] denotes the length (k2 - k1) list {d(k1), d(k1+1),..., >>>> d(k2-1)}" >>>> >>>> >>>> How about rephrasing it along the lines of this: >>>> >>>> D[k1:k2] denotes a sublist {d(k1), d(k1+1),..., d(k2-1)}, having >>>> (k2 - k1) elements, of the original input list D[n]. When (k2 - k1) >>>> is 1, a leaf hash is calculated. >>> >>> We tried lots of different ways of saying this and they were all a >>> little messy. Yours mixes concerns and is rather verbose, so not >>> convinced it is actually an improvement. >> >> well, the way it's presently said in the spec is (to me) pretty darn hard to >> understand. >> >> which concerns are missed in the suggested reformulation? > > I said "mixes" :-) doh :) > That is, it mixes the hashing up with the definition of the list. > Other than that, I'm OK with the rephrasing. oh, well, perhaps just saying.. D[k1:k2] denotes a sublist {d(k1), d(k1+1),..., d(k2-1)}, having (k2 - k1) elements, of the original input list D[n]. ..to supplant.. "D[k1:k2] denotes the length (k2 - k1) list {d(k1), d(k1+1),..., d(k2-1)}" ? and placing "When (k2 - k1) is 1, a leaf hash is calculated." (or something akin) elsewhere appropriate? (sounds like from your various msgs you might have already done the equivalent) HTH, =JeffH From Jeff.Hodges@KingsMountain.com Mon Jan 28 14:55:44 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C82121E803D for ; Mon, 28 Jan 2013 14:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5BPfqk3jCa7 for ; Mon, 28 Jan 2013 14:55:43 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id D29C521E8039 for ; Mon, 28 Jan 2013 14:55:42 -0800 (PST) Received: (qmail 22376 invoked by uid 0); 28 Jan 2013 22:55:08 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy11.bluehost.com with SMTP; 28 Jan 2013 22:55:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=KLWohKHxodUw9UvGXIoN09RVJJX+SNKZVoM8bIN7u0w=; b=tnfiBswo+skm/o3Uff6Bg8dpsKiNBzDrpF/uz2ksWGf50fhlRnA4IlcPDtCcvwS6ZFJFxPd1qnbFKFyC+EdZA5gwWfNwO81yTHjhLNEkqyJjcwZN4HNQVdB+aUsU0ew9; Received: from [70.199.81.220] (port=63696 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1TzxbX-000739-VA; Mon, 28 Jan 2013 15:55:08 -0700 Message-ID: <510701C9.50305@KingsMountain.com> Date: Mon, 28 Jan 2013 14:55:05 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jeffrey Hutzelman , "therightkey@ietf.org" , The IESG , secdir@ietf.org, draft-laurie-pki-sunlight.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.199.81.220 authed with jeff.hodges+kingsmountain.com} Subject: Re: [therightkey] dir review of draft-laurie-pki-sunlight-05 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 22:55:44 -0000 benl replied: > jhutz noted >> I'm concerned that this document attempts to specify operational policy, >> particularly for operators of logs. As the saying goes, "MUST is for >> implementors"; statements like "Anyone can submit a certificate to any >> log" are inappropriate for protocol specifications. > > This is not a MUST, however - in any case, we've changed this language > in the next version. AFAIK, draft-laurie-pki-sunlight isn't strictly a "protocol spec" in that it's documenting protocols, algorithms, and operational aspects of a (grand :) experiment. (and not all RFCs are protocol specs...) HTH, =JeffH From benl@google.com Tue Jan 29 02:52:57 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1800121F8AD4 for ; Tue, 29 Jan 2013 02:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFYPpOVyL6k1 for ; Tue, 29 Jan 2013 02:52:56 -0800 (PST) Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD7421F87FA for ; Tue, 29 Jan 2013 02:52:55 -0800 (PST) Received: by mail-bk0-f43.google.com with SMTP id jm19so162478bkc.16 for ; Tue, 29 Jan 2013 02:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PCRjv7osl+AhzB7sMf3M8nJnsnWQZK5obs57EZA4t2o=; b=JnS4cK5iT/2tJMIsY/gYQFmEpy6WEizaEo2r+XFJPV0F/8k2hkaKaBHAIOOPqdnZre y79Keuhjdf9PdXFGNbKDe9z2+JthXda+pPZqiObwFFjj+UuuVd3LoqNo+9jyOJznenCK nZwcLXDZghEfP4L5zuWKsCgINRyxtQ7G5QiSmHRJUzCvvCbXxdWwTaQY8QSIZtAQJ1jM 5vSzBuVwsGhb8+OylVA0UPCH2hYesQP1rKIPPhFXNipIVM2vNh00sV2fr8pih5noBD8P V1u8A01DkajPZE9+1mpzWB4eSQlVf0bnMdG2Acy5Wko0oGlzbMeixBazp+bn3Ix7O9KV M88Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=PCRjv7osl+AhzB7sMf3M8nJnsnWQZK5obs57EZA4t2o=; b=WZJdPQTW2DMaRw2NaY88BL0FlBFZ+lCMWvCg6WEgYwd4l4zpGw+AiL4GnC5P4XpQS+ YPxypa9NzwUMAOB9Uz6zY4ZmrTwihe7ryaX+APoQUU5HmoAaKmcpohA1lymM1M5VXuo7 r7CDVd4jMhYZdN+TJe6I0H6y396NBeohweudGk8tloJm7Ki0XlofEeaDtSggBafEFrUz P52qPAybLvarZWcYOP6YBvdtSbDukId7rQfxq7WbRyAYp+A1X9Z+2ujJutTTaIAoizHQ xbMcYttC4ukEC4Pkv36aWGrIZelRk4+yBEKD6cst4d5PhNRN2cDwZyIBvxqFflhXEmIk kQGw== MIME-Version: 1.0 X-Received: by 10.204.150.205 with SMTP id z13mr211930bkv.16.1359456774147; Tue, 29 Jan 2013 02:52:54 -0800 (PST) Received: by 10.204.38.198 with HTTP; Tue, 29 Jan 2013 02:52:54 -0800 (PST) In-Reply-To: <50FF084B.5040508@KingsMountain.com> References: <50FF084B.5040508@KingsMountain.com> Date: Tue, 29 Jan 2013 10:52:54 +0000 Message-ID: From: Ben Laurie To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnJcQU8fMSjKLV1yt2kd/LTIDFq2rYHmzTSafa10/MVCkfY2sIeD7Klg6V1pBnj9wiyw8sDnjJhtuFSnGyePkVRQ7qXwfKQ5uWZk/xBXF8RCGLKzEQ4Vqp4eiUnruql5V/9+4wTg/I1McP9wkIRrKD6b7nEi3mcmCwyvdeu6YqCLZsDHI/qTbgfsKneMH+gnBRMhEid Cc: Emilia Kasper , "therightkey@ietf.org" , IETF Discussion List , Adam Langley Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05 - "acceptable root certificates" ? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 10:52:57 -0000 On 22 January 2013 21:44, =JeffH wrote: > > >>>> 3.1. Log Entries >>>> >>>> Anyone can submit a certificate to any log. In order to enable >>>> attribution of each logged certificate to its issuer, the log SHALL >>>> publish a list of acceptable root certificates (this list might >>>> usefully be the union of root certificates trusted by major browser >>>> vendors). Each submitted certificate MUST be accompanied by all >>>> additional certificates required to verify the certificate chain up >>>> to an accepted root certificate. The root certificate itself MAY be >>>> omitted from this list. > > a question I neglected to add here is: how do log services publish their > lists of "acceptable root certificates" ? In the next version there's a URL for it. From benl@google.com Tue Jan 29 03:16:28 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D22D21F882C for ; Tue, 29 Jan 2013 03:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.893 X-Spam-Level: X-Spam-Status: No, score=-102.893 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPb4aHLe8-nQ for ; Tue, 29 Jan 2013 03:16:27 -0800 (PST) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by ietfa.amsl.com (Postfix) with ESMTP id C17C521F881C for ; Tue, 29 Jan 2013 03:16:26 -0800 (PST) Received: by mail-bk0-f52.google.com with SMTP id jk13so178953bkc.11 for ; Tue, 29 Jan 2013 03:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FBMmMuT5YoPz3Y4FucHTJDW3G61Zf2ktoEOUGKBg1Uo=; b=FzOiwhF2nuFly2QEcutbisSRhgqwhqN0ym1lisXrti7dRIAexOoggsKFmwgXMeSBf5 lR7vTu0/adg8ZJSJQcxBNGAZBe4a1iUBAWKIVbPjU9h6GscmOcH5OtlTtoD59iuAFaFr 5iM10eOBMWHdJnnQbk9TiwctkUvmlcsZf+QwkD85ITwxxOIM+oLMoZEojsL5cafbulBN KfnHw7gPfl1aNqSLbhi43EWZvbMLE2UE96ZTWbVEBUfcOxzUeT9sRy3PY1LfRkufjRn8 /BYpG0cagvaNzhq5QALYCh3MMyUPByKsO+Iy6tgJn+NqrlUL94gOsJxj1CGlkS27ZmYa nTzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=FBMmMuT5YoPz3Y4FucHTJDW3G61Zf2ktoEOUGKBg1Uo=; b=OPeVBEKyEJaysTn989Oz9KtaGBUBvkR7edil1QI6CYLp3Pw9zKAFKeXePvwnxWjMQo /9h6+PCPZ+KKQl69KmPUMvH5U4NEwIhPnTh58Xme/IkRzikWoagoQasG9MsMVSIYLXvC /mnYUE4tV4DCaovCvhnK8Bbnrzhw39jyXrFOqxthzAi5BdbznlzfgiAQKnJ5X/8OlyHH 3ma9hJHAUTKwQxjWX9DYicnm3cm/eU/i+MCQ+0p1ATMUuPSuG+I6dBSZbXNpxQ+OEXhv bXh9qmVQMAsk/CC3kglf1/wTzWpybyZe23FwPY9CEAQGEbjDOZUNz1iQrs8cKPReisCa YUBw== MIME-Version: 1.0 X-Received: by 10.204.149.149 with SMTP id t21mr216632bkv.85.1359458185771; Tue, 29 Jan 2013 03:16:25 -0800 (PST) Received: by 10.204.38.198 with HTTP; Tue, 29 Jan 2013 03:16:25 -0800 (PST) In-Reply-To: <5106FE98.2020904@KingsMountain.com> References: <5106FE98.2020904@KingsMountain.com> Date: Tue, 29 Jan 2013 11:16:25 +0000 Message-ID: From: Ben Laurie To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnmarXDXjWmb4hr6knMDin9TofkUSH1EeLkH405URS8p5p0MZB0LSfR7uWAMYFLzxtlow7BDcVE385ZjNIhcUK4B8ycTYYJ9R0lmq/GQzCbXyuUnZItHqXFlxfDA494+iJbIzsDfCRYRQaXHhMTW+ErVOeL6C1sQ227S/268Wr4M4S96LIdFyYnlRHAco0KflIdGNMP Cc: Emilia Kasper , "therightkey@ietf.org" , IETF Discussion List , Adam Langley Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05 - "acceptable root certificates" ? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 11:16:28 -0000 On 28 January 2013 22:41, =JeffH wrote: >> Apologies for responding to recent comments in random order: I'm >> travelling and have accumulated something of a backlog. > > no worries :) > > thx again for your thoughts. > > > BenL replied: >> On 22 January 2013 03:11, =JeffH wrote: > > >>>> - is there a >>>> standard reference for that? I've refereced HTML 4.01, but perhaps >>>> there's a better one? >>> >>> hm, AFAICT, there is not a standard for URI query component formating and >>> thus parameter encoding, so this spec will have to explicitly specify >>> something. Section 3.4 of RFC3986 gives allowed chars for the query >>> component, but that's about it. >>> >>> Have you mocked up code that parses the log client messages? If so, what >>> query component syntax does it handle? >> >> I have specified the "standard" format via HTML 4.01. > > ok, i assume you're referring to section 17.13 "form submission" of HTML > 4.01, and using the application/x-www-form-urlencoded content type, with > the parameters appended to the url encoded according to S17.13.4 ? Yes. >>>>> 6. Signed tree heads (STHs) are denoted in terms of "tree size" (number >>>>> of >>>>> entries), but SCTs are denoted in terms of a timestamp. Should there >>>>> be >>>>> a >>>>> log client message supporting the return of the nearest STH (and thus >>>>> tree >>>>> size) to a given timestamp? >>>> >>>> I'm not sure why? Any STH (that includes that SCT) will do. >>> >>> Hm, it was sort of a gut feel that it might be useful, but perhaps not. >>> >>> S5.2. Auditor says.. >>> >>> A certificate accompanied by an SCT can be verified against any STH >>> dated after the SCT timestamp + the Maximum Merge Delay by requesting >>> a Merkle Audit Proof using Section 4.5. >>> >>> S4.5 get-proof-by-hash stipulates tree_size as an input, but >>> if a log auditor doesn't already have tree_size, then I suppose it first >>> calls S4.3 get-sth, which will return a timestamp and a tree_size, which >>> if >>> generated max merge delay (MMD) after the SCT was gen'd, ought to be >>> sufficient, yes? >> >> Yes. >> >>> I don't see in the spec where/how MMD is published. Does MMD vary per >>> log >>> service? The latter isn't stipulated in the spec it seems AFAICT ? >> >> We have not really figured out how MMD is specified. I suspect it is >> something that will be agreed between browser vendors and logs. > > ok, tho specified in terms of an operational value agreed between browser > vendors and logs is different than whatever mechanism a log service uses to > "publish" its chosen MMD value, and log monitors/auditors will want to get > the MMD value(s), yes? As I said, not clear on that: seems obvious that the MMD can't just be fetched from the log. >>>>> 7. S3 paragraph 2 states that "TLS clients MUST reject certificates >>>>> that >>>>> do >>>>> not have a valid SCT for the end-entity certificate" (i.e., hard-fail). >>>>> Presummably this requirement is only for TLS clients participating in >>>>> the >>>>> CT >>>>> experiment and that understand this protocol. >>>> >>>> Of course - what other way could it be? In other words, all RFCs can >>>> only say what implementations that conform with them do. >>>> >>>>> This, or whatever the >>>>> requirement actually is, should be further explained. >>> >>> I guess what I was getting at is that CT-conformant TLS clients should be >>> differentiated from non-CT-conformant ones. Stipulating a name for >>> CT-conformant TLS clients would clarify this (seems to me), e.g. "TLS-CT >>> client" or something similar. >> >> I understand what you're getting at, but not why. > > well, its a minor item, but the "why" is that when folks come across this > spec (eg in searching for TLS specs), and in discussions in various fora, > that there's a name for ct-capable TLS clients, since not all tls clients > will be so capable. "Conforms to RFC xxxx"? "Is CT capable"? Not sure the RFC is the place to decide what people say! > >>> The differences between the spec and [CrosbyWallach] doesn't seem to be >>> that >>> large, and so if there aren't more closely matching paper(s) to cite (?), >>> it >>> may be worth summarizing the differences between the spec and >>> [CrosbyWallach] e.g. in an appendix. >>> >>> >>>> "commitment" is a term of cryptographic art. >>> >>> so it is, but its definitions in the literature seem to vary somewhat >>> depending on context. IIUC, the spec uses "commitment" to refer to the >>> hash >>> labels of intermediate nodes ('interior nodes' in [CrosbyWallach]) as >>> well >>> as the root hash, yes? >>> >>> In S2.1.1, where it says.. >>> >>> We prove that the left subtree entries D[0:k] are consistent >>> and add a commitment to D[k:n]: >>> >>> ..it's not clear just what "add a commitment" means. add it (an >>> intermediate-node hash?) to the list of hashes that the recursive >>> algorthm >>> is constructing? >>> >>> Overall, I'm finding S2.1.1 pretty difficult to parse and sort out. >>> >>> E.g., it isn't clear to me how/why/when the apparently boolean 3d >>> parameter >>> of SUBPROOF is either true or false, and whether there's an implied "if b >>> then ... else ..." in there somewhere. >> >> Its reasonably hard to define this thing rigorously, and so I'm not >> surprised you find it hard to follow - but as I think I've said >> before, we did try various different phrasings and did not find an >> easier one. Suggestions welcome. > > ok. I suppose clarifying the use of the boolean 3d parameter of SUBPROOF is > a place to start, tho I'm not sure of its use at this time, so don't feel > able to suggest text :( (i haven't grokked the code on this point > either..) I don't get you - the use is defined entirely by the algorithm. It possibly doesn't help that the first step of the algorithm is buried in text instead of having a line to itself, so I've corrected that. > >>>>> Suggested rephrase for this where it occurs throughout section 2.. >>>>> >>>>> For n > 1, let k be a number which is the largest power of two >>>>> such that k = 2^i, 0 <= i < n, and k < n. >>>> >>>> If we're going to go down that path, then it should say: >>>> >>>> For n > 1, let k be the largest number such that k = 2^i and k < n. >>>> >>>> or >>>> >>>> For n > 1, let k = 2^i s.t. k < n and 2k >= n. >>>> >>>> surely? >>> >>> well, yes (i prefer the former), but i think it's also important to >>> explicitly state 0 <= i < n >> >> Why? Its weird! its also not generally true - e.g. n=2 and i=1. > > ok, what i was getting at is that in the latter statement.. > > For n > 1, let k = 2^i s.t. k < n and 2k >= n > > ..shouldn't the range of "i" also be specified? especially that it's lower > bound is 0 <= i ? (i haven't stared at math texts for a while and don't > recall whether they'd leave "i" only tacitly specified..) i is specified entirely by the text (i.e. there is only one i that satisfies 2^i < n and 2^(i+1) >= n, for all n > 1). > For n=2, k=1, i=0 yes? Sorry, yes, you are correct. > > > >>>>>> MTH(D[n]) = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n])), >>>>>> >>>>>> where || is concatenation and D[k1:k2] denotes the length (k2 - k1) >>>>>> list {d(k1), d(k1+1),..., d(k2-1)}. >>>>> >>>>> >>>>> The above phrase doesn't parse well and is somewhat ambiguous, here it >>>>> is >>>>> extracted for clarity: >>>>> >>>>> "D[k1:k2] denotes the length (k2 - k1) list {d(k1), d(k1+1),..., >>>>> d(k2-1)}" >>>>> >>>>> >>>>> How about rephrasing it along the lines of this: >>>>> >>>>> D[k1:k2] denotes a sublist {d(k1), d(k1+1),..., d(k2-1)}, having >>>>> (k2 - k1) elements, of the original input list D[n]. When (k2 - k1) >>>>> is 1, a leaf hash is calculated. >>>> >>>> We tried lots of different ways of saying this and they were all a >>>> little messy. Yours mixes concerns and is rather verbose, so not >>>> convinced it is actually an improvement. >>> >>> well, the way it's presently said in the spec is (to me) pretty darn hard >>> to >>> understand. >>> >>> which concerns are missed in the suggested reformulation? >> >> I said "mixes" :-) > > doh :) > >> That is, it mixes the hashing up with the definition of the list. >> Other than that, I'm OK with the rephrasing. > > oh, well, perhaps just saying.. > > D[k1:k2] denotes a sublist {d(k1), d(k1+1),..., d(k2-1)}, having > (k2 - k1) elements, of the original input list D[n]. > > ..to supplant.. > > "D[k1:k2] denotes the length (k2 - k1) list {d(k1), d(k1+1),..., d(k2-1)}" > > ? I did something like this. > and placing "When (k2 - k1) is 1, a leaf hash is calculated." (or something > akin) elsewhere appropriate? (sounds like from your various msgs you might > have already done the equivalent) Yes. > > > HTH, > > =JeffH > > From stephen.farrell@cs.tcd.ie Tue Jan 29 03:20:51 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E170F21F886D for ; Tue, 29 Jan 2013 03:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy4YZrp25nFO for ; Tue, 29 Jan 2013 03:20:49 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A35E021F884C for ; Tue, 29 Jan 2013 03:20:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9AF0CBE56 for ; Tue, 29 Jan 2013 11:20:27 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyi9Rty45IMN for ; Tue, 29 Jan 2013 11:20:26 +0000 (GMT) Received: from [IPv6:2001:770:10:203:75b2:48e:2a5f:bc82] (unknown [IPv6:2001:770:10:203:75b2:48e:2a5f:bc82]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8F2FBBE33 for ; Tue, 29 Jan 2013 11:20:26 +0000 (GMT) Message-ID: <5107B07B.6020601@cs.tcd.ie> Date: Tue, 29 Jan 2013 11:20:27 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "therightkey@ietf.org" X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [therightkey] relevant NIST workshop X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 11:20:51 -0000 Folks here might be interested in this [1] upcoming NIST workshop. Cheers, S. [1] http://www.nist.gov/itl/csd/ct/ca_workshop.cfm From benl@google.com Tue Jan 29 06:00:47 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF6B21F8884 for ; Tue, 29 Jan 2013 06:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.8 X-Spam-Level: X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTjKjsF8d4VK for ; Tue, 29 Jan 2013 06:00:47 -0800 (PST) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id D520321F886E for ; Tue, 29 Jan 2013 06:00:46 -0800 (PST) Received: by mail-bk0-f42.google.com with SMTP id jk7so282382bkc.1 for ; Tue, 29 Jan 2013 06:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9URiU9+35XW9o6HgB/sgjZMSg6i1YoM9fhfNeb9Vxo8=; b=l+suuwN9n6NWV68leY8NKMJOJTyRNe2rGUF4ja3PVV2kzZ1chRBiHu14OXU+cXeObl oP1ItBJoIons0VSlFbgAGoqe2eOdsL+e4b3XCxeXsUyYFb0pQjdXzCtJ0AfzrG63mef4 BQitLewh7y/9a+IreR9chuUzpc+9HtSRFEswIJ5gPCPigxjZI0q1EUEp59G28j+Z3Bsl uvNPjQtypkU9imsR/broecPLsvFtcZfpZeLUVU6QWQwx/OYGcdNJS7t44L70oZ+mdrnJ 2uKifvLwTPz0wqp5Ll1C/kBdKE+f+5zPwGzV+mfgDZ+ia0bQLvd7TS8rSIsji5S+gvwj xNmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=9URiU9+35XW9o6HgB/sgjZMSg6i1YoM9fhfNeb9Vxo8=; b=plkgzHPZNPhM81toj+xWocXDaKDK+/NlI1I3rJcODwkpXY8273STRREtYcp4SXSDwx gX/AYm2XyCvFQ2zymC7nHrEdFSWRH5pFMh92za1bCr/cnxfgkTHK3AV2Jnk2igoFJ6J+ 6atxcahv7vT4te8DqhBMY8YfHwfmE/ozlTmq+FMg3Zj7ED3FdFCFk7Eyh2dixaieRKnw FBhtP7jUIb21q3suM/XvuQSI9Add2PU5mYCKRz5wP3J9+dlfdluEJU2bi3q8pyY0G9NX Yr/rj4pLOV6mQDmJXlTskI5nM4gqOWRV2OiVRubhYBTv04R2clu7zByyUzbpSJHtK8Sr dYbg== MIME-Version: 1.0 X-Received: by 10.204.131.89 with SMTP id w25mr385191bks.22.1359468045545; Tue, 29 Jan 2013 06:00:45 -0800 (PST) Received: by 10.204.38.198 with HTTP; Tue, 29 Jan 2013 06:00:45 -0800 (PST) In-Reply-To: References: Date: Tue, 29 Jan 2013 14:00:45 +0000 Message-ID: From: Ben Laurie To: Trevor Perrin Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkfPcIMzi3PW+Hr1UEz/EOyRRQtNJHs0LV2E8P7Aq7mZNxLWXTf3y0Y06ekI8cZ2bLfU25j3eewIhnJyUe0eoNzeejpNQZswojvvuH5JSin7mpFtt3/Cso7hq/NQ5SXny9RQLUU+KaSxdZE532Oe6rhyF5b9cbrTBNiTzaheAqkibhHC4jMBJHDmiuoNQ8ie9ckc65y Cc: Emilia Kasper , "therightkey@ietf.org" Subject: Re: [therightkey] CT and RFC 5878 (was Re: CT Qs) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 14:00:47 -0000 On 25 January 2013 17:32, Trevor Perrin wrote: > On Fri, Jan 25, 2013 at 8:55 AM, Emilia Kasper wrote: >>> > We've already implemented 5878 for OpenSSL and Apache. The wider benefit >>> > of >>> > a more general mechanism is that adding new types of authorization data >>> > (Revocation Transparency?) will in the future not require upgrading >>> > servers >>> > again. >>> >>> But this isn't an inherent virtue of 5878, it's due to the CT team >>> adding functionality to OpenSSL and Apache that allows specifying >>> server responses in a data file [3]. The server can parse the data >>> file and return whichever responses the client asks for, without >>> needing code changes to know their meaning. >>> >>> That's a great mechanism, but why not apply it to TLS Extensions? >>> Then we could deploy CT's timestamps (or other server auth data) >>> without needing server code changes *or* 5878. >>> >>> That would be the best of both worlds, wouldn't it? >> >> >> I'm not sure I follow; do you mean specifying TLS extension data in a data >> file? > > Yes, I think you could do something much like the authorization data > file, except that the file would be a list of TLS Extension responses > instead of 5878 responses. > > For any ClientHello extensions the server receives that have empty > extension_data, the server would look through this extension file and > add corresponding responses to its ServerHello. > > >> Surely that doesn't work for arbitrary extensions... > > No, but it would work for simple TLS Extensions that are just stapling > some data into the handshake. So, it would support things like CT's > SignedCertificateTimestamps, TACK, or other things (you mentioned a > "Revocation Transparency"; some sort of DNSSEC/DANE stapling; etc.) > > Anyways, I think this would be a fantastically useful mechanism that > would ease the common burden of these various stapling proposals in a > simple, clean way. If you're interested, I'd love to help with the > implementation... I rather like this idea. Help welcome :-) From Jeff.Hodges@KingsMountain.com Thu Jan 31 08:22:48 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25B821F842A for ; Thu, 31 Jan 2013 08:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.307 X-Spam-Level: X-Spam-Status: No, score=-102.307 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeq0eFn17yWN for ; Thu, 31 Jan 2013 08:22:48 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id D454021F8976 for ; Thu, 31 Jan 2013 08:22:47 -0800 (PST) Received: (qmail 32192 invoked by uid 0); 31 Jan 2013 16:22:23 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 31 Jan 2013 16:22:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=vWvHqgdr45xdB5bS4e9YPO/VvHkPhPC4Ni34grmkkgI=; b=Lszifhkxrvw4v0QaWdOD4NTlLlUJqwd1s852g7jZoaIWjdl8im++50BgQlNCTr3DdhcIvEKYxB8f9feuroHidG2AFhiaSXhV2q9VxyvVER/t3UwPCcl7CmVDOQHEpo+O; Received: from [216.113.168.128] (port=36654 helo=[10.244.136.154]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1U0wu6-0004sr-AX for therightkey@ietf.org; Thu, 31 Jan 2013 09:22:22 -0700 Message-ID: <510A9A3E.8000105@KingsMountain.com> Date: Thu, 31 Jan 2013 08:22:22 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [therightkey] fyi: draft-laurie-pki-sunlight-07.txt X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 16:22:48 -0000 [ -06 preceded this by just a couple hours ] Subject: I-D Action: draft-laurie-pki-sunlight-07.txt From: internet-drafts@ietf.org Date: Tue, 29 Jan 2013 10:41:15 -0800 To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Certificate Transparency Author(s) : Ben Laurie Adam Langley Emilia Kasper Filename : draft-laurie-pki-sunlight-07.txt Pages : 32 Date : 2013-01-29 Abstract: This document describes an experimental protocol for publicly logging the existence of TLS certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority activity and notice the issuance of suspect certificates, as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates which do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services which implement the protocol operations for submissions and queries that are defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-laurie-pki-sunlight There's also a htmlized version available at: http://tools.ietf.org/html/draft-laurie-pki-sunlight-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-laurie-pki-sunlight-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt