From benl@google.com Mon Dec 3 02:53:38 2012 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 91A4D21F869E for ; Mon, 3 Dec 2012 02:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.874 X-Spam-Level: X-Spam-Status: No, score=-100.874 tagged_above=-999 required=5 tests=[AWL=-1.198, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, FRT_LEVITRA=1.812, 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 r0PZyd7nsiTk for ; Mon, 3 Dec 2012 02:53:38 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id DDA7921F867D for ; Mon, 3 Dec 2012 02:53:37 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so1082631wib.13 for ; Mon, 03 Dec 2012 02:53:37 -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:content-transfer-encoding; bh=SurNvkdIZ+c696lk2XPBv6Jmkco2p1514RDlOg2dApw=; b=ar4J6IRDWx4HXOQUU3uA+HO6oMvxyYEyxgmJq8FQEK/db7ouK2sCsFG7bok/TH5f/V 0QqpSvF07j49lXeBsBKiuE/8AQshoMZion0F0FGLuDpW8SIVmrf1OrXhmPhYtKpquzFh RuQ1aCmy05+2ShctFNahxs8P0kmntHTrwfoKh8/q9TwF1fN6tSeqRWsLjhc/3Jo5AXAh Fp0PN8mPtTXdtrie9iUWzDk+qaSAb2ybPvLIi0UGj06ri4W9ZoeViB4W4du/YOqXPjvT 5efR/GfucTsCKeS0sjziqUwDWSrX1C2LUcLXi1+0RTcr/UR8lj3EAHW2av1cMnD0W9VW u/QQ== 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:content-transfer-encoding:x-gm-message-state; bh=SurNvkdIZ+c696lk2XPBv6Jmkco2p1514RDlOg2dApw=; b=P/RSJrEb8r3FBiiaPoyDehIqoKL7dVARJ0DaD0R3M+JplFMimR8f1pMTztD/naodf7 aUdYDm+ZaIf/3twhbUPRBVKVvuwuhHlQfxudhcdwNpQ5tk/kqKSSYJeePZSUaQjtPsMM 3HQpYJ5YbnMQTr3YB/8IwuAP7kVS+TONo+6L2buwm9uQvUzUn330wwt43o8srWyV/KuZ YyCRB2BEDc9Qy91WcVv2g16Ilpf/upmexZ+901md+DcmHPrjr3Hfh/XqnV3N16KXWkop XPGF54WJmPHRT/UEke595yd8jFzTxqoTZQ8EHMmCnd+hoVOgygI3NdhN1bMN+94lJITy o9Rw== MIME-Version: 1.0 Received: by 10.180.103.106 with SMTP id fv10mr8695947wib.19.1354532016876; Mon, 03 Dec 2012 02:53:36 -0800 (PST) Received: by 10.194.51.35 with HTTP; Mon, 3 Dec 2012 02:53:36 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Dec 2012 10:53:36 +0000 Message-ID: From: Ben Laurie To: Paul Lambert Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkKcaeuVBmUUpjw6pW7VsqPK1ha99kylslCoC3f7aPc3JPTkF/FZxczGqoSjWUb7l7cvMzAvHNP7AJYICfsxOEcnxctnQQcaU6DCO7BA1uq5vXMKJOrOF3mIgf8AS03K/yYX3qsPFEzGE9w3ARbfyVLUB/x8NFOwldd4xCBAz06iigo+g5yC3/0QKz/w/jhj3O/wEXb Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Another suggested change 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, 03 Dec 2012 10:53:38 -0000 On 30 November 2012 17:27, Paul Lambert wrote: > > > On 11/30/12 6:17 AM, "Ben Laurie" wrote: > >>On 29 November 2012 15:55, Paul Lambert wrote: >>> >>> >>> >>>>Structure of the Merkle audit proof: >>>> >>>> struct { >>>> opaque sha256_hash[32]; >>>> } MerkleNode; >>>> >>>> struct { >>>> Version version; >>>> LogID id; >>>> uint64 tree_size; >>>> uint64 timestamp; <------------------------------ not >>>>necessary >>>> uint64 leaf_index; >>>> MerkleNode audit_path<0..2^16-1>; >>>> TreeHeadSignature tree_head_signature; <--- contains >>>>timestamp >>>> } MerkleAuditProof; >> >>Not sure why you think the timestamp is not needed? > > There are two timestamps =C5=A0 one in the tree_head_signature and one o= n the > Audit Proof. > The timestamp within tree_head_signature is very useful. > Not sure the intent of the usage and benefit of the additional timestamp > on MerkleAuditProof. > Seems that the timestamp with the tree_head_signature would always be the > definitive creation time. I trust this is explained by Emilia's post? In case it isn't: the TreeHeadSignature is just a signature, the timestamp in the audit proof _is_ the timestamp the THS signs. > However =C5=A0 03 no longer has the MerkelAuditProof structure That's because we now define the log API in terms of JSON. > The SignedCertificateTimestamp is similar and has two timestamps. Clarity > on the need and utilization of two time values would be useful. Same thing. > > > Paul >> >>>> >>>> >>> > From paul@marvell.com Mon Dec 3 12:17:05 2012 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 6B31721F87EB for ; Mon, 3 Dec 2012 12:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.28 X-Spam-Level: X-Spam-Status: No, score=-3.28 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_40=-0.185, FRT_LEVITRA=1.812, RCVD_IN_DNSWL_MED=-4] 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 o9COTdmnONnm for ; Mon, 3 Dec 2012 12:17:04 -0800 (PST) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id BD11621F881D for ; Mon, 3 Dec 2012 12:17:04 -0800 (PST) Received: from SC-OWA01.marvell.com ([199.233.58.136]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUL0IvMAbvr8pbHhDuBhESC5VqUghIEJZ@postini.com; Mon, 03 Dec 2012 12:17:04 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 3 Dec 2012 12:14:56 -0800 From: Paul Lambert To: Ben Laurie Date: Mon, 3 Dec 2012 12:14:57 -0800 Thread-Topic: Another suggested change Thread-Index: Ac3RktzrjepFPIARS6aopcKT/P9xxw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Another suggested change 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, 03 Dec 2012 20:17:05 -0000 Thanks. Makes sense to me now. Appreciate the info. Paul On 12/3/12 2:53 AM, "Ben Laurie" wrote: >On 30 November 2012 17:27, Paul Lambert wrote: >> >> >> On 11/30/12 6:17 AM, "Ben Laurie" wrote: >> >>>On 29 November 2012 15:55, Paul Lambert wrote: >>>> >>>> >>>> >>>>>Structure of the Merkle audit proof: >>>>> >>>>> struct { >>>>> opaque sha256_hash[32]; >>>>> } MerkleNode; >>>>> >>>>> struct { >>>>> Version version; >>>>> LogID id; >>>>> uint64 tree_size; >>>>> uint64 timestamp; <------------------------------ not >>>>>necessary >>>>> uint64 leaf_index; >>>>> MerkleNode audit_path<0..2^16-1>; >>>>> TreeHeadSignature tree_head_signature; <--- contains >>>>>timestamp >>>>> } MerkleAuditProof; >>> >>>Not sure why you think the timestamp is not needed? >> >> There are two timestamps =A9 one in the tree_head_signature and one on >>the >> Audit Proof. >> The timestamp within tree_head_signature is very useful. >> Not sure the intent of the usage and benefit of the additional timestamp >> on MerkleAuditProof. >> Seems that the timestamp with the tree_head_signature would always be >>the >> definitive creation time. > >I trust this is explained by Emilia's post? In case it isn't: the >TreeHeadSignature is just a signature, the timestamp in the audit >proof _is_ the timestamp the THS signs. > >> However =A9 03 no longer has the MerkelAuditProof structure > >That's because we now define the log API in terms of JSON. > >> The SignedCertificateTimestamp is similar and has two timestamps. >>Clarity >> on the need and utilization of two time values would be useful. > >Same thing. > >> >> >> Paul >>> >>>>> >>>>> >>>> >> From stephen.farrell@cs.tcd.ie Sun Dec 16 17:54:26 2012 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 0F64021F858C for ; Sun, 16 Dec 2012 17:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.149 X-Spam-Level: X-Spam-Status: No, score=-101.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MANGLED_LIST=2.3, 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 ir7ER2dURqpd for ; Sun, 16 Dec 2012 17:54:25 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EA5E521F8587 for ; Sun, 16 Dec 2012 17:54:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DAA68BE35; Mon, 17 Dec 2012 01:54:02 +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 dUiWsGzRe0lJ; Mon, 17 Dec 2012 01:54:01 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.44.64.140]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 88F82BE32; Mon, 17 Dec 2012 01:54:01 +0000 (GMT) Message-ID: <50CE7B39.8040703@cs.tcd.ie> Date: Mon, 17 Dec 2012 01:54:01 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie , Adam Langley , Emilia Kasper X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: [therightkey] review of draft-laurie-pki-sunlight-03 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, 17 Dec 2012 01:54:26 -0000 Hiya, I think this is getting very near the point where we can last call it, but isn't quite there yet. My review below. Cheers, S. maybe needs thought, defo needs answering: ------------------------------------------ (1) RFC 5878 has a bunch of IPR declarations [1] attached and is not afaik widely implemented (is it at all?). Is re-use of that really a good plan for something ultimately intended to be used for all web servers if that IPR were problematic? Note: in the IETF we don't judge the terms nor applicability of IPR but we do pay attention to what IETF participants say they think about that. In this case, there's no WG, so I'm asking. (Full disclosure: one of the declarations is a 3rd party one I made. [2]) My take is that this might be problematic, but what do others think? [1] https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=5878 [2] https://datatracker.ietf.org/ipr/808/ (2) abstract: "domain owners or their agents" makes it sound like I might have to pay to monitor; be good to re-assure that no such constraint is planned. (Such re-assurance doesn't need to be in the abstract, arguably not even in the draft, but also arguably ought be somewhere.) While its none of the IETF's business who charges for what in general, in this case, where there has been ongoing negative comment on the impact of PKI business models on Internet security, I do think it'd be good for the authors of proposals to be clear how they think they're affecting such charging issues. Personally, I guess that since EFF and some academics have been able to afford to populate large databases of TLS server certs, this shouldn't become a huge barrier, but it could in principle impose new subscription costs or constraints on TLS servers or even clients and that might not be a good plan. (3) Sometimes you say "the log" and other times "logs" I think the term log needs to be used consistently otherwise we may end up being unclear about cardinalities of things later. Suggest adding a specific definition for this term, or invent a term for all logs everywhere. (4) You say you expect "most" public CAs to take part. I think that's a bad thing to say for an experimental RFC and could cause you problems at IETF LC (say if some CA says "this is BS because we're not taking part"). The experiment in any case doesn't need most CAs, just some useful number and you seem to have that. (5) 2.1, better to say sha-256 is hard-coded for now and that that's ok for an experiment - you may well get comment on that since a standards-track RFC would need alg. agility probably. Do *all* logs have to use sha-256 or is it just that all logs have to use one hash alg? Be good to be clear on that too. (6) The precertificate thing needs some more detail at least, e.g. what's "poision" about? (I assume its to prevent such a "pre-cert" be verified anywhere, but then you could also mess with the dates.) Also, saying the precert-signing-cert has to be signed by "the CA cert" private key isn't quite enough. If you mean the same CA cert that's above the TLS server cert then that might not be possible (e.g. with pathLen) albeit that's unlikely, but there could be other reasons why that CA can't issue a CA cert (which the precert-signing-cert is, right?) (7) 3.1, p10, 2nd para: "...chain...to a trusted root..." does that mean that trusted root has to be the CA that issued the topmost cert in the submission to the log, or is any trusted root accepted by the log ok? ("using" the chain might not be considered normative.) (8) 3.1, says the log can accept "not fully valid" things but also says that a "valid chain" is required. That needs clarification I think, since some would consider that a valid chain cannot contain e.g. an expired end-entity cert. (9) 3.1, " However, the log MUST refuse to publish certificates without a valid chain to a known root CA." seems to preclude any solution for self-signed certs or DNSSEC/DANE. Is that a good plan? Maybe if you make it a positive "must accept" then that'd avoid that problem? (If a good solution for SSCs or DANE spam is figured out later.) (10) 3.1, identifying a log solely on the basis of its key_id without any roll-over seems dumb. What if the log wants to roll its signature key? This would have to be fixed in a standards-track RFC but really could be done now and would be better for having being done. (11) various places: I'm not sure you need extensions in all the places you have 'em - if this does become an experimental RFC followed by a standards-track RFC, then that can be handled then. (12) 4.x - would it make sense to use .well-known/ct/ URLs or not? (13) 4.x - how does CT impact on the TLS server cert used for these HTTPS connections? needs fixing, but no thought: ----------------------------- - abstract: the RFC editor doesn't want references in abstracts, just use the RFC number and then put the [] into the body of the text 1st time you refer to each RFC. That might mean you need to repeat stuff from the abstract. (Apparent reason for RFC editor pref is that sometimes people just see the abstract and couldn't follow the reference, feel free to argue with the RFC editor on this about some other document:-) - Where're the OIDs in 3.1 and 3.2 registered? They should be in the some registry I guess. - 3.1, shameless self-promotion - draft-farrell-decade-ni has a way to hash public keys:-) Yes, filling in the TODO is needed. - STH needs to be expanded on 1st use - section 5, 2nd para: gossip TBD needs to be done - ref [1] results in a 404 random comments: ---------------- - abstract: "public end-entity" might not be the best term, maybe the word "web server" is needed since that's the real (inital) concern? - abstract: "accompanied by" seems wrong, "for which an accompanying" would seem better since that log-sig might be found in or out of band. - abstract: s/will be valid indefinitely/are good or bad forever and have no "expiry"/ ? - intro, para1: s/solve the problem/mitigate the problem/ better not to over-claim - intro, para1: what is an "untrusted log"? - intro, para1: s/added/are added/ - intro, para1: s/public TLS/public TLS server/ or are you adderssing client certs too? I don't care assuming it works but you ought be clear. - intro, para 2: ought "required" be 2119 terminology here? Its ok if it is repeated later, but if its not repeated later then it ought IMO be a 2119 term here. - intro, para 2: I'd avoid the word "prove" since mistakes can be made (e.g. a clock might be off) - intro, last para: I think you need to be clear about trusting the log. Clients do need to trust it to be available at least, and if they process a signature then they need to trust it to sign properly and for whatever signature-validity controls. - 2.1: "MTH({d(0)}) = SHA-256(0 || d(0))." The first input to the hash is ASCII '0' (0x30) or a 1-octet number 0 (0x00) or something else? You need to be clear on all those. Be good to say why you chose a 0 for the first but a 1 for others. - 2.1: would it be worth adding "if n is a power of 2 then k=n/2" ? Someone might miss "smaller than" when coding, though I'm not sure their code could work at all in that case, or could it? - 2.1.4: the NIST reference should be a proper reference - 3, 2nd para: saying clients MUST reject without defining client is odd and esp when doing more than audit with CT is optional. The servers MUST there is also odd. I think you want to say "conforming to this spec" in both cases at minimum. - 3, last para, is the MUST there correct use of 2119 language? Formally its not an interop thing but it is a security thing. While I have no issue with that, some other ADs do (mistakenly IMO, but nonetheless it has to be dealt with;-). Reading and closely following the definitions in 2119 might help with that. If, OTOH you want to argue that that's silly then I'm with you on that. - 3.1, 1st para: a list of roots does not "attribute each logged cert to its issuer" - 3.1, not all roots need to make self-signed certs for their root public keys, even though all probably do. Might be better for the language to recognise that. - 3.1, 1st para, s/shall/SHALL/ and maybe s/should/might usefully/ in the same sentence. - 3.1, what's the use-case for a log accepting a cert that has expired? (just curious) - 3.1, the log doesn't "publish" certs does it? - 3.1, why are log entries called "certificate entries"? - 3.1, why "0..." for X509ChainEntry and "1.." for PrecertChainEntry? You probably ought say and that might need to change if you change the "same CA issued both EE cert and precert-signing-cert" rule. - 3.2, it might be a pain to have the string SignedCertificateTimestampList mean two things i.e. both a type and the name of an OCTET STRING field. - 3.2, p13, 1st para, again you say *the* CA. - 3.4, 64 bits for tree size? seems a lot but ok. Is there any way to use a large size there as a DoS by someone on anyone? I've not thought about it, but has anyone? From benl@google.com Mon Dec 17 08:51:51 2012 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 3B12A21F8B20 for ; Mon, 17 Dec 2012 08:51: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 xcCseAGMQBio for ; Mon, 17 Dec 2012 08:51:50 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BD14221F8B1C for ; Mon, 17 Dec 2012 08:51:49 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so2983088wey.31 for ; Mon, 17 Dec 2012 08:51:48 -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:content-type; bh=BHkxvYacW3GZTAZYG20U+1N7AktSVY73DkMBmC2BJkw=; b=DE7lVgOqNOxMiNIuk9s961AiAqn9rgDDDXWLjVUy/Eu+faGPkAtHKI+SK8mTwALGfq CkAl3GO8pMqZH1Za1jdD+dHQyMGImHqp+HljbFOze7K9CfL5vjRCjAaNUSOEeTEpmR4p 3mneuO83iR5AkO+Ovf+JeJ0ri6Kg376Ysd8z+HsrdJf3dz4LuZdCdsX2DCvrUty3cidq pPFjAq6AKk96+cjlxdkaE1BbUTUY67zZSdhpTohL0FbKonbVba3XOhA95nxsbCmHFW9W TY0gunKTxh69qbLRpKezaYuxuoE8SL0GSOsjPlus9yjZEdXpcCHy6EH21NZJbv397U/X h5/w== 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:content-type :x-gm-message-state; bh=BHkxvYacW3GZTAZYG20U+1N7AktSVY73DkMBmC2BJkw=; b=BuWa3RK6isSbbD5yqHRPbUBRFENfE7IRKtBhJvk1i1zTzvOkgEineeLtVKpcScLDyu d1ts5LVoWXKcKv02SxLPg39aHvfYnOhFT5njKn/BODNLKAD0CiIOBvQ4diW1stojlHsK 6twNjjypvT2T+91FCezAeeY3yn48uTsIKJgfGt+C3mSmeDYgJ0WRca2wO+4meEqngmbe n35Wmbgjih35zf3us5wzpraMYrJPKIrU+I7QrgfbxwjKvIyIt7SOt2LnBAY+4rGXEQgO gTt3hiD2dUS+kmvyLRs/FLRnsWTf63d7XrzVeii5lTng1TY/6t/W+rE7HEwi6zZyen4g aBew== MIME-Version: 1.0 Received: by 10.180.20.176 with SMTP id o16mr16934718wie.10.1355763108801; Mon, 17 Dec 2012 08:51:48 -0800 (PST) Received: by 10.194.51.35 with HTTP; Mon, 17 Dec 2012 08:51:48 -0800 (PST) Date: Mon, 17 Dec 2012 16:51:48 +0000 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn1aOzdHlPZb+417FxF4HCP3EZYt+d4iTj3bWjtYwnPSIAHJKOIiv0Vrq7Z/na4vf7ZE5nZVlrK2PM/BZyeRTU2u1T+tip2inoNX9dx40y2ZPWOtdnUVR2xBZpDMtLo0BCUMEJTo/ZxKT6DP0TIaWXsGio8aiMTFQfbUvD0cm6t0jFTys1t5xZ07UnKWcejDxcqTtzP Subject: [therightkey] Review of draft-laurie-pki-sunlight-03: point 2 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, 17 Dec 2012 16:51:51 -0000 > (2) abstract: "domain owners or their agents" makes it sound > like I might have to pay to monitor; be good to re-assure that > no such constraint is planned. (Such re-assurance doesn't need > to be in the abstract, arguably not even in the draft, but > also arguably ought be somewhere.) While its none of the > IETF's business who charges for what in general, in this case, > where there has been ongoing negative comment on the impact of > PKI business models on Internet security, I do think it'd be > good for the authors of proposals to be clear how they think > they're affecting such charging issues. Personally, I guess > that since EFF and some academics have been able to afford to > populate large databases of TLS server certs, this shouldn't > become a huge barrier, but it could in principle impose new > subscription costs or constraints on TLS servers or even > clients and that might not be a good plan. Well, a log isn't much use unless it is public - but I don't really know how to say much about who charges for what. We can state our intent to run free services, but presumably not in an RFC. So ... I don't really know how to address this. From benl@google.com Mon Dec 17 08:54:01 2012 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 8989921F8509 for ; Mon, 17 Dec 2012 08:54:01 -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 cHcNZ7szXB6S for ; Mon, 17 Dec 2012 08:53:34 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8193321F84D3 for ; Mon, 17 Dec 2012 08:53:34 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so2803913wgb.13 for ; Mon, 17 Dec 2012 08:53:33 -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:content-type; bh=XBLvsPCfGv4sLskaOF/PWyAIYy168WAzSnO4VJC8Yos=; b=pcUcu7NpPkjPgyDl6wsLZHf/+kcuTWf5J09TTnY1x9Qtk48C11VCUm/Q66fc+HT0xU x7vAU/3dEX6MYM0QVNUNR2ftjDrqOaVQIJs/acmV32Ynb3OVfflKp24Um+881f6JxCmC 0Pn+sAnazWeP3SJO36iFw8z1nPE+e9EeX93mmR6FaX2wOXZF5HYV/+Dc/CJUbFyYaAQl r7/rz/uN6Ku6qlnjSXQdIujKmbO6673bCXuUtdQ+CPaMEVsX/6CuZW5Giih0zUlyZOxw aCoP0G06Yvp/pu2kzQllygCLFVTjmpb6I0lPsQWAKlDkXiUFdF/tlDOBiGpyGwfVo9mX iCUA== 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:content-type :x-gm-message-state; bh=XBLvsPCfGv4sLskaOF/PWyAIYy168WAzSnO4VJC8Yos=; b=gW2febcXyfb/Wj2cnsUZgSycUe2C+MCW3xHP5PvTIlsRFy4v4hlOqe9Vmd/35W1kBs jUUmhC5p0LFR8yI9l8CnwFSM/G7LbYbV6d/793Xm9t6QPJMtCn8PXhRNq2qUeu740gTW FHD+XkM6wU5CWOyog3I2vzbwV8dS1WlMxi+iDL04nZ900t1ZCplY30bmuD8eCVHGIdXj Drh/Wu9zuMpTu1QQnc9VT0a/GKqvID7A9u7MplkTpGh15vPRCArOyysZhJ7GiyQuiUtI B9+8s1i58Sq9lwgFT8v3VKmYbhD+kB50zhC5vVXftqQG41qhxMYDadozej8MJ35p64+/ vogA== MIME-Version: 1.0 Received: by 10.180.20.109 with SMTP id m13mr16935951wie.16.1355763213671; Mon, 17 Dec 2012 08:53:33 -0800 (PST) Received: by 10.194.51.35 with HTTP; Mon, 17 Dec 2012 08:53:33 -0800 (PST) Date: Mon, 17 Dec 2012 16:53:33 +0000 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmJHdliX7OGd46UnxhyzjfshL9xg/EtE3pvsqMf/8HYapKABIMhrYdReh5+eBFwv/wk3Km6a+ilQfGEG2mUqDsUlnEI8J9WJe7XIETFPG9hMysffP7WpEJr2LjJRa6G8LGl3KF8j6Tz/5kNfjHoXkL4kNzLhX0tib6Rwlvf2rpIVvRG2iGyIXCpSy5X+NNxjrQpJydp Subject: [therightkey] review of draft-laurie-pki-sunlight-03: point 9 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, 17 Dec 2012 16:54:01 -0000 > (9) 3.1, " However, the log MUST refuse to publish > certificates without a valid chain to a known root CA." seems > to preclude any solution for self-signed certs or DNSSEC/DANE. > Is that a good plan? Maybe if you make it a positive "must > accept" then that'd avoid that problem? (If a good solution > for SSCs or DANE spam is figured out later.) I think this has to exclude SSCs and DANE until we know how to deal with them, because otherwise a colluding CA and log could avoid blame on the CA by logging the end certificate, signed by, say, some one-off intermediate. This means we cannot weaken the MUST and still be able to blame the CA. We could add language to the effect that although this does exclude SSCs and DANE we welcome suggestions to allow their inclusion. From stephen.farrell@cs.tcd.ie Mon Dec 17 09:03:30 2012 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 DD27521F87C5 for ; Mon, 17 Dec 2012 09:03:30 -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 NHCtHyfPYgol for ; Mon, 17 Dec 2012 09:03:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C8A7221F8773 for ; Mon, 17 Dec 2012 09:03:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DDE37BDCA; Mon, 17 Dec 2012 17:03:05 +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 t0Gr76n2atBr; Mon, 17 Dec 2012 17:03:01 +0000 (GMT) Received: from [IPv6:2001:770:10:203:bcf1:96ff:1de8:8ef5] (unknown [IPv6:2001:770:10:203:bcf1:96ff:1de8:8ef5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E8C53BE20; Mon, 17 Dec 2012 17:03:00 +0000 (GMT) Message-ID: <50CF5045.4020909@cs.tcd.ie> Date: Mon, 17 Dec 2012 17:03:01 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] Review of draft-laurie-pki-sunlight-03: point 2 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, 17 Dec 2012 17:03:31 -0000 On 12/17/2012 04:51 PM, Ben Laurie wrote: >> (2) abstract: "domain owners or their agents" makes it sound >> like I might have to pay to monitor; be good to re-assure that >> no such constraint is planned. (Such re-assurance doesn't need >> to be in the abstract, arguably not even in the draft, but >> also arguably ought be somewhere.) While its none of the >> IETF's business who charges for what in general, in this case, >> where there has been ongoing negative comment on the impact of >> PKI business models on Internet security, I do think it'd be >> good for the authors of proposals to be clear how they think >> they're affecting such charging issues. Personally, I guess >> that since EFF and some academics have been able to afford to >> populate large databases of TLS server certs, this shouldn't >> become a huge barrier, but it could in principle impose new >> subscription costs or constraints on TLS servers or even >> clients and that might not be a good plan. > > Well, a log isn't much use unless it is public - but I don't really > know how to say much about who charges for what. We can state our > intent to run free services, but presumably not in an RFC. So ... I > don't really know how to address this. Yeah that's fair I guess. Maybe if it said that the intent of the RFC is that logs be public & open and SHOULD NOT require subscriptions or authentication for basic operation? S. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > From stephen.farrell@cs.tcd.ie Mon Dec 17 09:04:46 2012 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 1C8D121F87DC for ; Mon, 17 Dec 2012 09:04: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=[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 S+zWL7OgaQyS for ; Mon, 17 Dec 2012 09:04:45 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4DC21F87C8 for ; Mon, 17 Dec 2012 09:04:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A9A42BE36; Mon, 17 Dec 2012 17:04:23 +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 ZFc5aEjwWgUc; Mon, 17 Dec 2012 17:04:22 +0000 (GMT) Received: from [IPv6:2001:770:10:203:bcf1:96ff:1de8:8ef5] (unknown [IPv6:2001:770:10:203:bcf1:96ff:1de8:8ef5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 82119BE29; Mon, 17 Dec 2012 17:04:22 +0000 (GMT) Message-ID: <50CF5097.40400@cs.tcd.ie> Date: Mon, 17 Dec 2012 17:04:23 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03: point 9 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, 17 Dec 2012 17:04:46 -0000 On 12/17/2012 04:53 PM, Ben Laurie wrote: >> (9) 3.1, " However, the log MUST refuse to publish >> certificates without a valid chain to a known root CA." seems >> to preclude any solution for self-signed certs or DNSSEC/DANE. >> Is that a good plan? Maybe if you make it a positive "must >> accept" then that'd avoid that problem? (If a good solution >> for SSCs or DANE spam is figured out later.) > > I think this has to exclude SSCs and DANE until we know how to deal > with them, because otherwise a colluding CA and log could avoid blame > on the CA by logging the end certificate, signed by, say, some one-off > intermediate. This means we cannot weaken the MUST and still be able > to blame the CA. > > We could add language to the effect that although this does exclude > SSCs and DANE we welcome suggestions to allow their inclusion. That'd work for me for the experimental RFC. Others may quibble though, so it'd be great if someone did make that good suggestion S. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > From benl@google.com Mon Dec 17 09:08:12 2012 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 529FF21F8514 for ; Mon, 17 Dec 2012 09:08:12 -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=[AWL=-0.000, 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 hN7i5eXundp1 for ; Mon, 17 Dec 2012 09:08:11 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6A80821F8509 for ; Mon, 17 Dec 2012 09:08:11 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id dr1so1802548wgb.1 for ; Mon, 17 Dec 2012 09:08:10 -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=DblKUcWlHpK2soB//RluNkXbgOmv+cFAkOf/9dbIQlg=; b=PNOJ1tZslX35EHdY2sOnVwPwz8LVbzPjw4+9rea1XtlxFo2jkbjh+W9VGOZhoTaykT P7XLvGuNmHCzsGUojS1rrfpe2qwLa1XUGwRf6HCbOAabQIRwIFal0LkspQNugrVeNc7w fNxIJ4hmRmQJ+rN0a7F7pX952+bpT4z17juVAoT61YRJjpUo2feSEzSqkj1XSjxFSPIA DpjIC78ce/ci4MGFNBGDcRqOFww4YFMG4R7GktpQGwewBcAp/5izwS6HjsB3NZ6WxJrn uObDV9bD7YfLJ/EUZzqPkeeYVGkWpQiK93AKrKL50OsBfWSNSUfOWu4iU9fNvDk0Kpp0 qtQQ== 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=DblKUcWlHpK2soB//RluNkXbgOmv+cFAkOf/9dbIQlg=; b=FT2faKAoQDLojS1cavLnMeZJaAdlBobHT1Y/0PE1l7vZwj2k2GfTWFzpm700nxa0Au cNBib6GGv5pZyZ3/DEyOkj5zglFjgVJP8WrnAKGQjBYXfEGPsWq2PbYFMzgqHIe5J1QB +mHhMNv97JceVPN85uSr5Wy9J8za+iP0CPX90AbCA3/75OqiZiFvIt/Z0AfoJg+4fCJk R4syJoW5QZBHCbnM4q7lYwcI9iyT7kehqByks3OI4JStlZqQ11FEfGFrrRL6Cw0V3+Ir OcYhUXsAfVvBaseyTU3gFya1nGPGwzxCHCELQA6IwRFGyumyUiOItq1uG+joctjOA+hF LHLA== MIME-Version: 1.0 Received: by 10.180.81.170 with SMTP id b10mr17036749wiy.16.1355764090566; Mon, 17 Dec 2012 09:08:10 -0800 (PST) Received: by 10.194.51.35 with HTTP; Mon, 17 Dec 2012 09:08:10 -0800 (PST) In-Reply-To: <50CF5045.4020909@cs.tcd.ie> References: <50CF5045.4020909@cs.tcd.ie> Date: Mon, 17 Dec 2012 17:08:10 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmp/bECGZgELTj10Mfx/P3ztoyKyaT3j+KEw4Eh+59uvomTJ4wQdIqcyGTbdJDhaRsWdXtcJV7uy1F5oprQqmorkADrs7L1PkTmUyGcXgFplWBTP0jrNdh/mgQS75vVPEd9UVu3TTAz/KHSgqRXVYm5nI7sa2fhZS3b+P+TxHCtKzCXPsv+nBcRdPfXbt4gi7yAIevM Cc: therightkey@ietf.org Subject: Re: [therightkey] Review of draft-laurie-pki-sunlight-03: point 2 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, 17 Dec 2012 17:08:12 -0000 On 17 December 2012 17:03, Stephen Farrell wrote: > > > On 12/17/2012 04:51 PM, Ben Laurie wrote: >>> (2) abstract: "domain owners or their agents" makes it sound >>> like I might have to pay to monitor; be good to re-assure that >>> no such constraint is planned. (Such re-assurance doesn't need >>> to be in the abstract, arguably not even in the draft, but >>> also arguably ought be somewhere.) While its none of the >>> IETF's business who charges for what in general, in this case, >>> where there has been ongoing negative comment on the impact of >>> PKI business models on Internet security, I do think it'd be >>> good for the authors of proposals to be clear how they think >>> they're affecting such charging issues. Personally, I guess >>> that since EFF and some academics have been able to afford to >>> populate large databases of TLS server certs, this shouldn't >>> become a huge barrier, but it could in principle impose new >>> subscription costs or constraints on TLS servers or even >>> clients and that might not be a good plan. >> >> Well, a log isn't much use unless it is public - but I don't really >> know how to say much about who charges for what. We can state our >> intent to run free services, but presumably not in an RFC. So ... I >> don't really know how to address this. > > Yeah that's fair I guess. Maybe if it said that the intent > of the RFC is that logs be public & open and SHOULD NOT require > subscriptions or authentication for basic operation? Surely we can't make that kind of thing normative? Perhaps an indirect route would be to make a requirement on replication of data, e.g "logs MUST NOT impose any conditions on copying of their data", which would have a GPL-like effect of driving the price to zero for public logs? In any case this seems like a sensible thing to require! > > S. > > >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey >> >> From stephen.farrell@cs.tcd.ie Mon Dec 17 09:11:46 2012 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 5BEB521F8B0E for ; Mon, 17 Dec 2012 09:11: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=[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 Bjgf0GBLMQzv for ; Mon, 17 Dec 2012 09:11:45 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B167921F8514 for ; Mon, 17 Dec 2012 09:11:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0A4BDBDCC; Mon, 17 Dec 2012 17:11:24 +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 yvzTifqDXVW7; Mon, 17 Dec 2012 17:11:19 +0000 (GMT) Received: from [IPv6:2001:770:10:203:bcf1:96ff:1de8:8ef5] (unknown [IPv6:2001:770:10:203:bcf1:96ff:1de8:8ef5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0AFB5BE29; Mon, 17 Dec 2012 17:11:18 +0000 (GMT) Message-ID: <50CF5237.8040804@cs.tcd.ie> Date: Mon, 17 Dec 2012 17:11:19 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: <50CF5045.4020909@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] Review of draft-laurie-pki-sunlight-03: point 2 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, 17 Dec 2012 17:11:46 -0000 On 12/17/2012 05:08 PM, Ben Laurie wrote: > On 17 December 2012 17:03, Stephen Farrell wrote: >> >> >> On 12/17/2012 04:51 PM, Ben Laurie wrote: >>>> (2) abstract: "domain owners or their agents" makes it sound >>>> like I might have to pay to monitor; be good to re-assure that >>>> no such constraint is planned. (Such re-assurance doesn't need >>>> to be in the abstract, arguably not even in the draft, but >>>> also arguably ought be somewhere.) While its none of the >>>> IETF's business who charges for what in general, in this case, >>>> where there has been ongoing negative comment on the impact of >>>> PKI business models on Internet security, I do think it'd be >>>> good for the authors of proposals to be clear how they think >>>> they're affecting such charging issues. Personally, I guess >>>> that since EFF and some academics have been able to afford to >>>> populate large databases of TLS server certs, this shouldn't >>>> become a huge barrier, but it could in principle impose new >>>> subscription costs or constraints on TLS servers or even >>>> clients and that might not be a good plan. >>> >>> Well, a log isn't much use unless it is public - but I don't really >>> know how to say much about who charges for what. We can state our >>> intent to run free services, but presumably not in an RFC. So ... I >>> don't really know how to address this. >> >> Yeah that's fair I guess. Maybe if it said that the intent >> of the RFC is that logs be public & open and SHOULD NOT require >> subscriptions or authentication for basic operation? > > Surely we can't make that kind of thing normative? I guess it you can try say anything:-) I wonder what DNS RFCs say or maybe we all just take it for granted. > Perhaps an indirect route would be to make a requirement on > replication of data, e.g "logs MUST NOT impose any conditions on > copying of their data", which would have a GPL-like effect of driving > the price to zero for public logs? In any case this seems like a > sensible thing to require! Something down that road should be good. Might need some inventive language though. S. > >> >> S. >> >> >>> _______________________________________________ >>> therightkey mailing list >>> therightkey@ietf.org >>> https://www.ietf.org/mailman/listinfo/therightkey >>> >>> > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > From benl@google.com Mon Dec 17 09:52:53 2012 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 419B821F8BC4 for ; Mon, 17 Dec 2012 09:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.125 X-Spam-Level: X-Spam-Status: No, score=-102.125 tagged_above=-999 required=5 tests=[AWL=0.852, 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 jDPMjTvT06m8 for ; Mon, 17 Dec 2012 09:52:52 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id CBDC621F8569 for ; Mon, 17 Dec 2012 09:52:51 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so2156630wib.13 for ; Mon, 17 Dec 2012 09:52:41 -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=6XILcCNZxW+Ufqlsl5tjuJpcUKUlDOuF+UpwzZp56Vc=; b=klwJCQqLEY7EcAuCu2sP9HsGI2EQ/izM6H0WqXBDz+lO831YuFR4Tb7Rvv4+tguRUA J3FcSO6Sze3PfI+LdMLT7wuSb3entT+HQWfdTVl7XZ6E4jg7p4ozmoh3W44E8wpMIZVH NZQFw0X9M1wQnATyUb1c4uUs0Pd0+KUxE05VGv+iQm35880ApmwaqyGL7mjjL7PuXAfm b7sFZgNIpZRsfnJWBHUfRkvd7bUnBZEZZ5+DwmJBSaSD6cheOzTpjxehFtvUBBoCixbz V8F6ugdeTgFsdsQMl7B3ur5YcVIFOKka7p5gfghB7MMdvESo94aIb8CXBejO01qezW2d whwA== 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=6XILcCNZxW+Ufqlsl5tjuJpcUKUlDOuF+UpwzZp56Vc=; b=N6opBx2QQZUOHKgkkPbrSJhFCs7GMtT3+Gys2haf5x4HYAsS9sVv83YZSK7YMMRJ+E RqQgGlAoYbE+BiRcJfajs8neod6O/Qm8R158DsQ8yoA9xnvRW8Y+EhhsOS0/OE4vI0VB VTEL5OPNFc7ub8MwU1+YmWq58rSrWrjO+6y75S70FlOq/Yjt/zdOfsVOWZT42BWtU3xh PzK0aWClfQeJXcmCT0NDlFY3ewZOJ9fRCu8prgsKxJz0RSVRqYpCsdxRIwpks+28Isx8 o6/B4oDCV8iokSqN/YE4ZN7zYqFgRxmuJ2chYrkIuAwT0VZPh6QPogxkZDe5glX+5wih XQhQ== MIME-Version: 1.0 Received: by 10.194.119.33 with SMTP id kr1mr18877796wjb.4.1355766761153; Mon, 17 Dec 2012 09:52:41 -0800 (PST) Received: by 10.194.51.35 with HTTP; Mon, 17 Dec 2012 09:52:41 -0800 (PST) In-Reply-To: <50CF5237.8040804@cs.tcd.ie> References: <50CF5045.4020909@cs.tcd.ie> <50CF5237.8040804@cs.tcd.ie> Date: Mon, 17 Dec 2012 17:52:41 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQluNJzkgez3NOIAkuU2b2ce9rPf7YBQ6d/Df4xGXOZkC8owHk+RyRY6aF9IjiOuxsxb+pYdnDYsASauNxD3wVol5AAvzW8dCQSt1+B+cfnVCrEREL/gufG7cl8OUD2JWQgmsgaMQblSQNGWqSN/o1V0DeOXFg+Pmv2Z1TMcZzTo8x3GB+orRym3tiGhi6FPTSTCoaQr Cc: therightkey@ietf.org Subject: Re: [therightkey] Review of draft-laurie-pki-sunlight-03: point 2 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, 17 Dec 2012 17:52:53 -0000 On 17 December 2012 17:11, Stephen Farrell wrote: > > > On 12/17/2012 05:08 PM, Ben Laurie wrote: >> On 17 December 2012 17:03, Stephen Farrell wrote: >>> >>> >>> On 12/17/2012 04:51 PM, Ben Laurie wrote: >>>>> (2) abstract: "domain owners or their agents" makes it sound >>>>> like I might have to pay to monitor; be good to re-assure that >>>>> no such constraint is planned. (Such re-assurance doesn't need >>>>> to be in the abstract, arguably not even in the draft, but >>>>> also arguably ought be somewhere.) While its none of the >>>>> IETF's business who charges for what in general, in this case, >>>>> where there has been ongoing negative comment on the impact of >>>>> PKI business models on Internet security, I do think it'd be >>>>> good for the authors of proposals to be clear how they think >>>>> they're affecting such charging issues. Personally, I guess >>>>> that since EFF and some academics have been able to afford to >>>>> populate large databases of TLS server certs, this shouldn't >>>>> become a huge barrier, but it could in principle impose new >>>>> subscription costs or constraints on TLS servers or even >>>>> clients and that might not be a good plan. >>>> >>>> Well, a log isn't much use unless it is public - but I don't really >>>> know how to say much about who charges for what. We can state our >>>> intent to run free services, but presumably not in an RFC. So ... I >>>> don't really know how to address this. >>> >>> Yeah that's fair I guess. Maybe if it said that the intent >>> of the RFC is that logs be public & open and SHOULD NOT require >>> subscriptions or authentication for basic operation? >> >> Surely we can't make that kind of thing normative? > > I guess it you can try say anything:-) > > I wonder what DNS RFCs say or maybe we all just take it > for granted. DNS isn't free, so not sure what we take for granted? From benl@google.com Mon Dec 17 10:12:17 2012 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 3E85221F8B5A for ; Mon, 17 Dec 2012 10:12:17 -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 GTKZnznTiPa2 for ; Mon, 17 Dec 2012 10:12:16 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8052C21F8B48 for ; Mon, 17 Dec 2012 10:12:16 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so2850112wgb.13 for ; Mon, 17 Dec 2012 10:12:15 -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=leUrkqqKkMY+XCYvhnjfPFgrsp8OUSyJu/l8Fb23rJo=; b=JjjoioYeFCXkIJZPWPOYYDbMHL6+SyF/WpFDSvpOHM7URGKEvqtBJLlqn6CvjqSaqT cY2eVsvdLVK8wRv8KjUUYSVIZU9+9M0X+zx5R8QrRGvhn4Xxcrrx52SsBO2kQkLXBHjQ 81oUSnAN7j6/YtYH4tGQO5l3RLW5C4gvCKUzGe2i30fsh26WLIUF29EtMcGiTf+fdyJ8 uUS4DWYqqLzEp9hbLd5NPwJGfFuc144MUCHY3BEjIRMAIwNCqKtbv9rS8Q9H+H5GwdtL Qlwe59+Z6F15ZBbTO6Ut+iXLLnuSLwaF0ElFGBWNjneF5+1knOUw3dLkpGighRmF2ELd oVkA== 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=leUrkqqKkMY+XCYvhnjfPFgrsp8OUSyJu/l8Fb23rJo=; b=hC7p6NW57xoLnSS6G2rZzhbxGee6Cz/OkDHC0gvzsvlMlfTE3KOi6cA6Zr5nWDjJYs TQ7B/jqN0vh1zN/l2SBXgy4xpzsp8ey0ddJh2+n8XwEfirwsGZhkXhZNZ9glrsXOdsD7 MwTJH/RE0SbHeLsx/H88Ni/pmsUcSpVIqQApcm3taF98AUTlmQDIhKeTczVeqM6mnCPH BNV9kji55YlFEr83QeCRS4RqaHPwnBPWhizPzh6EgYGKQJ1IrkWt2U0ue0vVzRdBXvg/ lS+FCEbCiN2W80oq2s6IMUoklSjGI9YqL6oXeVsS267Tqtjad3C6wBykyyNZhG35uUkR Qlwg== MIME-Version: 1.0 Received: by 10.194.21.70 with SMTP id t6mr18702744wje.42.1355767935453; Mon, 17 Dec 2012 10:12:15 -0800 (PST) Received: by 10.194.51.35 with HTTP; Mon, 17 Dec 2012 10:12:15 -0800 (PST) In-Reply-To: <50CF5097.40400@cs.tcd.ie> References: <50CF5097.40400@cs.tcd.ie> Date: Mon, 17 Dec 2012 18:12:15 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnBKkJg7YNgrDsw1vG9s8hrWHdmWcPcqOFCMiEMn6evRHHRZrBXoyAY0b59UBUTFeh7f5RKqmiB9MNyYw3UUiboUSCnHbwLsXG97mgjrYooO/n6i4Klah1XkHX2wpLev6vIuAkkEy7Qo2M7HUlY5NsMof4gP5IgGqvjqSm2GI4EaBCyWhWT1trMRFxujkLQg8GrK37/ Cc: therightkey@ietf.org Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03: point 9 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, 17 Dec 2012 18:12:17 -0000 On 17 December 2012 17:04, Stephen Farrell wrote: > > > On 12/17/2012 04:53 PM, Ben Laurie wrote: >>> (9) 3.1, " However, the log MUST refuse to publish >>> certificates without a valid chain to a known root CA." seems >>> to preclude any solution for self-signed certs or DNSSEC/DANE. >>> Is that a good plan? Maybe if you make it a positive "must >>> accept" then that'd avoid that problem? (If a good solution >>> for SSCs or DANE spam is figured out later.) >> >> I think this has to exclude SSCs and DANE until we know how to deal >> with them, because otherwise a colluding CA and log could avoid blame >> on the CA by logging the end certificate, signed by, say, some one-off >> intermediate. This means we cannot weaken the MUST and still be able >> to blame the CA. >> >> We could add language to the effect that although this does exclude >> SSCs and DANE we welcome suggestions to allow their inclusion. > > That'd work for me for the experimental RFC. Others may quibble > though, so it'd be great if someone did make that good suggestion Done. From benl@google.com Mon Dec 17 10:19:15 2012 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 D7B0121F8B2E for ; Mon, 17 Dec 2012 10:19:15 -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 jBO0DpV0BdxS for ; Mon, 17 Dec 2012 10:19:15 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD0A21F8B16 for ; Mon, 17 Dec 2012 10:19:14 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so2854052wgb.13 for ; Mon, 17 Dec 2012 10:19:14 -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:content-type; bh=dgxe0hnhKKdT7rJJZwclwS+uoEPRWAUUOeAiezmFH7U=; b=dmQgcGmZgMzFBOuRUNMzhdY5IBVOnHYlKQl0FHXhFVxhJcqa7IAn0LsdSVa7suBvig SvilxmS/PROQdDDmC5U5Pah8iCWmlgp5ZabMhpr9CSbkR2/1FIgml9DWKvOn2Jp0XdI+ HAVXIebvKkcrRjVMC/TRDptnxaR4i6xjCFgGqOrCx1KEp5Hq8vXbxihKnJhLy5Rn6OU4 I/bVnp51RSlD127IokYTdsPNeanL1KTt65gaiw0t4AYyekFZ8UhjxPPOwMjKB/5debBe dvbi0U8lbuHVEHk3b/R6kfC+uYOsrzWMPB7BK/rsoz0lA/bd0xUvFml18lFmb9KjCqG7 45Bg== 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:content-type :x-gm-message-state; bh=dgxe0hnhKKdT7rJJZwclwS+uoEPRWAUUOeAiezmFH7U=; b=CdjUwIeszJmIsrof3DVWzShphZBhOPuCzbIx2PZdA1uXR01H+8EsNTxp82AXb8Q73M kWGGAr2YRfWqCEhTI8KW32dGteiKh4Rz/fJM3nJVrtNmsSELPG81mfvn5FRQm4tgSE99 lWUx/TbgzF97HCSCmSAA62bklOzscnreQC7XCwsg2NyHMO/SiKCXYIHC8kpux3nxxg6a 3xqIsseU81oEcejDA3uArV8ia4xdviXv0knMJvwIzwnsdg+huK4fHcSQ63k6AXEyphvz Gv8kNz3E1r1TBIv0yypcrHLuY98i3hdzXLDclgOoP80VybjByIE19EyYlMsyJy0SNwqr DdjA== MIME-Version: 1.0 Received: by 10.180.20.176 with SMTP id o16mr17399564wie.10.1355768354094; Mon, 17 Dec 2012 10:19:14 -0800 (PST) Received: by 10.194.51.35 with HTTP; Mon, 17 Dec 2012 10:19:14 -0800 (PST) Date: Mon, 17 Dec 2012 18:19:14 +0000 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm2ONtPsrxFc94EYyIUgT9Z7CkkC8mGZt20jzuJfwdK3OC1Zwu/vht9ogM9rWnujf9XLi0INrYmsXONCFeQzDloWXJezP21w+f4eYMmAQ9YHCJkyDJDGGxHWVJbreNpqMufjEzHLHMGXw5qXGsJSeY42aim385mGBDf4iSEtM2bUDOhqEUcCeaXXHPalJZYsavZ0y0C Subject: [therightkey] review of draft-laurie-pki-sunlight-03: point 10 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, 17 Dec 2012 18:19:16 -0000 > (10) 3.1, identifying a log solely on the basis of its key_id > without any roll-over seems dumb. What if the log wants to > roll its signature key? This would have to be fixed in a > standards-track RFC but really could be done now and would be > better for having being done. Our view was that a new key is effectively a new log and so roll-over is achieved by ... starting a new log. If it is done because of key compromise, then the old log can no longer be trusted. From benl@google.com Mon Dec 17 10:21:09 2012 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 36AFE21F8B4A for ; Mon, 17 Dec 2012 10:21:08 -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 uEm5Jat251+I for ; Mon, 17 Dec 2012 10:21:04 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id D6DAE21F8B48 for ; Mon, 17 Dec 2012 10:20:59 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id dr1so1845147wgb.1 for ; Mon, 17 Dec 2012 10:20:59 -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=qVhiNJvUyPY0yT8nKvbiUKlQEzAIk1xRKeL1wOS1iSk=; b=FztbXjzjNB0U84ajhVLPfd7X5qptfkCA+mq7RfI4HrMJeRqTzMYLcvCl5SoBaHTaOR CgRAfq8eHnGwKOTvTM2RjPh/1ywTtucDWbBQ0+YLTnTYZu8O1Iw4aPTS+pkNyTkccC5I Dcg431o4ysxAmvpwCySa2hMNXd/CtHMpT79CrFHRxLddjvv6l/XJLVxlmfxek8E9768z yxaqQ/PX4wD15m2V10jtJtXy84ACDhDjJ+2cqU8hExfNNOb5lqHEBHGMhUK7Nl0qCtFA qc7FwRVM0UlcKD8cwOfEi7nZcDuoLTSGENNBjyDBTwhkn70JuRgrsSe0CvWUQ5ZMxwbZ 64Iw== 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=qVhiNJvUyPY0yT8nKvbiUKlQEzAIk1xRKeL1wOS1iSk=; b=U4jIXd2JvJOLU1TykAXtlqRL//ppKd05jEuzVDQNnwiMe4sNZou7qJ79zfKKAdSXxe YkjqiJNLzVuwFNDSx5E3ux4Q3APsIlqslVnugA6UUt0s2D1tG28LUIbrBZnGQh2Z7sxs a8h/D37rblyhAeSYKz4776xceBuqGpT4HZOnep+XJdCbfdRAw0P0TXS2EGx/3aCPPcZ5 JvTKM+yV7iIB6Nrhin9e/XhpJBpsSR3/uQXrFraxmNvghVuqHFnTHirR9E+cV/ZL0s0T eQApkPZceI1n/DWrj4DAovkGfDfEYTIx7SoNvNKLlHjax5/lRkBck1mkH18hWm+xTui7 9cBw== MIME-Version: 1.0 Received: by 10.194.21.70 with SMTP id t6mr18752375wje.42.1355768459068; Mon, 17 Dec 2012 10:20:59 -0800 (PST) Received: by 10.194.51.35 with HTTP; Mon, 17 Dec 2012 10:20:59 -0800 (PST) Date: Mon, 17 Dec 2012 18:20:59 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnY6ksaevj/5y2Y1sCZ6SxbX/ahokXTCQSPPp2HcGvzhffy3HLKn+iF9Eai5CHcRcc2cyiWEsAKS0FzHxEzGW7QK8c0JeanH35DHYCI3GezufD/Gwsx9EGXjD1BDEwx5/9uXiZPR1kZqZFog+vLFsIeTTixh0pFiqMrwoBmUikyM+/rDXvSY5bTFRLSqVwB2hAapuKu Cc: Emilia Kasper , "therightkey@ietf.org" , Adam Langley Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03: points 1-10 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, 17 Dec 2012 18:21:09 -0000 On 17 December 2012 01:54, Stephen Farrell wrote: > > Hiya, > > I think this is getting very near the point where we can last > call it, but isn't quite there yet. My review below. > > Cheers, > S. > > maybe needs thought, defo needs answering: > ------------------------------------------ > > (1) RFC 5878 has a bunch of IPR declarations [1] attached and > is not afaik widely implemented (is it at all?). We implemented it in OpenSSL. I have patches for Apache. > Is re-use of > that really a good plan for something ultimately intended to > be used for all web servers if that IPR were problematic? > Note: in the IETF we don't judge the terms nor applicability > of IPR but we do pay attention to what IETF participants say > they think about that. In this case, there's no WG, so I'm > asking. (Full disclosure: one of the declarations is a 3rd > party one I made. [2]) My take is that this might be > problematic, but what do others think? I do not have a view on whether it is problematic, but would be happy (ish) to propose an extension all of CT's own. > [1] > https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=5878 > [2] https://datatracker.ietf.org/ipr/808/ > > (2) abstract: "domain owners or their agents" makes it sound > like I might have to pay to monitor; be good to re-assure that > no such constraint is planned. (Such re-assurance doesn't need > to be in the abstract, arguably not even in the draft, but > also arguably ought be somewhere.) While its none of the > IETF's business who charges for what in general, in this case, > where there has been ongoing negative comment on the impact of > PKI business models on Internet security, I do think it'd be > good for the authors of proposals to be clear how they think > they're affecting such charging issues. Personally, I guess > that since EFF and some academics have been able to afford to > populate large databases of TLS server certs, this shouldn't > become a huge barrier, but it could in principle impose new > subscription costs or constraints on TLS servers or even > clients and that might not be a good plan. [response in separate email] > > (3) Sometimes you say "the log" and other times "logs" I think > the term log needs to be used consistently otherwise we may > end up being unclear about cardinalities of things later. > Suggest adding a specific definition for this term, or invent > a term for all logs everywhere. OK, I have gone through the document and cleaned this up. In short, I have referred to "the logs" meaning all of them, and used terms like "a log", "each log" or "a particular log" elsewhere. The actual phrase "the log" still crops up but is hopefully clear from context. > (4) You say you expect "most" public CAs to take part. I think > that's a bad thing to say for an experimental RFC and could > cause you problems at IETF LC (say if some CA says "this is BS > because we're not taking part"). The experiment in any case > doesn't need most CAs, just some useful number and you seem to > have that. I removed the word "most" :-) > (5) 2.1, better to say sha-256 is hard-coded for now and that > that's ok for an experiment - you may well get comment on that > since a standards-track RFC would need alg. agility probably. > Do *all* logs have to use sha-256 or is it just that all logs > have to use one hash alg? Be good to be clear on that too. Done. > (6) The precertificate thing needs some more detail at least, > e.g. what's "poision" about? (I assume its to prevent such a > "pre-cert" be verified anywhere, but then you could also mess > with the dates.) Also, saying the precert-signing-cert has to > be signed by "the CA cert" private key isn't quite enough. If > you mean the same CA cert that's above the TLS server cert > then that might not be possible (e.g. with pathLen) albeit > that's unlikely, but there could be other reasons why that CA > can't issue a CA cert (which the precert-signing-cert is, > right?) Done. > (7) 3.1, p10, 2nd para: "...chain...to a trusted root..." does > that mean that trusted root has to be the CA that issued the > topmost cert in the submission to the log, or is any trusted > root accepted by the log ok? ("using" the chain might not be > considered normative.) I think I clarified this in the process of fixing point (6). > (8) 3.1, says the log can accept "not fully valid" things but > also says that a "valid chain" is required. That needs > clarification I think, since some would consider that a valid > chain cannot contain e.g. an expired end-entity cert. This is essentially hedging against operational CA difficulties, so I have clarified that. > (9) 3.1, " However, the log MUST refuse to publish > certificates without a valid chain to a known root CA." seems > to preclude any solution for self-signed certs or DNSSEC/DANE. > Is that a good plan? Maybe if you make it a positive "must > accept" then that'd avoid that problem? (If a good solution > for SSCs or DANE spam is figured out later.) [response in separate email] > (10) 3.1, identifying a log solely on the basis of its key_id > without any roll-over seems dumb. What if the log wants to > roll its signature key? This would have to be fixed in a > standards-track RFC but really could be done now and would be > better for having being done. [response in separate email] From benl@google.com Tue Dec 18 04:14:28 2012 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 B7B5421F86F7 for ; Tue, 18 Dec 2012 04:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.639, 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 QGFwDGzYxzKM for ; Tue, 18 Dec 2012 04:14:28 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC1121F86FC for ; Tue, 18 Dec 2012 04:14:27 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so324588wib.1 for ; Tue, 18 Dec 2012 04:14:27 -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:content-type; bh=E4HRtoc3Bjwd6CZG3LyWQf3UNqiarl0o8Y6hg2cv41I=; b=QhacBcOB7o9Ao1YU0n0hdxW5vERJilHx8s2GRkjFo0VWFyrKfvrf3E2Kn9lmefRGHw 6GpzNMW3Si5/wwkM8w30RS5BW0K0bLAP3mbsBWGHBDfKgHdU6QsLcvFfjnIQugtSewWl /c7Qy7LS3YSOyJJYDJ0WNnAu+cUrLNKoWrtckemf5DxJE48tm+KnZotLoJovuFFgnL2C odW81nxtZEVW+3GkeythUOBJi4JCrQ/XfiEjLx1O4aKLfIqo6oIdsoxYDMJvle12jE9q b8BnOo/MhO7cJdBy9HOD4MHHOXGznMuLOCOgmUqpJofGCkjuISwjQYvK93MiouzKHRHx 6Rtg== 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:content-type :x-gm-message-state; bh=E4HRtoc3Bjwd6CZG3LyWQf3UNqiarl0o8Y6hg2cv41I=; b=SaRkKXM9+IewY2l5sZpxA4KOSAMa7pJLiAxTUWU7lPzAVDDe5mDSykz/KwwVCnGE++ 8+felGfGNppFgtGikDjlZOwckOfDyq6sIKk3KgdWkhzCkcfxibd2XbxGguskdpUJtj7h uhFqQoPXHmjC8hgnwRi72Tr/tzx2rmuOYLHQTDh4Lj/vItjrFV/8wzwa/ktjFSykX/M2 vEdnvGUUzK9in9xt9/A15mRP1nXdDNzXZOm2broZBX4RU+ZPUfq/TS0HY1iqsH/lLd7a qn8GKx+H5CQ8Ecqy2URowqD+8jDR5KtNa1/hTUDdVwBJVbb1kkSti1tHKJqGzzTCRLr9 5Q6A== MIME-Version: 1.0 Received: by 10.180.93.3 with SMTP id cq3mr4368412wib.1.1355832866923; Tue, 18 Dec 2012 04:14:26 -0800 (PST) Received: by 10.194.51.35 with HTTP; Tue, 18 Dec 2012 04:14:26 -0800 (PST) Date: Tue, 18 Dec 2012 12:14:26 +0000 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnAeF/sfPr1wdg93yM2UnUY3CmJyT5m74Tx7S9vV9wzI6bDlN0gaSU+DIFQ0SlbFB5CdF9EWHIRpD1cdATmBXqGqu9QJY7iNahr8sNyR8w/xw3oXIQt3nhVPB40GQvDVuI2T46Ox6BHSYA8dtPLOwZDKerpXdUNnCXgHkWqFLP5gqGA/RkWGzKYQmw4eB5L2HJjdwrL Subject: [therightkey] review of draft-laurie-pki-sunlight-03: point 12 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, 18 Dec 2012 12:14:28 -0000 > (12) 4.x - would it make sense to use .well-known/ct/ URLs or > not? Not to me... a) .well-known is a discovery mechanism, but CT logs will not be discovered, they'll be explicitly known. b) We allow the prefix to include a path, which would defeat .well-known. From benl@google.com Tue Dec 18 04:15:38 2012 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 B6A9221F87D8 for ; Tue, 18 Dec 2012 04:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.511, 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 fQ5yTIUVsvJz for ; Tue, 18 Dec 2012 04:15:38 -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 DA6D821F86FC for ; Tue, 18 Dec 2012 04:15:37 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hn3so324553wib.11 for ; Tue, 18 Dec 2012 04:15:37 -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:content-type; bh=mhtZcSbRzQtXGXL3i/ZhTTCj6zrajf1YPxd3pvK7WOI=; b=crl8mLkok5NVFzKELK/7VJjJmznXMQElD0f58C7KBicSEGWeLPrJInSvMvclzp1DUA r3mz/Yt7TNMM4j58hVCiyqRwMIktiT2O7POl9lmqC4+qzEnV7LNbZ8G8Al8ECfJRziEm vSD8gu2xRzpLE8Mg00Wm0oEkeijmD48QSXV2oCrzByrqjoubukuOAvHlU62oI/Mk0Wd5 oUTzKCEiE2L/0/TU+IIwmVFHfI+pz08rwLy5HhVCgPwYiW6jUNeyXDIro+94hUNHoaRq HijKcDgrhs3OxJK7z9A1ADOn8//e09fiCBMGNH8+mw5DPPvmFwpYc1yC4UGC4zTnJMJN HdQw== 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:content-type :x-gm-message-state; bh=mhtZcSbRzQtXGXL3i/ZhTTCj6zrajf1YPxd3pvK7WOI=; b=jZwC58Hw2S0+EL+d6OUbAkGBCUKJ+qBWLRduuboECbc+JmUsT9NaVVnquM9FXKH1r4 TQp4Xa3A4Jq6ZwEytu+xVi9dLxXZizqoqB/wkNe3emLzZ4D5ghAOd1shwrK/UZl7HeqS 9INnCHr4Ty05tFF32e9VLxGUFIlS+BLi08yE1dF5HjJALUbb44ly6D9OvZukWI7Arnf2 JgOWiX8nHAfCiHkLnfUSS0aT35ZBK4y1pShG/INqP3fVz8GIXrmx1Tw+3rBF0LCBVgBg JEUfQymnPhUH6Gm4DaHMOJUY5gd09TxL7WwWHrFm3iADvFvy52UhCQjVIuIEkPLBJ9uW PmuA== MIME-Version: 1.0 Received: by 10.194.236.68 with SMTP id us4mr4007675wjc.11.1355832936954; Tue, 18 Dec 2012 04:15:36 -0800 (PST) Received: by 10.194.51.35 with HTTP; Tue, 18 Dec 2012 04:15:36 -0800 (PST) Date: Tue, 18 Dec 2012 12:15:36 +0000 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnmK47xPKjKYfaDw4ZYoq1Nb8Pq8VqlxO3P3bQF0YmRcelHOURtAFVm4dLSbWLCRhH0iJtrPWO3NfGqRdWPVR5uoEeL0swisBBe3KBkOBpNESo9h2T1lTu5nxpYDsTezzos/idb3kWDF70WUfSs+Tq1zg8gYRFrdfxosLScSrEonqm87E0hLg+RyYDzSmJUk/qkJ/MA Subject: [therightkey] review of draft-laurie-pki-sunlight-03: point 11 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, 18 Dec 2012 12:15:38 -0000 > (11) various places: I'm not sure you need extensions in all > the places you have 'em - if this does become an experimental > RFC followed by a standards-track RFC, then that can be > handled then. We only add extensions to the SCT - everywhere else is just propagation of that one set of extensions. From benl@google.com Tue Dec 18 04:19:45 2012 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 9194821F8948 for ; Tue, 18 Dec 2012 04:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.426, 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 v2rPEGCHu1S2 for ; Tue, 18 Dec 2012 04:19:45 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id D95D121F892E for ; Tue, 18 Dec 2012 04:19:44 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so328228wib.7 for ; Tue, 18 Dec 2012 04:19:44 -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:content-type; bh=6LhlqNIn2OtjRe9ZUAd3o88GhFlEQzBbZrEgyBRALmw=; b=KnLFhbOu3aoh72ty1l9WFitB5sveFc8mM1xIqT1NXMVddq/xkHpYdvh4R1ZV5PILfZ n7hOJUKZr0yjLdDfsi8A4T0XGcJuWwHK2EaNkvtYzZB0m8RIJuKzXQ4OzKfMUrX9fqaS ZpG7hVfZ+HhFBymMxgRRK/3s0J7ntSWYnWQiOIsCDO9Cf+ZifjcBKqOpNwTaq8KOpA8H XG84xlnd1XjDkHpfxAuk9MnZVeQ69UKLW0qhR2j17UOGPaPjYcWQ6WJzZUQrzAuti8GV lV8XJxFoCcYymhpY/JNzT9bzCVRcb99YdOXkA+pDv83uDnoMFbXZs5HcGP2QCGPNVymL 9/yw== 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:content-type :x-gm-message-state; bh=6LhlqNIn2OtjRe9ZUAd3o88GhFlEQzBbZrEgyBRALmw=; b=g3gJiz4GfS0wHC08s6qSB594M6488r9OKMDtuAfDVrjwfpEe1B5zwLZcEslP/SSVme 7Vg336fbAgrGndN4+gt3BqZFoXY8uGQRhx726kANBqMMPOwAw3L3oZsy1If3rVHts5Id YWCLO8tXF2R0XQaeDvQGeAQ8EphtV1BZduHW9hLF1w8VKpfJZTBvY640n3wZB3SqiBWQ 9AUqYpb+16R2TtRfB3snje23JX593Jor4MAUrjagACQ5hmRLr8qIjwWVTNevM8Iekn5d kGTaRharKmEyaqFAKAOqZFtO3jGQxFmEZyyR2PuhhzW4F/jMPAW51DkAOvQO+gkv+XG2 H+jg== MIME-Version: 1.0 Received: by 10.180.83.169 with SMTP id r9mr3874644wiy.10.1355833184010; Tue, 18 Dec 2012 04:19:44 -0800 (PST) Received: by 10.194.51.35 with HTTP; Tue, 18 Dec 2012 04:19:43 -0800 (PST) Date: Tue, 18 Dec 2012 12:19:43 +0000 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlPFB+oU2iN1F5738YQDQMx0REzoXya3Pczmi8HY/q23YRm28cDgKHUcGaO083NGD2qmFBsz5ueF2OxDoX5M0Xwctb5haF+kkzZh+Swip8oYGifRX39FUidEljVgOVnEIGXkAjMgiKxSZNs3+NCC5PrqtCF/ev8k7JGl907dGOS+vi8T6sBF/Yw2Jtev4eu78aDnfZy Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03: point 13 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, 18 Dec 2012 12:19:45 -0000 > (13) 4.x - how does CT impact on the TLS server cert used for > these HTTPS connections? I presume you're afraid of some bootstrapping problem. So, let's imagine a world in which no logs exist yet, but clients insist on CT for all new certs. How do we get off the ground? Easily: the log gets a cert from a CA _without_ an embedded SCT. It then logs it (using an internal API) to get an SCT, which it serves using a TLS extension. From benl@google.com Tue Dec 18 08:51:17 2012 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 C90E321F854A for ; Tue, 18 Dec 2012 08:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_52=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 5gvPX4jkHqXo for ; Tue, 18 Dec 2012 08:51:17 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8245B21F8512 for ; Tue, 18 Dec 2012 08:51:15 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq7so3118972wib.1 for ; Tue, 18 Dec 2012 08:51:14 -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:content-type; bh=i0CP4ilQCO7HkYQtlAy5MJmxvTdWFzvssUS6tMu2cjs=; b=KNvN9Rj0muYbC5GeQ4pzWjtfFulvW+Hr+Lr6tf0vwT6Bw5oDAAhugEwTctnW7NXB1d L84DXwaMK2MvhXrtkcT+/I3X4arsXT0Y/paFSTd/3AVypYj//ZV1b7eCZCqirVACBJYx vBvaifw6/d6xdepvPcSmN/2bIW/vIe4R7lWydHBmaxB1LI9+L6dhEz8cj5ALn3LhiWa9 q7/upH+TrClzJtS9xkdmwRNrBueNz5R6xYeGCNVt9kIN4sJw8CemLwVbRGPJwmcu+rui CjEkOFwtUw5shoq6VnbfG6kzJ7pQs1ReSqdaruJVz/H7mDDR2Kfq28MIzK0GSRneNh5p LUhA== 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:content-type :x-gm-message-state; bh=i0CP4ilQCO7HkYQtlAy5MJmxvTdWFzvssUS6tMu2cjs=; b=pIudKM91PQ6TWPDb7MM6CjT0cuV6uHY5iq6iQEMxVutjBORuR++WIKZQgSTSkfcc6P +dvGpc4RpWCv328/t4vMYN6eknKQKMqimdtWZpxy8G0Nx8iNOZfCEayWePaSrAGSTw0L +s/jg6b4bIA+gC25hP9T9g+vmtj5NxjkPCuBPnIdEuKEtCIah6kuhtG+SGfxOmkLxPbb jAtBqsgXStsOMVUaG5GeXqeXyjDmU1p/O+YrUphbE1pkPJwT7Dyhfel9wFEF6hmXzdap YlWjPkHa7XSLI/bOKh4ImIbhOrDlsX7okA/bZvxXn052grtlMurf1spJXU6+l4lqf5fS 8IHg== MIME-Version: 1.0 Received: by 10.194.21.70 with SMTP id t6mr5753529wje.42.1355849474199; Tue, 18 Dec 2012 08:51:14 -0800 (PST) Received: by 10.194.51.35 with HTTP; Tue, 18 Dec 2012 08:51:14 -0800 (PST) Date: Tue, 18 Dec 2012 16:51:14 +0000 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnpJTvYKuBN++EbE7GwpIbH//c2jJuaRHbeDJgF7TCO7QyH5S4tTGdgLCh7PZmuR6ptwSHtAIPBK9JUzdNCZon3ze7SRHcG7WbxZWtmI5lJJvGM0yrr3nqqXuqlR4kkQ/pTPy6ZTrlD+hHlOo7oeZ0UtIeakfh7KGwl4UlBwUZYpZX4u8x8AVsnmrz40CGC87r8eSrv Subject: [therightkey] review of draft-laurie-pki-sunlight-03: OIDs 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, 18 Dec 2012 16:51:17 -0000 > - Where're the OIDs in 3.1 and 3.2 registered? They should be > in the some registry I guess. Should they be? They're rooted on Google's OID. We have an internal registry for those. Isn't that the point of OIDs? (i.e. that you can generate new ones yourself) From benl@google.com Tue Dec 18 09:28:33 2012 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 09B0D21F85E7 for ; Tue, 18 Dec 2012 09:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.62 X-Spam-Level: X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=0.357, 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 HL45IWdJeAsV for ; Tue, 18 Dec 2012 09:28:32 -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 E87A621F85C0 for ; Tue, 18 Dec 2012 09:28:31 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hm11so2985832wib.14 for ; Tue, 18 Dec 2012 09:28:31 -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:content-type; bh=Q41eLZNcqjsT6Myo1b/VfJYeSnv73s6gL4lZ5MFiSZc=; b=AJxOPcRkASgT2ZN/SgQ9fY3B6j7hj9NyaNoG3OcLOJt/igOEqOFjWdPGabIfDcioF7 dLEjIpaOHmFzxBA1pGRvmLqC6HZOBgiyBex2mVSeAAp3af3YX/xLYwD5KkFaXmIUY6hw bgzeMA9NNj1ZcRA4dhX6kGCOpP0t1DLBe5Tq/baw9oyjET89MnRj+oEe24WilMuzoG3N VLcqsP2I9BDFmXpDVXxR9CDM/anyf88mr/B0rAeN0sW/1kE2SR0L9sG/k9yWQPCF8u+1 0ejvAyTwbAReKYm0kHaii5MFeAO3emtIKgpk1UYK5outClYsllwL01blUxSjyzyEWq6F I9ZA== 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:content-type :x-gm-message-state; bh=Q41eLZNcqjsT6Myo1b/VfJYeSnv73s6gL4lZ5MFiSZc=; b=EQuuVf9e+ekNnWdGuzXlo47LQjv4m2PNWW6eBis7eH9Th2R20jyqrQGuy9wIrtPgYS vGOGSFT61+N2+tm99MlvxUdwyinIQo+TTbnyBIBYWv5o9gxv+neKP2o0oPw9ycE9gR3B nRR5QnChp20JAoDwKVGKCBG4712asUNA0LtqgobKsmTwregFXnCx2FJOwXRqK8aIbgfE ZgyqjE422jj56N7Ka0VwQFGcWoWJjrA0XVfBVo4Fe79x3Tl+kJKpU1oHAptM0VeAMg/4 7LNBoCOXy8O+bNhmCPV0piHeEukwXCUheGjtZcyRB5UVYjVMai0ytvlibkbt630Npbyp oO3Q== MIME-Version: 1.0 Received: by 10.180.20.109 with SMTP id m13mr6332635wie.16.1355851710823; Tue, 18 Dec 2012 09:28:30 -0800 (PST) Received: by 10.194.51.35 with HTTP; Tue, 18 Dec 2012 09:28:30 -0800 (PST) Date: Tue, 18 Dec 2012 17:28:30 +0000 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmC++Yc8n9cXIO06PdMtzWKmBRMcG3tLQAqKqHPl0FZgpqLSgd/1XUq570K4o4NTa44XcqWWrrR2GIyWZKPZUUZi2ez/eXCyq1nyvOpnn4SpSyEpDsjgs9Y07kXBqiJBcIqoioYvZGt6R+Jpin50KsdbN0LzHYCDA8QrDk+/7W8lzhaPt77nZmPriWfzodc3fKZzsFf Subject: [therightkey] review of draft-laurie-pki-sunlight-03: gossip 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, 18 Dec 2012 17:28:33 -0000 > - section 5, 2nd para: gossip TBD needs to be done I don't think I can do that any time soon. Can I say it will be defined in a separate spec? From stephen.farrell@cs.tcd.ie Tue Dec 18 14:17:31 2012 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 DAC3321E8054 for ; Tue, 18 Dec 2012 14:17:31 -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 ogTlWRv6idsv for ; Tue, 18 Dec 2012 14:17: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 54E2121E8039 for ; Tue, 18 Dec 2012 14:17:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 72E1EBE2F; Tue, 18 Dec 2012 22:17:07 +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 kgfzntzqz7Ls; Tue, 18 Dec 2012 22:17:06 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.41.54.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A413CBE29; Tue, 18 Dec 2012 22:17:06 +0000 (GMT) Message-ID: <50D0EB62.60704@cs.tcd.ie> Date: Tue, 18 Dec 2012 22:17:06 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03: point 10 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, 18 Dec 2012 22:17:32 -0000 Hiya, On 12/17/2012 06:19 PM, Ben Laurie wrote: >> (10) 3.1, identifying a log solely on the basis of its key_id >> without any roll-over seems dumb. What if the log wants to >> roll its signature key? This would have to be fixed in a >> standards-track RFC but really could be done now and would be >> better for having being done. > > Our view was that a new key is effectively a new log and so roll-over > is achieved by ... starting a new log. If it is done because of key > compromise, then the old log can no longer be trusted. Hmm. That seems wrong to me in some cases. If signing with RSA then I might want to roll a new, longer key at some point in future, but without having to consider the log as changing. Similarly, I might want to have both RSA and ECC based signatures if different clients support different algs. A log might also want to upgrade some crypto h/w in a way that doesn't allow for migration of the same private key. Maybe this and other similar things might be usefully handled in a section called "stuff we might change as we move to standards-track" or something? S. From stephen.farrell@cs.tcd.ie Tue Dec 18 14:26:25 2012 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 73DA021E8085 for ; Tue, 18 Dec 2012 14:26:25 -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 ZHo5syCL2lDl for ; Tue, 18 Dec 2012 14:26:24 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1F59E21E8082 for ; Tue, 18 Dec 2012 14:26:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 63C4BBE2F; Tue, 18 Dec 2012 22:26:01 +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 QdXTPjJ5qE1M; Tue, 18 Dec 2012 22:25:58 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.41.54.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A6089BE29; Tue, 18 Dec 2012 22:25:58 +0000 (GMT) Message-ID: <50D0ED76.1030302@cs.tcd.ie> Date: Tue, 18 Dec 2012 22:25:58 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Emilia Kasper , "therightkey@ietf.org" , Adam Langley Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03: points 1-10 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, 18 Dec 2012 22:26:25 -0000 Hiya, On 12/17/2012 06:20 PM, Ben Laurie wrote: > On 17 December 2012 01:54, Stephen Farrell wrote: >> >> Hiya, >> >> I think this is getting very near the point where we can last >> call it, but isn't quite there yet. My review below. >> >> Cheers, >> S. >> >> maybe needs thought, defo needs answering: >> ------------------------------------------ >> >> (1) RFC 5878 has a bunch of IPR declarations [1] attached and >> is not afaik widely implemented (is it at all?). > > We implemented it in OpenSSL. I have patches for Apache. I wonder if anyone else plans to implement now and could say if they see this as an issue or not? > >> Is re-use of >> that really a good plan for something ultimately intended to >> be used for all web servers if that IPR were problematic? >> Note: in the IETF we don't judge the terms nor applicability >> of IPR but we do pay attention to what IETF participants say >> they think about that. In this case, there's no WG, so I'm >> asking. (Full disclosure: one of the declarations is a 3rd >> party one I made. [2]) My take is that this might be >> problematic, but what do others think? > > I do not have a view on whether it is problematic, but would be happy > (ish) to propose an extension all of CT's own. Fair enough. As above, I guess if others don't comment then what you're doing must be ok for now at least. The rest below are fine, Cheers, S. > >> [1] >> https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=5878 >> [2] https://datatracker.ietf.org/ipr/808/ >> >> (2) abstract: "domain owners or their agents" makes it sound >> like I might have to pay to monitor; be good to re-assure that >> no such constraint is planned. (Such re-assurance doesn't need >> to be in the abstract, arguably not even in the draft, but >> also arguably ought be somewhere.) While its none of the >> IETF's business who charges for what in general, in this case, >> where there has been ongoing negative comment on the impact of >> PKI business models on Internet security, I do think it'd be >> good for the authors of proposals to be clear how they think >> they're affecting such charging issues. Personally, I guess >> that since EFF and some academics have been able to afford to >> populate large databases of TLS server certs, this shouldn't >> become a huge barrier, but it could in principle impose new >> subscription costs or constraints on TLS servers or even >> clients and that might not be a good plan. > > [response in separate email] > >> >> (3) Sometimes you say "the log" and other times "logs" I think >> the term log needs to be used consistently otherwise we may >> end up being unclear about cardinalities of things later. >> Suggest adding a specific definition for this term, or invent >> a term for all logs everywhere. > > OK, I have gone through the document and cleaned this up. In short, I > have referred to "the logs" meaning all of them, and used terms like > "a log", "each log" or "a particular log" elsewhere. The actual phrase > "the log" still crops up but is hopefully clear from context. > >> (4) You say you expect "most" public CAs to take part. I think >> that's a bad thing to say for an experimental RFC and could >> cause you problems at IETF LC (say if some CA says "this is BS >> because we're not taking part"). The experiment in any case >> doesn't need most CAs, just some useful number and you seem to >> have that. > > I removed the word "most" :-) > >> (5) 2.1, better to say sha-256 is hard-coded for now and that >> that's ok for an experiment - you may well get comment on that >> since a standards-track RFC would need alg. agility probably. >> Do *all* logs have to use sha-256 or is it just that all logs >> have to use one hash alg? Be good to be clear on that too. > > Done. > >> (6) The precertificate thing needs some more detail at least, >> e.g. what's "poision" about? (I assume its to prevent such a >> "pre-cert" be verified anywhere, but then you could also mess >> with the dates.) Also, saying the precert-signing-cert has to >> be signed by "the CA cert" private key isn't quite enough. If >> you mean the same CA cert that's above the TLS server cert >> then that might not be possible (e.g. with pathLen) albeit >> that's unlikely, but there could be other reasons why that CA >> can't issue a CA cert (which the precert-signing-cert is, >> right?) > > Done. > >> (7) 3.1, p10, 2nd para: "...chain...to a trusted root..." does >> that mean that trusted root has to be the CA that issued the >> topmost cert in the submission to the log, or is any trusted >> root accepted by the log ok? ("using" the chain might not be >> considered normative.) > > I think I clarified this in the process of fixing point (6). > >> (8) 3.1, says the log can accept "not fully valid" things but >> also says that a "valid chain" is required. That needs >> clarification I think, since some would consider that a valid >> chain cannot contain e.g. an expired end-entity cert. > > This is essentially hedging against operational CA difficulties, so I > have clarified that. > >> (9) 3.1, " However, the log MUST refuse to publish >> certificates without a valid chain to a known root CA." seems >> to preclude any solution for self-signed certs or DNSSEC/DANE. >> Is that a good plan? Maybe if you make it a positive "must >> accept" then that'd avoid that problem? (If a good solution >> for SSCs or DANE spam is figured out later.) > > [response in separate email] > >> (10) 3.1, identifying a log solely on the basis of its key_id >> without any roll-over seems dumb. What if the log wants to >> roll its signature key? This would have to be fixed in a >> standards-track RFC but really could be done now and would be >> better for having being done. > > [response in separate email] > From stephen.farrell@cs.tcd.ie Tue Dec 18 14:29:37 2012 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 5875D21F86CD for ; Tue, 18 Dec 2012 14:29:37 -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 mCiXBxCfMiu2 for ; Tue, 18 Dec 2012 14:29:36 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 62D4521F86CA for ; Tue, 18 Dec 2012 14:29:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A6F38BE2F; Tue, 18 Dec 2012 22:29:14 +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 a+5buyXpuZi3; Tue, 18 Dec 2012 22:29:14 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.41.54.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0150ABE29; Tue, 18 Dec 2012 22:29:13 +0000 (GMT) Message-ID: <50D0EE39.3040108@cs.tcd.ie> Date: Tue, 18 Dec 2012 22:29:13 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03: point 12 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, 18 Dec 2012 22:29:37 -0000 On 12/18/2012 12:14 PM, Ben Laurie wrote: >> (12) 4.x - would it make sense to use .well-known/ct/ URLs or >> not? > > Not to me... > > a) .well-known is a discovery mechanism, but CT logs will not be > discovered, they'll be explicitly known. Well, ok. Maybe check this with some apps folks - they seem to care about this sometimes for reasons I never can fathom. > > b) We allow the prefix to include a path, which would > defeat .well-known. Ah, I missed that actually. Maybe an example would make it harder to skip over. S. From stephen.farrell@cs.tcd.ie Tue Dec 18 15:00:08 2012 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 4A3F01F0CE3 for ; Tue, 18 Dec 2012 15:00:08 -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 0alrxFxCtMDd for ; Tue, 18 Dec 2012 15:00: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 48FD11F0CB2 for ; Tue, 18 Dec 2012 15:00:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 63C2DBE2F for ; Tue, 18 Dec 2012 22:59: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 uxNq9zy85-+G for ; Tue, 18 Dec 2012 22:59:44 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.41.54.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 374B3BE29 for ; Tue, 18 Dec 2012 22:59:44 +0000 (GMT) Message-ID: <50D0F560.40000@cs.tcd.ie> Date: Tue, 18 Dec 2012 22:59:44 +0000 From: Stephen Farrell 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" X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [therightkey] Missing IANA considerations... 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, 18 Dec 2012 23:00:08 -0000 Hiya, One I missed entirely...you need an IANA considerations section that at least asks to register a value in the relevant registry. [1] You can ask for 182 I guess. I expect that it'll be allocated for CT but that's not certain. S. [1] http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#authorization-data-rules From stephen.farrell@cs.tcd.ie Tue Dec 18 15:03:35 2012 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 D4C5C21F8545 for ; Tue, 18 Dec 2012 15:03:35 -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 XL-4pjt2tcrQ for ; Tue, 18 Dec 2012 15:03:35 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2C90921F84FD for ; Tue, 18 Dec 2012 15:03:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 80D25BE2F; Tue, 18 Dec 2012 23:03:13 +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 s4WutcoFu5f0; Tue, 18 Dec 2012 23:03:12 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.41.54.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DE508BE29; Tue, 18 Dec 2012 23:03:12 +0000 (GMT) Message-ID: <50D0F630.80101@cs.tcd.ie> Date: Tue, 18 Dec 2012 23:03:12 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03: point 13 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, 18 Dec 2012 23:03:35 -0000 On 12/18/2012 12:19 PM, Ben Laurie wrote: >> (13) 4.x - how does CT impact on the TLS server cert used for >> these HTTPS connections? > > I presume you're afraid of some bootstrapping problem. Right. To be honest I still need to figure out that I agree there's no gotcha there. > So, let's > imagine a world in which no logs exist yet, but clients insist on CT > for all new certs. How do we get off the ground? > > Easily: the log gets a cert from a CA _without_ an embedded SCT. It > then logs it (using an internal API) to get an SCT, which it serves > using a TLS extension. Ok, so do you need to say that clients interacting with a log MUST be able to do CT and that CT SHOULD be used for such TLS sessions? S. From stephen.farrell@cs.tcd.ie Tue Dec 18 15:04:13 2012 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 D55B321F8554 for ; Tue, 18 Dec 2012 15:04:13 -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 MA4f2CakPg21 for ; Tue, 18 Dec 2012 15:04:13 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3CA21F854A for ; Tue, 18 Dec 2012 15:04:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4E5A0BE2F; Tue, 18 Dec 2012 23:03:51 +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 jo1rOlMx3Fhr; Tue, 18 Dec 2012 23:03:50 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.41.54.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 74D22BE29; Tue, 18 Dec 2012 23:03:50 +0000 (GMT) Message-ID: <50D0F656.6080403@cs.tcd.ie> Date: Tue, 18 Dec 2012 23:03:50 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03: gossip 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, 18 Dec 2012 23:04:13 -0000 On 12/18/2012 05:28 PM, Ben Laurie wrote: >> - section 5, 2nd para: gossip TBD needs to be done > > I don't think I can do that any time soon. Can I say it will be > defined in a separate spec? works for me. S. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > From stephen.farrell@cs.tcd.ie Tue Dec 18 15:11:19 2012 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 D4E6521E805A for ; Tue, 18 Dec 2012 15:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 hkzPCJpbzXG4 for ; Tue, 18 Dec 2012 15:11:19 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 343ED21E8045 for ; Tue, 18 Dec 2012 15:11:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 68D8EBE2F; Tue, 18 Dec 2012 23:10:57 +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 3xAfW8qvwSas; Tue, 18 Dec 2012 23:10:53 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.41.54.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E76F0BE29; Tue, 18 Dec 2012 23:10:52 +0000 (GMT) Message-ID: <50D0F7FC.9000905@cs.tcd.ie> Date: Tue, 18 Dec 2012 23:10:52 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03: OIDs 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, 18 Dec 2012 23:11:20 -0000 On 12/18/2012 04:51 PM, Ben Laurie wrote: >> - Where're the OIDs in 3.1 and 3.2 registered? They should be >> in the some registry I guess. > > Should they be? They're rooted on Google's OID. We have an internal > registry for those. Isn't that the point of OIDs? (i.e. that you can > generate new ones yourself) That is one of 'em. Another is that you don't roll new OIDs to mean the same thing which is where a registry can be useful. I can't recall where the PKIX OIDs can be accessed but I do recall there being a web page somewhere. Might be no hard to add these there maybe (the EKU anyway). But ok. S. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > From benl@google.com Wed Dec 19 02:33:56 2012 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 6935921F84D0 for ; Wed, 19 Dec 2012 02:33:56 -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 SBQbefOdgIDC for ; Wed, 19 Dec 2012 02:33:56 -0800 (PST) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id B7FC021F84BB for ; Wed, 19 Dec 2012 02:33:55 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id x43so843466wey.23 for ; Wed, 19 Dec 2012 02:33:54 -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=ubTEUTCKtaELNLiJZ35rokT7L+e6YADYqZCs3RZoAt4=; b=IaKbVg3Kt/tM1ed2JjUphSZESw5Kf/nlXFVyOEVl9+3DPU1a6kbs3oeXN5wOnFZLCc OcbiiMb+RH9BcRlKoH7Dp6qpkcP634OH4fVGgeJujbdRGoeAuZutXKzENU5003OTqjoy Y6uS6MKzcOQgutk2QK7YNaccOFps9vRfNp0OBZTKUpfudzPMC/YaStYmcMo72ksPIElX AJTRHcSgnJPVBD8bFzSv+2yBUmoWQ3QdU7fTin0r7cJcpSGj3En/HNv1+uUYaswy0yxH jnwpf9MdA8BZzR5BeaBr/IRoYPFvdFkg+lJfHNC6AKJiG1oObR4o+Epxw1RA0gg/6KmQ h5YA== 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=ubTEUTCKtaELNLiJZ35rokT7L+e6YADYqZCs3RZoAt4=; b=K6068f7pUBSxsinqXwA4U61PlFqBY4HQdyUgkrnYcMO62YH8S6TYDO7KpkyT6WUHR8 RF4BxVHDAfgwcHcaQjP9QVp2ln+aMwg2+lBiYiSKa4IFsF9DCsgQHDO8lYhTz3CaWz4u tQycVSe0vWUoFeGbo84KSoRWlNZVToIfVB7o/rZyC8JkeDuj9BJyeeRMGEDJFrouRbAF hIBGwNKerLfOLpv/SVj6EKsPnuk6VIzL4jsH3H0ZrxUdQc37WTs/dxA0q3e/0Qp/x+cU V7CpQvdWhQKg1gRucsYvTNPG1vDWq0DAL4YvG2U2s1wqX8MS/JA6bsgOFBqNoql46cpr EqUA== MIME-Version: 1.0 Received: by 10.194.236.68 with SMTP id us4mr10745078wjc.11.1355913234865; Wed, 19 Dec 2012 02:33:54 -0800 (PST) Received: by 10.194.51.35 with HTTP; Wed, 19 Dec 2012 02:33:54 -0800 (PST) In-Reply-To: <50D0F630.80101@cs.tcd.ie> References: <50D0F630.80101@cs.tcd.ie> Date: Wed, 19 Dec 2012 10:33:54 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkA/14oQmstYXMacDEzfssV6waOWzcrZ1KXhSsAvW4cQcKpoVgrpJ+tTFw+u7fwG/k4X2xswxHP1ersKptpnkZ03zJFQRubdPJCD1xu9NKKGF6n+vC27y9gqhUNqqKHmMELeIBI9ki84sadMu73/QjSQT1GG0gO4GGotd+gXlb9NFmtfCPnvz6xCxajdmdggCguoXaY Cc: therightkey@ietf.org Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03: point 13 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, 19 Dec 2012 10:33:56 -0000 On 18 December 2012 23:03, Stephen Farrell wrote: > > > On 12/18/2012 12:19 PM, Ben Laurie wrote: >>> (13) 4.x - how does CT impact on the TLS server cert used for >>> these HTTPS connections? >> >> I presume you're afraid of some bootstrapping problem. > > Right. To be honest I still need to figure out that I agree > there's no gotcha there. > >> So, let's >> imagine a world in which no logs exist yet, but clients insist on CT >> for all new certs. How do we get off the ground? >> >> Easily: the log gets a cert from a CA _without_ an embedded SCT. It >> then logs it (using an internal API) to get an SCT, which it serves >> using a TLS extension. > > Ok, so do you need to say that clients interacting with a log > MUST be able to do CT and that CT SHOULD be used for such TLS > sessions? No, I don't think so, I'm saying that _if_ they do CT we can still bootstrap :-) From benl@google.com Wed Dec 19 02:47:38 2012 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 77C1B21F87C7 for ; Wed, 19 Dec 2012 02:47:38 -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 uGKcBUB77DKS for ; Wed, 19 Dec 2012 02:47:36 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id A1B7221F8790 for ; Wed, 19 Dec 2012 02:47:36 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id e12so841586wge.10 for ; Wed, 19 Dec 2012 02:47:35 -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=AL6mXK8NBOdDUTIF5z1l8NMeb5Lahv+DhxC8PiRcgtU=; b=n5IKjyqQBQoCiPKS3TnMi53HpHrSvKbU/NsiacmmuDJFY7cQEnhwAOQGQAZJUFLN7Q hF7bdbgD0zUhQmoURQM8WsbjNtjmG6jcR4pkPyYAFDe/5c2GaaxdfUuAC0n/rnypgdGD gw0wxZgaXcWcZW7kyEt0YO15dokUlo5ZN6bGzuzqIao0b6PQ830Zaa0/eVZ0xNGT9dvt HTdE1s+b/KzE+fw1m04FAIxdZw5uwDtjcSyNZLlfm2EpTWFj33kJjykBDto3glzQdpeQ na8jHYxd/Zj2yUTybVIvwm3kIbPmWlff4W3muwtMq9tyZ77BJTmEgyKHEXDLhsGNbbTc 9kvQ== 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=AL6mXK8NBOdDUTIF5z1l8NMeb5Lahv+DhxC8PiRcgtU=; b=mW2SPfzZkyShDMcIZZRcp+SMJiJqfU7pIAyKBPlME4N5yQ9HfaWBCPCJ11OOjetj7N oLUNPsel9UMbWY5lDsAj61fXoaZco53wieNK6obOLa5NnPRZKJmvZoRZZtk6rhsvY3MO 0Lfz3CwPZFl12LzLp6P2jxhaQOOk1AI97OeEbNh6fd/PFvnSMSzLXUsZwG2Q6h96Y0Ti bnI7WQ+BogRLD0rUHDJ8fM+UGMFGyAgvY7CFBMoT6hDDYW2Wau9W/5FK4CgM0yl6vrMD CF+BzviBxOD03NutADqeJb15lC2vbxlj+nP0JIcZLeevzcyjGtqVCYkLVvgTJhfZEWvN 2xog== MIME-Version: 1.0 Received: by 10.180.109.195 with SMTP id hu3mr3155267wib.31.1355914055737; Wed, 19 Dec 2012 02:47:35 -0800 (PST) Received: by 10.194.51.35 with HTTP; Wed, 19 Dec 2012 02:47:35 -0800 (PST) In-Reply-To: <50D0EB62.60704@cs.tcd.ie> References: <50D0EB62.60704@cs.tcd.ie> Date: Wed, 19 Dec 2012 10:47:35 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmkRsHrlHpDiughRFIAlLHB0VF+FtE2Vu7o5+bL0vJqnkQ/8VGaXicO2S9QVNSkd9Eru+1NnfgpyQptxSaqGAeppObEtZQ1AGKN02EXJUDNz5M9fQ1RIxda+MpEWuPbv/B8AqO6boq4yl3X2/hqlrAaOAoh50JrRn/lbpdHOWdO6erO5O09dP00hxucu2aX1worh87d Cc: therightkey@ietf.org Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03: point 10 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, 19 Dec 2012 10:47:38 -0000 On 18 December 2012 22:17, Stephen Farrell wrote: > > Hiya, > > On 12/17/2012 06:19 PM, Ben Laurie wrote: >>> (10) 3.1, identifying a log solely on the basis of its key_id >>> without any roll-over seems dumb. What if the log wants to >>> roll its signature key? This would have to be fixed in a >>> standards-track RFC but really could be done now and would be >>> better for having being done. >> >> Our view was that a new key is effectively a new log and so roll-over >> is achieved by ... starting a new log. If it is done because of key >> compromise, then the old log can no longer be trusted. > > Hmm. That seems wrong to me in some cases. > > If signing with RSA then I might want to roll a new, longer > key at some point in future, but without having to consider > the log as changing. Similarly, I might want to have both > RSA and ECC based signatures if different clients support > different algs. A log might also want to upgrade some > crypto h/w in a way that doesn't allow for migration of > the same private key. Maybe. The only way to do this that makes much sense to me would be to allow the log's "master key" to delegate to subkeys (rather like DNSSEC's KSKs and ZSKs). In which case the ID would still be derived from the key. > Maybe this and other similar things might be usefully > handled in a section called "stuff we might change as we > move to standards-track" or something? Sounds like a good idea. From benl@google.com Wed Dec 19 04:17:53 2012 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 2EA2621F8AD8 for ; Wed, 19 Dec 2012 04:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.527 X-Spam-Level: X-Spam-Status: No, score=-101.527 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_52=0.6, MANGLED_LIST=2.3, 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 edsniz1d-p9P for ; Wed, 19 Dec 2012 04:17:52 -0800 (PST) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5A121F8A9C for ; Wed, 19 Dec 2012 04:17:51 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id u54so930701wey.13 for ; Wed, 19 Dec 2012 04:17:51 -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=5+MsgpkDD0f5vWeqTE5DV/p1cgHiD6XrCIlMPZF/M/g=; b=oWMKNs/frkYPgcQAr5egu0UpuAenldpDupsR03AmZHdviRXD/nhm/j5OTu6s6W531n AO0kHIiVwe8shYUtapmcH8TvWp7AwFfXv8dF71Tjh4QysUl82igtH8hl8au7MJ90/W0x A0rgu6jwcBjxlKPD9LMSDLSAW1bKNDiAjz0WriNChs/4l9fOFVjX1BRg+N1W9qVdYqe9 SWXWJRdLPnOOhiAhH0D9KCmUlvTOQzwO41RdIJY2UiR1tIFvhZGDQEmxOLZJL17wRNj7 uw++M/umMOzStKqBzXkTMqX/0tfxByr1EwnpmWYp6VJ4Ccp8xRZH8JepP2CK4PpWAm8a 8Xqg== 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=5+MsgpkDD0f5vWeqTE5DV/p1cgHiD6XrCIlMPZF/M/g=; b=Ede2LrpkHmVSZqE1/Ltfo6somBniyePpB1QFgbYV6H2Zrd7T3mAzo1h64lzxPb9qjP zIscgrZCJBG4j2eQ8dZKH8OBtU5IIcvkfHHuwHacBd4rYvOXmuqXmkJDzvUIXNiwvy8R 1rid6s8ItBimfuANTLBAWYGf/HsZ66XwfqRmfMCsq4U01w5TI/zAWjkjzupxNl/+xuQM JpTGWEc1BV23xiz17aGa8UesHNNevqsQLP/RFPEgp07OXaxx8paL9bCAeeX3VeJ4KB99 prYUlQfwK/sfLr6GRCqnpZXNpcExthRC1NsLSwjaCsS0E6ypsueZ3m/7qcOuZllt9mYW WllA== MIME-Version: 1.0 Received: by 10.180.100.197 with SMTP id fa5mr3659493wib.32.1355919471081; Wed, 19 Dec 2012 04:17:51 -0800 (PST) Received: by 10.194.51.35 with HTTP; Wed, 19 Dec 2012 04:17:50 -0800 (PST) In-Reply-To: <50CE7B39.8040703@cs.tcd.ie> References: <50CE7B39.8040703@cs.tcd.ie> Date: Wed, 19 Dec 2012 12:17:50 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkUUEwiwtpLfN3HQbQS4g76HtGwYdLTxzFRQcSx2PRKKAau1dXyFPn66cl6Wwdjz3ZZxd6QmlV/mHLtmlBlDAZGnyvRdTJut/xXrGKbqDrBcOLkg3iwJVoYpt+T610LO4zU6GHup0wNmwhTKwF9qfqlvyDNbaNumTIHD7VeBMbn8bquaShMg8mhpHoaBQt/M56UIbEJ Cc: Emilia Kasper , "therightkey@ietf.org" , Adam Langley Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03 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, 19 Dec 2012 12:17:53 -0000 On 17 December 2012 01:54, Stephen Farrell wrote: > needs fixing, but no thought: > ----------------------------- > > - abstract: the RFC editor doesn't want references in > abstracts, just use the RFC number and then put the [] into > the body of the text 1st time you refer to each RFC. That > might mean you need to repeat stuff from the abstract. > (Apparent reason for RFC editor pref is that sometimes people > just see the abstract and couldn't follow the reference, feel > free to argue with the RFC editor on this about some other > document:-) Done. > - Where're the OIDs in 3.1 and 3.2 registered? They should be > in the some registry I guess. > > - 3.1, shameless self-promotion - draft-farrell-decade-ni has > a way to hash public keys:-) Yes, filling in the TODO is > needed. Am I allowed to refer to I-Ds? > > - STH needs to be expanded on 1st use Done. > > - section 5, 2nd para: gossip TBD needs to be done > > - ref [1] results in a 404 Fixed. > random comments: > ---------------- > > - abstract: "public end-entity" might not be the best term, > maybe the word "web server" is needed since that's the real > (inital) concern? I added seb servers as an example. > - abstract: "accompanied by" seems wrong, "for which an > accompanying" would seem better since that log-sig might be > found in or out of band. No, it is always in band. > - abstract: s/will be valid indefinitely/are good or bad > forever and have no "expiry"/ ? I just said "do not expire". > - intro, para1: s/solve the problem/mitigate the problem/ > better not to over-claim Good point. > - intro, para1: what is an "untrusted log"? This is explained in the last paragraph. > - intro, para1: s/added/are added/ Fixed. > - intro, para1: s/public TLS/public TLS server/ or are you > adderssing client certs too? I don't care assuming it works > but you ought be clear. The protocol would require tweaking for client certs, so I have said server. > - intro, para 2: ought "required" be 2119 terminology here? > Its ok if it is repeated later, but if its not repeated later > then it ought IMO be a 2119 term here. It is repeated later. It seems mean to put normative requirements into an intro! > - intro, para 2: I'd avoid the word "prove" since mistakes can > be made (e.g. a clock might be off) I am slightly at a loss for a better word here! > - intro, last para: I think you need to be clear about > trusting the log. Clients do need to trust it to be available > at least, and if they process a signature then they need to > trust it to sign properly and for whatever signature-validity > controls. I have tried to clarify this. > - 2.1: "MTH({d(0)}) = SHA-256(0 || d(0))." The first input to > the hash is ASCII '0' (0x30) or a 1-octet number 0 (0x00) or > something else? You need to be clear on all those. Be good to > say why you chose a 0 for the first but a 1 for others. Done. > - 2.1: would it be worth adding "if n is a power of 2 then > k=n/2" ? Someone might miss "smaller than" when coding, though > I'm not sure their code could work at all in that case, or > could it? It would be an infinite loop :-) > - 2.1.4: the NIST reference should be a proper reference Done. > - 3, 2nd para: saying clients MUST reject without defining > client is odd and esp when doing more than audit with CT is > optional. The servers MUST there is also odd. I think you want > to say "conforming to this spec" in both cases at minimum. Surely that's implicit in all normative language? Even standards track documents don't impose anything on me if I don't conform to them. I have, however, made it clear that I mean TLS clients and servers. > - 3, last para, is the MUST there correct use of 2119 > language? Formally its not an interop thing but it is a > security thing. While I have no issue with that, some other > ADs do (mistakenly IMO, but nonetheless it has to be dealt > with;-). Reading and closely following the definitions in 2119 > might help with that. If, OTOH you want to argue that that's > silly then I'm with you on that. I would argue that: a) It is an interop thing because you cannot audit a log that fails to conform to that requirement, and b) RFC 2119 says "In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions)". Failure to include the cert in the log causes harm. > > - 3.1, 1st para: a list of roots does not "attribute each > logged cert to its issuer" I'm not sure what you think is wrong with this, but assuming you mean the terrible grammar, I've changed it to " In order to enable attribution of each logged certificate to its issuer..." > - 3.1, not all roots need to make self-signed certs for their > root public keys, even though all probably do. Might be better > for the language to recognise that. Done. > - 3.1, 1st para, s/shall/SHALL/ and maybe s/should/might > usefully/ in the same sentence. Done. > - 3.1, what's the use-case for a log accepting a cert that has > expired? (just curious) People use expired certificates, either by accident or design, and users can (currently) choose to accept them - therefore we should allow audit of expired certificates. > - 3.1, the log doesn't "publish" certs does it? Yes? > - 3.1, why are log entries called "certificate entries"? I can't find where we say that. > - 3.1, why "0..." for X509ChainEntry and "1.." for > PrecertChainEntry? You probably ought say and that might need > to change if you change the "same CA issued both EE cert and > precert-signing-cert" rule. I can't parse this! > - 3.2, it might be a pain to have the string > SignedCertificateTimestampList mean two things i.e. both a > type and the name of an OCTET STRING field. But they're actually the same thing, just in two different contexts. > - 3.2, p13, 1st para, again you say *the* CA. Changed to "a". > - 3.4, 64 bits for tree size? seems a lot but ok. Is there any > way to use a large size there as a DoS by someone on anyone? 32 bits seemed risky given a few million certs per year at current rates. > I've not thought about it, but has anyone? Issuing very large number of certs would DoS logs and monitors. We imagine that logs would have a discussion with CAs that started to do this. From stephen.farrell@cs.tcd.ie Wed Dec 19 04:47:57 2012 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 8D7A821F8AD8 for ; Wed, 19 Dec 2012 04:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 qMYZuENQN-AC for ; Wed, 19 Dec 2012 04:47:56 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6314221F8AC4 for ; Wed, 19 Dec 2012 04:47:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 58932BE29; Wed, 19 Dec 2012 12:47:34 +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 c8tSywJmXH9h; Wed, 19 Dec 2012 12:47:33 +0000 (GMT) Received: from [IPv6:2001:770:10:203:2c02:cb9b:fa9d:a3bb] (unknown [IPv6:2001:770:10:203:2c02:cb9b:fa9d:a3bb]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 771C0BE20; Wed, 19 Dec 2012 12:47:33 +0000 (GMT) Message-ID: <50D1B765.3000803@cs.tcd.ie> Date: Wed, 19 Dec 2012 12:47:33 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: <50CE7B39.8040703@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Emilia Kasper , "therightkey@ietf.org" , Adam Langley Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03 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, 19 Dec 2012 12:47:57 -0000 Just the bits where there's something to say: On 12/19/2012 12:17 PM, Ben Laurie wrote: > On 17 December 2012 01:54, Stephen Farrell wrote: > >> - Where're the OIDs in 3.1 and 3.2 registered? They should be >> in the some registry I guess. >> >> - 3.1, shameless self-promotion - draft-farrell-decade-ni has >> a way to hash public keys:-) Yes, filling in the TODO is >> needed. > > Am I allowed to refer to I-Ds? You could. However, my I-D is gonna be stuck for a while since it has a normative dependency on http/1.1 drafts so unfortunately you're probably better to just copy the bit of text you need from there, if you want to use it. If you do that you could copy what you need and add an informative reference and it could all be fixed up later without slowing down your RFC. Or you could refer to DANE [rfc6698] assuming you hash the SPKI which both my draft and DANE do. >> - intro, para 2: I'd avoid the word "prove" since mistakes can >> be made (e.g. a clock might be off) > > I am slightly at a loss for a better word here! s/prove/provide strong evidence / maybe >> - 3.1, why "0..." for X509ChainEntry and "1.." for >> PrecertChainEntry? You probably ought say and that might need >> to change if you change the "same CA issued both EE cert and >> precert-signing-cert" rule. > > I can't parse this! Can't say I blame you, wonder who typed that silly comment;-) It was this bit that triggered the comment: struct { ASN.1Cert leaf_certificate; ASN.1Cert certificate_chain<0..2^24-1>; } X509ChainEntry; struct { ASN.1Cert tbs_certificate; ASN.1Cert precertificate_chain<1..2^24-1>; } PrecertChainEntry; The certificate_chain can be empty but the precertificate_chain cannot. That's right given the current spec, but maybe non-obvious. The 2nd part of the comment was that if you do need to change the precertificate_chain idea (if the issuing CA cannot create a precert issuer under itself e.g. because of a pathLenConstraint) then the PrecertChainEntry syntax might also have to change. I dunno if that'd be a real problem now, or only later, or is just theoretical but I'd say there will be CAs that can issue TLS server certs but that cannot issue a sub-ca cert for precertificates. Cheers, S. From rob.stradling@comodo.com Wed Dec 19 05:02:35 2012 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 8156E21F8A0A for ; Wed, 19 Dec 2012 05:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ZBOytoFLRx0v for ; Wed, 19 Dec 2012 05:02:35 -0800 (PST) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9B96B21F894D for ; Wed, 19 Dec 2012 05:02:34 -0800 (PST) Received: (qmail 27294 invoked from network); 19 Dec 2012 13:02:32 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 19 Dec 2012 13:02:32 -0000 Received: (qmail 7919 invoked by uid 1000); 19 Dec 2012 13:02:32 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 19 Dec 2012 13:02:32 +0000 Message-ID: <50D1BAE8.5040600@comodo.com> Date: Wed, 19 Dec 2012 13:02:32 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: <50CE7B39.8040703@cs.tcd.ie> <50D1B765.3000803@cs.tcd.ie> In-Reply-To: <50D1B765.3000803@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Emilia Kasper , "therightkey@ietf.org" , Adam Langley , Stephen Farrell Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03 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, 19 Dec 2012 13:02:35 -0000 On 19/12/12 12:47, Stephen Farrell wrote: > The 2nd part of the comment was that if you do need > to change the precertificate_chain idea (if the > issuing CA cannot create a precert issuer under itself > e.g. because of a pathLenConstraint) then the > PrecertChainEntry syntax might also have to change. > I dunno if that'd be a real problem now, or only > later, or is just theoretical but I'd say there > will be CAs that can issue TLS server certs but > that cannot issue a sub-ca cert for precertificates. Ben, you said to me privately a couple of months ago that you would be happy to support the option of having each pre-cert signed directly by the same root/intermediate CA that will sign the final cert. Are you still happy to support this option? IMHO, having to include a Precertificate Signing Certificate in the precert chain represents unnecessary hassle. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From benl@google.com Wed Dec 19 05:41:46 2012 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 E80E421F8B26 for ; Wed, 19 Dec 2012 05:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_52=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 3MuiBwno7gtx for ; Wed, 19 Dec 2012 05:41:46 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3964721F888F for ; Wed, 19 Dec 2012 05:41:46 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so3623571wib.1 for ; Wed, 19 Dec 2012 05:41:45 -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=sBCrNONFi7AkhnmRQqMaSucQltPV88BLVYiY0xMoOZk=; b=Gc4p+2na7x1JQP7lfyIrtvwUiaho+1ZJX817dwiIeqcLNxFRiJ7fwGIz7jfOVl7JyP jbN2PKm66yDtOx3HK/3Pa1UdE5c38AYK0wvrrWiTgvqcnmr/Xf6W5XL0YB5YaZK4G/vE /rhQ/ShsoKNdVufTvYH6swcF7u0kSrcMfnwYOod2E7r7EEuwEMXgBDWLSHhX5q2xjrqL nTHA+vTfmb3cV/OJ3vViJGc/ca3uOh7u2Y2Hw+XG5bx9Fpk4ybu+DUk+4ArUQnvSedj6 HTvxRNefo7Vwqvdd52oXJqDKPcWjRS6IJ1GhYhEDcK+ua6ke71pdHfzRCrAFYPU9bZVy Acrg== 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=sBCrNONFi7AkhnmRQqMaSucQltPV88BLVYiY0xMoOZk=; b=HNAAVyY3LIUKdYwHCca5HEwdhJ2p/ZHQ4xQtInEH+BuutcnR1nwf+WzR7J/HS5a/RB AqkMIA3W2aA5DERuUeNbQnxsLWiQfrx782aze4dhbx19ITsc0UW+kzbU8qeTeffAOpzQ B1DAsiL7aoURnBFXyANBQUsa1iWnzzrztfkTE6jqvMsWuzyh5cTcOXxH1m2cwpQxFsLD PIyg34gZhO/ssk/KjpEM8kN0GbN7m7/nJAT4ay6z7q/6DycKDh2H2fWToi2Lii5qRxAN 6PyXFidZzmlUvScRytYaOAUUEgtzyF+qhOfYDBEPZSIR3pVCW3AeJYwuFPghiOmY91kX sXNg== MIME-Version: 1.0 Received: by 10.180.93.133 with SMTP id cu5mr4111221wib.32.1355924504785; Wed, 19 Dec 2012 05:41:44 -0800 (PST) Received: by 10.194.51.35 with HTTP; Wed, 19 Dec 2012 05:41:44 -0800 (PST) In-Reply-To: <50D1B765.3000803@cs.tcd.ie> References: <50CE7B39.8040703@cs.tcd.ie> <50D1B765.3000803@cs.tcd.ie> Date: Wed, 19 Dec 2012 13:41:44 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk84RgHCG1pDUpd1w/joIfbFODce8Xw8e0KfyIUA3iBBJ+ZVdkIxzQuo7eu8SU14UunpYsqDah4k4+w3TlXmuR9vJS2AwLcGZJJI0zKtiZdXrd58FrHAEM4EQAckWW75cdFS37h8C0T/HOEXG67foVFCuCrcyB8cvx19owaF5aANo/HIPU+GpOwFjIx7t89WkOa6h4z Cc: Emilia Kasper , "therightkey@ietf.org" , Adam Langley Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03 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, 19 Dec 2012 13:41:47 -0000 On 19 December 2012 12:47, Stephen Farrell wrote: > > Just the bits where there's something to say: > > On 12/19/2012 12:17 PM, Ben Laurie wrote: >> On 17 December 2012 01:54, Stephen Farrell wrote: >> >>> - Where're the OIDs in 3.1 and 3.2 registered? They should be >>> in the some registry I guess. >>> >>> - 3.1, shameless self-promotion - draft-farrell-decade-ni has >>> a way to hash public keys:-) Yes, filling in the TODO is >>> needed. >> >> Am I allowed to refer to I-Ds? > > You could. However, my I-D is gonna be stuck for a while > since it has a normative dependency on http/1.1 drafts so > unfortunately you're probably better to just copy the bit > of text you need from there, if you want to use it. If > you do that you could copy what you need and add an > informative reference and it could all be fixed up later > without slowing down your RFC. > > Or you could refer to DANE [rfc6698] assuming you hash > the SPKI which both my draft and DANE do. For a single sentence it seems simpler to just say it again! >>> - intro, para 2: I'd avoid the word "prove" since mistakes can >>> be made (e.g. a clock might be off) >> >> I am slightly at a loss for a better word here! > > s/prove/provide strong evidence / maybe OK. > >>> - 3.1, why "0..." for X509ChainEntry and "1.." for >>> PrecertChainEntry? You probably ought say and that might need >>> to change if you change the "same CA issued both EE cert and >>> precert-signing-cert" rule. >> >> I can't parse this! > > Can't say I blame you, wonder who typed that silly comment;-) > > It was this bit that triggered the comment: > > struct { > ASN.1Cert leaf_certificate; > ASN.1Cert certificate_chain<0..2^24-1>; > } X509ChainEntry; > > struct { > ASN.1Cert tbs_certificate; > ASN.1Cert precertificate_chain<1..2^24-1>; > } PrecertChainEntry; > > > The certificate_chain can be empty but the > precertificate_chain cannot. That's right given the > current spec, but maybe non-obvious. > > The 2nd part of the comment was that if you do need > to change the precertificate_chain idea (if the > issuing CA cannot create a precert issuer under itself > e.g. because of a pathLenConstraint) then the > PrecertChainEntry syntax might also have to change. > I dunno if that'd be a real problem now, or only > later, or is just theoretical but I'd say there > will be CAs that can issue TLS server certs but > that cannot issue a sub-ca cert for precertificates. Well, in response to Rob's comment I'm going to have to change this anyway :-) From benl@google.com Wed Dec 19 05:43:18 2012 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 9075B21F8B27 for ; Wed, 19 Dec 2012 05:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.661 X-Spam-Level: X-Spam-Status: No, score=-102.661 tagged_above=-999 required=5 tests=[AWL=0.316, 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 ge5Co9GD82YV for ; Wed, 19 Dec 2012 05:43:14 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8A26421F888F for ; Wed, 19 Dec 2012 05:43:14 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hn14so3543911wib.4 for ; Wed, 19 Dec 2012 05:43:13 -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=0CK0GvZE0pBeLNZrgEgu5X7NaqAFrGH92snMTdIt6ug=; b=FHMFMQ55JNo8118Fil7bsxrSrN6eIJ+dxCRovpyqNkBDrYR+K1k0ok3ltPU/FyAEEg 5xSet1ls8/rYS2aip/0yLosAzgA+i/K+Y8Xj4C2xdcMzWx880nfqmRvBkXJmdSh3H0+w fb/Wmq7LqmGKouyALDs6y0IQlOAq7X2JawKCT2Ou3/32pZyHGXNnR0ReVXRnTTVV4lUj wvMTB32IRVxm2TDssUXkYdwQ6owkkKGgma+wqGb0L2b0+08YX9LHWDUFL6urkVSCrN3H oP6iXzpBLlErsFbPPMNjEJ0EIX+ExqmyMLsQAdyN7MLVWhc+qqHllH5ZmXRYnojbJqUh c7ng== 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=0CK0GvZE0pBeLNZrgEgu5X7NaqAFrGH92snMTdIt6ug=; b=ExPs2BF+JjcDh0AQ3qBcjJGBmxssV0H2KYz/BCscv8fd8iXwJ63UQeKPNooIla2sND mhekCtq7fAre5B6pu4gAwuyHXCXZML/SrzhlDVEVDRM86w+5dYtSsXBaph8fCOQ7On1/ 3EXtK080FAenD37n4mGBTaubPl8k1GbNiBXlvgwjE3f2eeK/Ly1EKgTRrovlEhnPBhLV TGWdREx83VKV5ou6FbkHWeoRz9nLsh/8CEnw+BNiXAn3I0CDZ1kDllXR6q/Smm5qU+J7 ozkB93yq1QkaNF1GoYBSgqq3kHPq40RsOUKK+9wfrH1jnX3SATCL044y52iOSglWHurf jZwA== MIME-Version: 1.0 Received: by 10.194.236.68 with SMTP id us4mr11837740wjc.11.1355924593501; Wed, 19 Dec 2012 05:43:13 -0800 (PST) Received: by 10.194.51.35 with HTTP; Wed, 19 Dec 2012 05:43:13 -0800 (PST) In-Reply-To: <50D1BAE8.5040600@comodo.com> References: <50CE7B39.8040703@cs.tcd.ie> <50D1B765.3000803@cs.tcd.ie> <50D1BAE8.5040600@comodo.com> Date: Wed, 19 Dec 2012 13:43:13 +0000 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkU/iwELr8GNqBrhNM6BWufbbim8aDyM5RGmfBe13cS2Z/W1p16NZFv43+f7pv6Sx7APCXP5I3FHd0XDJtxfAskabxjtJ8VHWV+bMPrJ6vXbwB/mNABNEnd3dr6aNGc2L+rHy53EKV78l1zeMggrAlUulgiptlMxfDkx8Y3QfjmtgoC5t/kvP+bNZ3+pNJqQ/PhzRrO Cc: Emilia Kasper , "therightkey@ietf.org" , Adam Langley , Stephen Farrell Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03 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, 19 Dec 2012 13:43:18 -0000 On 19 December 2012 13:02, Rob Stradling wrote: > On 19/12/12 12:47, Stephen Farrell wrote: > > >> The 2nd part of the comment was that if you do need >> to change the precertificate_chain idea (if the >> issuing CA cannot create a precert issuer under itself >> e.g. because of a pathLenConstraint) then the >> PrecertChainEntry syntax might also have to change. >> I dunno if that'd be a real problem now, or only >> later, or is just theoretical but I'd say there >> will be CAs that can issue TLS server certs but >> that cannot issue a sub-ca cert for precertificates. > > > Ben, you said to me privately a couple of months ago that you would be happy > to support the option of having each pre-cert signed directly by the same > root/intermediate CA that will sign the final cert. > > Are you still happy to support this option? Absolutely. All we care about is a strong link to the issuer - we don't care how that's achieved! The current convoluted method was, I think, in response to some CAs' concern that they didn't want to issue a usable cert as an intermediate step. > > IMHO, having to include a Precertificate Signing Certificate in the precert > chain represents unnecessary hassle. > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > From rob.stradling@comodo.com Wed Dec 19 05:56:24 2012 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 B77E121F876E for ; Wed, 19 Dec 2012 05:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 4ex40bTdNj0Y for ; Wed, 19 Dec 2012 05:56:24 -0800 (PST) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id BA78021F8780 for ; Wed, 19 Dec 2012 05:56:23 -0800 (PST) Received: (qmail 11713 invoked from network); 19 Dec 2012 13:56:22 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 19 Dec 2012 13:56:22 -0000 Received: (qmail 24256 invoked by uid 1000); 19 Dec 2012 13:56:22 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 19 Dec 2012 13:56:22 +0000 Message-ID: <50D1C786.8060800@comodo.com> Date: Wed, 19 Dec 2012 13:56:22 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: <50CE7B39.8040703@cs.tcd.ie> <50D1B765.3000803@cs.tcd.ie> <50D1BAE8.5040600@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Emilia Kasper , "therightkey@ietf.org" , Adam Langley , Stephen Farrell Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03 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, 19 Dec 2012 13:56:24 -0000 On 19/12/12 13:43, Ben Laurie wrote: >> Ben, you said to me privately a couple of months ago that you would be happy >> to support the option of having each pre-cert signed directly by the same >> root/intermediate CA that will sign the final cert. >> >> Are you still happy to support this option? > > Absolutely. Great. :-) > All we care about is a strong link to the issuer - we > don't care how that's achieved! The current convoluted method was, I > think, in response to some CAs' concern that they didn't want to issue > a usable cert as an intermediate step. Are there any alternative ways to make the precerts unusable, even if issued directly by the same root/intermediate CA that will sign the final cert? How about requiring each precert to have a Critical extension with an OID that no existing software will recognize and which CT-compliant software will be required to reject ? >> IMHO, having to include a Precertificate Signing Certificate in the precert >> chain represents unnecessary hassle. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From benl@google.com Wed Dec 19 05:58:50 2012 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 0286121F857A for ; Wed, 19 Dec 2012 05:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.69 X-Spam-Level: X-Spam-Status: No, score=-102.69 tagged_above=-999 required=5 tests=[AWL=0.287, 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 MChB8sJ72mHR for ; Wed, 19 Dec 2012 05:58:49 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5E221F8505 for ; Wed, 19 Dec 2012 05:58:49 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm6so3566060wib.3 for ; Wed, 19 Dec 2012 05:58:48 -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=rDojY7/DhUfH2H/PhxOvzqkL4QOUXc63WNPlHGFEo7I=; b=jJ6pmwjoQom06WZUd/LpYSHL32aLH2vq3xPq7AIh161YbzgrlqXiVNZRPvyMyT1oDB xNmEA/UBAWNKK9Ck3WTnUQ8cmV+fTBMg5oNOI83iyRQAaWRc9Q3Ljn8+U1OmB8kMHVGq Uy+RM4ol4SAfCWahl3q8q45ygEgeRPm/NLmIUkh6/AUkAQ0KfRK8qr/OrTfM2RIW/isd Bj7l1kzC5rGIZfsQ4fhB/59Gf2SDACMvHwz06FDUYbGTUPnM0LGZj3hCqA0VRSKBsY8I 953+gAPNwRmsZmTnjNl8+qc2eMX8mBd9L8BsioeEoeI3LSL1Q8BObGjjXG7ZUhpw3Z/R c5ZQ== 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=rDojY7/DhUfH2H/PhxOvzqkL4QOUXc63WNPlHGFEo7I=; b=SmCax7ndSyTfst2EfrNcrO8wYT5CHajVU0ZFbXcdT0BBN+TkTzLSIgJlSez5GASNGv Q1pMUwedgouLxGecUFxgVrP/fyn6gJtDtyFm0lkcAP/uqwZx6aadNL48rqhgAfsnz/CT KuBQqq7oKo4vsBlrH9FpY2U8CoiZ1hYzM9MTVsqBi1f+IbY3xWsL2tZ2Z02+8+6sm6eP B0AAsMi5kjCgAWFYwHVpDPvaygMViIpO5wpb8raMvyw62w8Z71fRiQO9ak76J8/S1Cwy LDlz+Zq2IO0aHfGtBJHJCODd9Y8nqJaVJLMvf26aokJxhiOoknjIVDvjWizCMcIx+l56 vDpA== MIME-Version: 1.0 Received: by 10.180.75.135 with SMTP id c7mr11879617wiw.10.1355925527985; Wed, 19 Dec 2012 05:58:47 -0800 (PST) Received: by 10.194.51.35 with HTTP; Wed, 19 Dec 2012 05:58:47 -0800 (PST) In-Reply-To: <50D1C786.8060800@comodo.com> References: <50CE7B39.8040703@cs.tcd.ie> <50D1B765.3000803@cs.tcd.ie> <50D1BAE8.5040600@comodo.com> <50D1C786.8060800@comodo.com> Date: Wed, 19 Dec 2012 13:58:47 +0000 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQngRYiRCtcI70F9kvajKBwDylqE4UZA+YNVW24BeX3IQNF3CjKeo6XSq/ToNB4SmMg8Y/fvlWOPyoU0ITnRBxRCqAPzQgNPwXrdzynLMm+3NtVjFZ+6w2mxnk3JncvDTDyZFtst1ghEz2nPzttqxyoq/OuNdAI4AVVii/yWN5/y30+N+xOhXdbR2vAJJ0cW9R9HQc1r Cc: Emilia Kasper , "therightkey@ietf.org" , Adam Langley , Stephen Farrell Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03 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, 19 Dec 2012 13:58:50 -0000 On 19 December 2012 13:56, Rob Stradling wrote: > On 19/12/12 13:43, Ben Laurie wrote: > > >>> Ben, you said to me privately a couple of months ago that you would be >>> happy >>> to support the option of having each pre-cert signed directly by the same >>> root/intermediate CA that will sign the final cert. >>> >>> Are you still happy to support this option? >> >> >> Absolutely. > > > Great. :-) We are more than happy to support _any_ option that meets the requirements of CT and is convenient for CAs. >> All we care about is a strong link to the issuer - we >> don't care how that's achieved! The current convoluted method was, I >> think, in response to some CAs' concern that they didn't want to issue >> a usable cert as an intermediate step. > > > Are there any alternative ways to make the precerts unusable, even if issued > directly by the same root/intermediate CA that will sign the final cert?\ Yes - there's already belt & braces going on there - the precert includes a critical extension that is otherwise unused, and so should prevent processing of it by any X509v3 client. The intermediate was just an extra precaution. > How about requiring each precert to have a Critical extension with an OID > that no existing software will recognize and which CT-compliant software > will be required to reject ? You have read the I-D, right? :-) > > >>> IMHO, having to include a Precertificate Signing Certificate in the >>> precert >>> chain represents unnecessary hassle. > > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > From rob.stradling@comodo.com Wed Dec 19 06:07:27 2012 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 742C821F85BA for ; Wed, 19 Dec 2012 06:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 hB0zzbthe-f1 for ; Wed, 19 Dec 2012 06:07:26 -0800 (PST) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9F71121F857C for ; Wed, 19 Dec 2012 06:07:24 -0800 (PST) Received: (qmail 15739 invoked from network); 19 Dec 2012 14:07:23 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 19 Dec 2012 14:07:23 -0000 Received: (qmail 5657 invoked by uid 1000); 19 Dec 2012 14:07:23 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 19 Dec 2012 14:07:23 +0000 Message-ID: <50D1CA1A.2090406@comodo.com> Date: Wed, 19 Dec 2012 14:07:22 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: <50CE7B39.8040703@cs.tcd.ie> <50D1B765.3000803@cs.tcd.ie> <50D1BAE8.5040600@comodo.com> <50D1C786.8060800@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Emilia Kasper , "therightkey@ietf.org" , Adam Langley , Stephen Farrell Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-03 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, 19 Dec 2012 14:07:27 -0000 On 19/12/12 13:58, Ben Laurie wrote: >> Are there any alternative ways to make the precerts unusable, even if issued >> directly by the same root/intermediate CA that will sign the final cert?\ > > Yes - there's already belt & braces going on there - the precert > includes a critical extension that is otherwise unused, and so should > prevent processing of it by any X509v3 client. The intermediate was > just an extra precaution. > >> How about requiring each precert to have a Critical extension with an OID >> that no existing software will recognize and which CT-compliant software >> will be required to reject ? > > You have read the I-D, right? :-) TBH, I haven't yet read -03 properly. :$ The critical poison extension wasn't in -02. I had been expecting you to remove the Precertificate Signing Certificate concept and add the critical poison extension concept at the same time. ;-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From benl@google.com Wed Dec 19 13:16:39 2012 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 7486921F877B for ; Wed, 19 Dec 2012 13:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.832 X-Spam-Level: X-Spam-Status: No, score=-102.832 tagged_above=-999 required=5 tests=[AWL=0.145, 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 ozsakjc2ppJq for ; Wed, 19 Dec 2012 13:16:39 -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 9B48521F8781 for ; Wed, 19 Dec 2012 13:16:38 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id 15so1135397wgd.4 for ; Wed, 19 Dec 2012 13:16:37 -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 :content-type; bh=OJy9UB6lmQd1l3S177JHmxNl/S8BzdufY9mq8p/gVqw=; b=kvVJhRGxEMwAg6knVRjEtXeoGPJRztWgbLHvZTPlaIwTukZT4HuVET+03DzSGeeVgL Wf4ZrTrA/c+JTLMR/aOH3a51R/E4Nc5QUfNnUg+w6oWZlZVguKwdI0N0rpX/cIJmqu+G OkKXNilWGqdsIA2GgKbISuTjxY3csZdJ038xzWaxRX4/yQ183irdyquVSb3j8w1qZc+Z tTsMpfeDKMlvZzPcOWjHX7KASqoIMi4QZNM6Zj1Z2jkEDG6ys2BoNi1Mqyrc4llxeEol GJpoAvRBfpRI/DwOb3b3rcXPFgD7m7N0fSNtb+DJuJeTeQqxdgp0O2sqDYrt//LfE/8Z IVmQ== 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 :content-type:x-gm-message-state; bh=OJy9UB6lmQd1l3S177JHmxNl/S8BzdufY9mq8p/gVqw=; b=Bqa8BehsX2vVWetOAcIKCptZBFphjHGhgc3BzkxwTgq9dD1oFwnIDeqPBW4mcqTNTg Pt7bgSEgbzCbw4qZNbV5B9DxduCeAq94ee8I0bhnM2Z9CrN4FjFG/atYVQuHmK9C2pM6 /dV+mn6a1C6GrrCenKEjFQ9XuqxfwlfhUuTt6sChPmZpZZT9McSomxhbLM/xktP2rwVQ MMwuZmssiMc601sEuEUKq99Sd8fUp9OImWJ70zh524fbdcXOHBWvK/evHKC3Hykh7osF qrP3ci+Ac1uKx3twGPgNtVJUDECcf1j9mgS4NilW++sqtQj+ppACOM2O9NQGfCqgxmMi vpqA== MIME-Version: 1.0 Received: by 10.180.83.169 with SMTP id r9mr13535600wiy.10.1355951797644; Wed, 19 Dec 2012 13:16:37 -0800 (PST) Received: by 10.194.51.35 with HTTP; Wed, 19 Dec 2012 13:16:37 -0800 (PST) In-Reply-To: <20121219211603.15506.12874.idtracker@ietfa.amsl.com> References: <20121219211603.15506.12874.idtracker@ietfa.amsl.com> Date: Wed, 19 Dec 2012 21:16:37 +0000 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnnzT/cEB1OgfdlWCaUBOx6IKa8YAmEaRq/KuzsEhkeLogg55C0mw41XK9rcKY8WVpI2kTQULKbxmFQ26bcPY26zen0BNOiNrNuR8jO9P9/bLOg8v3LB0FWmyLq6nSP3jvrxd82/at7y4lLnxsrmDAKSWydUkB/5gdOTXzM/kcQ7IOkYKl+7uVLmCLogrTiuhTPEoWr Subject: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-04.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: Wed, 19 Dec 2012 21:16:39 -0000 ---------- Forwarded message ---------- From: Date: 19 December 2012 21:16 Subject: New Version Notification for draft-laurie-pki-sunlight-04.txt To: benl@google.com Cc: ekasper@google.com, agl@google.com A new version of I-D, draft-laurie-pki-sunlight-04.txt has been successfully submitted by Ben Laurie and posted to the IETF repository. Filename: draft-laurie-pki-sunlight Revision: 04 Title: Certificate Transparency Creation date: 2012-12-19 WG ID: Individual Submission Number of pages: 28 URL: http://www.ietf.org/internet-drafts/draft-laurie-pki-sunlight-04.txt Status: http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight Htmlized: http://tools.ietf.org/html/draft-laurie-pki-sunlight-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-laurie-pki-sunlight-04 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 IETF Secretariat From stephen.farrell@cs.tcd.ie Wed Dec 19 14:21:59 2012 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 38F1621F8530 for ; Wed, 19 Dec 2012 14:21:59 -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 j2DYIP41FZEb for ; Wed, 19 Dec 2012 14:21:56 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9418521F84ED for ; Wed, 19 Dec 2012 14:21:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E1D77BE25; Wed, 19 Dec 2012 22:21:33 +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 AjmR6zknHcMP; Wed, 19 Dec 2012 22:21:32 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.44.75.44]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A6355BE35; Wed, 19 Dec 2012 22:21:32 +0000 (GMT) Message-ID: <50D23DEC.9020308@cs.tcd.ie> Date: Wed, 19 Dec 2012 22:21:32 +0000 From: Stephen Farrell 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 References: <20121219211603.15506.12874.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ben Laurie Subject: Re: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-04.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: Wed, 19 Dec 2012 22:21:59 -0000 Ben tells me he reckons this is ready to do. I plan to give it a read and all being well start IETF LC in the next few days. (Probably for 5 weeks given the holidays.) So now's a very good time to read this and comment if you care. S. On 12/19/2012 09:16 PM, Ben Laurie wrote: > ---------- Forwarded message ---------- > From: > Date: 19 December 2012 21:16 > Subject: New Version Notification for draft-laurie-pki-sunlight-04.txt > To: benl@google.com > Cc: ekasper@google.com, agl@google.com > > > > A new version of I-D, draft-laurie-pki-sunlight-04.txt > has been successfully submitted by Ben Laurie and posted to the > IETF repository. > > Filename: draft-laurie-pki-sunlight > Revision: 04 > Title: Certificate Transparency > Creation date: 2012-12-19 > WG ID: Individual Submission > Number of pages: 28 > URL: > http://www.ietf.org/internet-drafts/draft-laurie-pki-sunlight-04.txt > Status: http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight > Htmlized: http://tools.ietf.org/html/draft-laurie-pki-sunlight-04 > Diff: http://www.ietf.org/rfcdiff?url2=draft-laurie-pki-sunlight-04 > > 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 IETF Secretariat > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > From tom@ritter.vg Wed Dec 19 19:38:19 2012 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 D6D9621F851F for ; Wed, 19 Dec 2012 19:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 jeV-IQf8b33I for ; Wed, 19 Dec 2012 19:38:19 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9E4721F851E for ; Wed, 19 Dec 2012 19:38:18 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so3282499vbb.3 for ; Wed, 19 Dec 2012 19:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Q4KQxXnQBmz15faIUUL3L1hV4wF9SWH4zdVe31f31oI=; b=c2yeCDYC2WG/MYnFARhQE2PuRClqzv55MbqMIDMnNltHH1Jsm1oywFye69ewgXz1Bo i1hrRkO3+ua073xruilyzOv3QOVwHw/lAGSBn0hKqjcSrIOQ6oADnI64wXYxmXDxX2Pw OO04Fhd/vtHTCo/hrAWijQ6jgDWM/HMy2ugxI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=Q4KQxXnQBmz15faIUUL3L1hV4wF9SWH4zdVe31f31oI=; b=D8lGhGoEP5kqHikc40v4yfTNVS4X1yvHREVicrZFVHjLqzJ2sCbSJzvm9TCa51zkV7 2JFGhw6HWk+LEDtWEtZdqsHdSbAIAUwGqlF40zvw8TRaA77JVx0fKXfRQFseS+6wTZcd uWV2ZRD6CmrRv8KL8jC0vsqU+09LFaO+OviwI6TLdlGuXq54KrslCrh26Y3dgX3jM3LD m8k2+RzdZu4KZbqUFjV1bXzImCRelH/XkjWwk6J8ie3rBelfCvDqjXPHtRBL4cLNI39M C14/xgu522iblQzmJpxgx1OuMsmWvh2lEekK1BR0HDeeiq7ULOUNyhABTavXvjo5B8Nh Hvrw== Received: by 10.220.150.210 with SMTP id z18mr12204855vcv.2.1355974698026; Wed, 19 Dec 2012 19:38:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.255.104 with HTTP; Wed, 19 Dec 2012 19:37:56 -0800 (PST) In-Reply-To: <50D23DEC.9020308@cs.tcd.ie> References: <20121219211603.15506.12874.idtracker@ietfa.amsl.com> <50D23DEC.9020308@cs.tcd.ie> From: Tom Ritter Date: Wed, 19 Dec 2012 22:37:56 -0500 Message-ID: To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlict2ATJwGuvXm49stzKHhjiqzyJQvnrHzkc131LrCuqkRONdVr/ns7AGvNuLamDKrAkyg Subject: Re: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-04.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, 20 Dec 2012 03:38:19 -0000 Spelling / Grammar: "Authorizationn" on page 22 RE: DANE/Self-Signed Certs [Note: this effectively excludes self-signed and DANE-based certificates until some mechanism to control spam for those certificates is found - the authors welcome suggestions]. Suggestion: Logs MAY accept certificates without a complete chain if querying the Common Name in the certificate indicates the certificate is deployed on a webserver or included in DNS records. Logs MAY set policies around subdomains and paths to maintain availability. If what you're trying to avoid is bloating the Merkle Tree, then reaching out for a TLS handshake or DNS records could work. Even if they were spoofed/middled/whatever - the log isn't certifying they're valid, only that they're public. In the future, someone could submit a DNS signature chain and bypass the need for the log to reach out, but that'd require defining new APIs and structures, and that's too much. -tom On 19 December 2012 17:21, Stephen Farrell wrote: > > > Ben tells me he reckons this is ready to do. I plan to give it > a read and all being well start IETF LC in the next few days. > (Probably for 5 weeks given the holidays.) > > So now's a very good time to read this and comment if you care. > > S. > > On 12/19/2012 09:16 PM, Ben Laurie wrote: > > ---------- Forwarded message ---------- > > From: > > Date: 19 December 2012 21:16 > > Subject: New Version Notification for draft-laurie-pki-sunlight-04.txt > > To: benl@google.com > > Cc: ekasper@google.com, agl@google.com > > > > > > > > A new version of I-D, draft-laurie-pki-sunlight-04.txt > > has been successfully submitted by Ben Laurie and posted to the > > IETF repository. > > > > Filename: draft-laurie-pki-sunlight > > Revision: 04 > > Title: Certificate Transparency > > Creation date: 2012-12-19 > > WG ID: Individual Submission > > Number of pages: 28 > > URL: > > http://www.ietf.org/internet-drafts/draft-laurie-pki-sunlight-04.txt > > Status: http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight > > Htmlized: http://tools.ietf.org/html/draft-laurie-pki-sunlight-04 > > Diff: http://www.ietf.org/rfcdiff?url2=draft-laurie-pki-sunlight-04 > > > > 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 IETF Secretariat > > _______________________________________________ > > therightkey mailing list > > therightkey@ietf.org > > https://www.ietf.org/mailman/listinfo/therightkey > > > > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From benl@google.com Thu Dec 20 01:47:04 2012 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 80F0B21F84C9 for ; Thu, 20 Dec 2012 01:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.714 X-Spam-Level: X-Spam-Status: No, score=-102.714 tagged_above=-999 required=5 tests=[AWL=0.263, 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 i6jPg4JSeW+O for ; Thu, 20 Dec 2012 01:47:03 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8936621F870C for ; Thu, 20 Dec 2012 01:47:03 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so3472604vbb.31 for ; Thu, 20 Dec 2012 01:47:02 -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=nIwyffmWzyAK/fEU9Ov3zgHKdHRkvsrrvtE7UykfDc0=; b=pah5JDxwaB2rGqFe1tt1752C4C0S+lGJwWXeqtdjNqYWQn35MXw9YE1t3ELrcXJwlG OLmOb/pIEXHv20CcYsbzgf5TpqEZctYZy9X2Eecd8qWJ7o0vVl4yUl7GempDiSndNeSy Qy/ZwR/FLm17LZk4nTGVDuqTRjibG9LLyaYK5d1m8GEGXsH7QkM0kG9UTbPR1ZzcxIFr U9SSyRAS+JS52FLjvWnZqEnqFFklovgQMsd9xEBDcqBEVHdrdTgWDqY86WjUEu8fEbFJ nBT+s1IS1q0QtU5tbF14tYTRgmsReE6ArAtavS3DjpNHkh01xDk+x14TITovc8OEvDBt tC5Q== 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=nIwyffmWzyAK/fEU9Ov3zgHKdHRkvsrrvtE7UykfDc0=; b=AkB5rS1wuF3Co4Hsg1RB3xCyofaTzhKJkt4gaPKgbRwvXNS7B/uA1zwJzREVY27tsr ug3LmltOPKuVAkOIh9JMWeo+bIXP1mRK+r4+3V81YmLavNq7ppZFNKxeKMAQc0lp8C7c XtWnUFcYWVayVMU+xMp598OT5zNYszI30OlfWrH1v5/WShTCBdcHqZUlJmQE6UjcZnwD xu8xcTGz5Bw5QsVhT4xw+tdvNZJ/qWXGcglaQtP/5AMU7B8Z/nFNiUUgX3i6e8tsPftJ K70iqy7xM7j63EEAB8AreucbdoC4nQSiRWFjO55SPjgkUA12UN1TiS/2mDWEZq8jVl5w 6F4A== MIME-Version: 1.0 Received: by 10.58.186.226 with SMTP id fn2mr13787288vec.33.1355996822735; Thu, 20 Dec 2012 01:47:02 -0800 (PST) Received: by 10.220.38.137 with HTTP; Thu, 20 Dec 2012 01:47:02 -0800 (PST) In-Reply-To: References: <20121219211603.15506.12874.idtracker@ietfa.amsl.com> <50D23DEC.9020308@cs.tcd.ie> Date: Thu, 20 Dec 2012 09:47:02 +0000 Message-ID: From: Ben Laurie To: Tom Ritter Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm20vVj2rFXXAtaACNW/1U+lYBfZl/34jYyYfD2BKSDUqzMCc4znl1zLnq7oZbz0zSlQcv3lEfnyACuYHdGtnPcUzU7iAsZvqGELgAbUfoW/ACHXl0DCd13o966HQBAV8ofeEAdhEO50EkXnTaP0Y6WxTi4iDa6tLdVzJouqGnLAgIudQm+IUqPHhkkn3iih/qeLU3n Cc: therightkey@ietf.org Subject: Re: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-04.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, 20 Dec 2012 09:47:04 -0000 On 20 December 2012 03:37, Tom Ritter wrote: > Spelling / Grammar: "Authorizationn" on page 22 Thanks. > RE: DANE/Self-Signed Certs > > [Note: this effectively excludes self-signed and DANE-based > certificates until some mechanism to control spam for those > certificates is found - the authors welcome suggestions]. > > > Suggestion: > > Logs MAY accept certificates without a complete chain if querying > the Common Name in the certificate indicates the certificate is > deployed on a webserver or included in DNS records. Logs MAY > set policies around subdomains and paths to maintain availability. > > If what you're trying to avoid is bloating the Merkle Tree, then > reaching out for a TLS handshake or DNS records could work. Even if > they were spoofed/middled/whatever - the log isn't certifying they're > valid, only that they're public. In the future, someone could submit > a DNS signature chain and bypass the need for the log to reach out, > but that'd require defining new APIs and structures, and that's too > much. I kinda like this suggestion, but it doesn't seem like it would actually be much of a barrier to spam. Of course, if we make it a MAY it would be no skin off my nose - but I doubt Google will implement the MAY. > > -tom > > > > On 19 December 2012 17:21, Stephen Farrell wrote: >> >> >> Ben tells me he reckons this is ready to do. I plan to give it >> a read and all being well start IETF LC in the next few days. >> (Probably for 5 weeks given the holidays.) >> >> So now's a very good time to read this and comment if you care. >> >> S. >> >> On 12/19/2012 09:16 PM, Ben Laurie wrote: >> > ---------- Forwarded message ---------- >> > From: >> > Date: 19 December 2012 21:16 >> > Subject: New Version Notification for draft-laurie-pki-sunlight-04.txt >> > To: benl@google.com >> > Cc: ekasper@google.com, agl@google.com >> > >> > >> > >> > A new version of I-D, draft-laurie-pki-sunlight-04.txt >> > has been successfully submitted by Ben Laurie and posted to the >> > IETF repository. >> > >> > Filename: draft-laurie-pki-sunlight >> > Revision: 04 >> > Title: Certificate Transparency >> > Creation date: 2012-12-19 >> > WG ID: Individual Submission >> > Number of pages: 28 >> > URL: >> > http://www.ietf.org/internet-drafts/draft-laurie-pki-sunlight-04.txt >> > Status: http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight >> > Htmlized: http://tools.ietf.org/html/draft-laurie-pki-sunlight-04 >> > Diff: http://www.ietf.org/rfcdiff?url2=draft-laurie-pki-sunlight-04 >> > >> > 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 IETF Secretariat >> > _______________________________________________ >> > therightkey mailing list >> > therightkey@ietf.org >> > https://www.ietf.org/mailman/listinfo/therightkey >> > >> > >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From stephen.farrell@cs.tcd.ie Thu Dec 20 01:50:46 2012 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 5172521F86F6 for ; Thu, 20 Dec 2012 01:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.766 X-Spam-Level: X-Spam-Status: No, score=-101.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, SARE_URI_EQUALS=1.666, 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 IDRJWa9CClNF for ; Thu, 20 Dec 2012 01:50:45 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9C64421F86CD for ; Thu, 20 Dec 2012 01:50:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A26D8BE38; Thu, 20 Dec 2012 09:50: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 U5XhDAebmvO4; Thu, 20 Dec 2012 09:50:21 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.44.68.76]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 00E19BE1E; Thu, 20 Dec 2012 09:50:20 +0000 (GMT) Message-ID: <50D2DF5C.6040605@cs.tcd.ie> Date: Thu, 20 Dec 2012 09:50:20 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: [therightkey] version -04 things to fix before/during IETF LC 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, 20 Dec 2012 09:50:46 -0000 Hiya, - The "extensions [TBD]" line on p17 needs fixing before IETF LC since that'd break/prevent interop. - The [DSS] reference seems outdated, there's a version of fips 186 from 2009, I think you need to fix the reference text since the 1994 version is probably the wrong one at which to point. Best done now but can be done after IETF LC. - The poison extension: you say it has ASN.1 NULL data, but extensions have OCTET STRING syntax. Do you mean an ASN.1 NULL (0x05 0x00) is encoded as the value of the OCTET STRING or that the OCTET STRING has zero length? This can be fixed after IETF LC, or now, if you know what you're code does, but needs fixing. - Having a thing with basicConstraints.cA==false issue precerts seems wrong, but that may be better discussed during IETF LC so I'm not requesting a change now. So only the first need hold up IETF LC but the next two might be worth fixing since a -05 is needed anyway. Not sure about the last one, probably best to review during IETF LC. Cheers, S. From benl@google.com Thu Dec 20 03:20:11 2012 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 2A43B21F86EB for ; Thu, 20 Dec 2012 03:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_URI_EQUALS=1.666, 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 TF2l0gT5FijO for ; Thu, 20 Dec 2012 03:20:10 -0800 (PST) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7A65B21F8715 for ; Thu, 20 Dec 2012 03:20:10 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id fr13so3543787vbb.37 for ; Thu, 20 Dec 2012 03:20:09 -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=M0lFMSxDXtED3tcMCgvcl7xrI137wwT7N8loHJ6HvqY=; b=V/3pANgQWfaQKWtv2EtlI8Xw9V/xwBM/D/WW/pgWvaDNMfzRznXvhJ66QVml7Vvsau URN5eclUKXiGvtLRHn7EsDqkl4ROxdbfiPquyS8zuv10KmLdWmrpszcSogRm+M08CGCF HhZriiEcZT3r8DRAq195yrPqx6i/hkB/fxv7lL7pETSRkMxFrAq8532NnwQCILtHRcHw f+yKvBzG9JKxHpduoDJ8xOZ/YUXvEQXayGfmHEE31bHCmIT8q2cIoP2d7/birlPDuORq pasDOZ8bxGcL/jjIyV6NnhQhty/P9NXVAz+QFWCJ6nnFC2Af8vx7lyDyIgw35nwgFhpJ zTqg== 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=M0lFMSxDXtED3tcMCgvcl7xrI137wwT7N8loHJ6HvqY=; b=ChZqE0wgVpBIIIxnHePeEXIqGUHjLUsKnl1tIjzMbWNr0y1QA0cyrGGvjAzwPoaoFV mWo4NKVMEeS6qptcKg1BIX9TU0CtK/feidZKv6L9HRh1ZwSSGN4lDf2c06Xl2zzd4Ugj L1IpN8C0f8T04dOpOViQpTwjrYIjErQqJHcQBBZQZQhRX0LaQw0QH7gf+JGLTxXpcWL9 z+sNHlFMivYWlUEgFf/cjL2eVDkI7cXL5OU8WjeW4TfHf3n9ezkrKGP5sH8RfE6h0bil DxriXROq95bGBBtFHhxqNDwGISvuYOLChA4vpJgYXvyWIME6yWmT6OSsHCGjlGM4vi3c e6tA== MIME-Version: 1.0 Received: by 10.52.70.232 with SMTP id p8mr12315091vdu.0.1356002409838; Thu, 20 Dec 2012 03:20:09 -0800 (PST) Received: by 10.220.38.137 with HTTP; Thu, 20 Dec 2012 03:20:09 -0800 (PST) In-Reply-To: <50D2DF5C.6040605@cs.tcd.ie> References: <50D2DF5C.6040605@cs.tcd.ie> Date: Thu, 20 Dec 2012 11:20:09 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlI/GixBVfbKQx8NU7kmkIqIuzWEffHY0bKiM4W+5m0Zd4j/8yMuYHs9no/Gm1HTRGjFTk5Lr45NX4ZAHZC34M2W9/4zHMBv3dy0FInDvMBtqk9U2gRWxGD10Jc1Pn3CTF9aOROq6bIZ1ch9PRSQ/nEjBCl98/0x98X1EkvXe/MWlrRsiOlKRiEeJpZeg6qpDsTOAjn Cc: "therightkey@ietf.org" Subject: Re: [therightkey] version -04 things to fix before/during IETF LC 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, 20 Dec 2012 11:20:11 -0000 On 20 December 2012 09:50, Stephen Farrell wrote: > - Having a thing with basicConstraints.cA==false issue precerts > seems wrong, but that may be better discussed during IETF LC so > I'm not requesting a change now. This was deliberate to avoid the precertificate being a valid certificate, as requested by CAs. From stephen.farrell@cs.tcd.ie Thu Dec 20 03:26:24 2012 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 4EC1421F87AD for ; Thu, 20 Dec 2012 03:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.627 X-Spam-Level: X-Spam-Status: No, score=-101.627 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, SARE_URI_EQUALS=1.666, 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 eJJjY4ZyXZEi for ; Thu, 20 Dec 2012 03:26:23 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 63EF021F87A6 for ; Thu, 20 Dec 2012 03:26:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 648A6BE3B; Thu, 20 Dec 2012 11:26:01 +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 3B9heY98wJ51; Thu, 20 Dec 2012 11:26:00 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.44.68.76]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4C656BE39; Thu, 20 Dec 2012 11:26:00 +0000 (GMT) Message-ID: <50D2F5C8.4040807@cs.tcd.ie> Date: Thu, 20 Dec 2012 11:26:00 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: <50D2DF5C.6040605@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] version -04 things to fix before/during IETF LC 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, 20 Dec 2012 11:26:24 -0000 On 12/20/2012 11:20 AM, Ben Laurie wrote: > On 20 December 2012 09:50, Stephen Farrell wrote: >> - Having a thing with basicConstraints.cA==false issue precerts >> seems wrong, but that may be better discussed during IETF LC so >> I'm not requesting a change now. > > This was deliberate to avoid the precertificate being a > certificate, as requested by CAs. Well it avoids the precert issuer being a CA. The precert is still syntactically a cert. And you need to use the precert issuer private key to make a precert. Some s/w might refuse if it saw that cert for the precert issuer that has .cA==false. No reason why you can't make it happen in principle, but I've no idea if needing s/w like that'd be a real barrier or not. S. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > From rob.stradling@comodo.com Thu Dec 20 03:28:27 2012 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 235B821F886F for ; Thu, 20 Dec 2012 03:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URI_EQUALS=1.666] 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 3hMi9a+JyJzm for ; Thu, 20 Dec 2012 03:28:26 -0800 (PST) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC1521F871E for ; Thu, 20 Dec 2012 03:28:22 -0800 (PST) Received: (qmail 17066 invoked from network); 20 Dec 2012 11:28:21 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 20 Dec 2012 11:28:21 -0000 Received: (qmail 19713 invoked by uid 1000); 20 Dec 2012 11:28:21 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 20 Dec 2012 11:28:21 +0000 Message-ID: <50D2F655.3040306@comodo.com> Date: Thu, 20 Dec 2012 11:28:21 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: <50D2DF5C.6040605@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] version -04 things to fix before/during IETF LC 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, 20 Dec 2012 11:28:27 -0000 On 20/12/12 11:20, Ben Laurie wrote: > On 20 December 2012 09:50, Stephen Farrell wrote: >> - Having a thing with basicConstraints.cA==false issue precerts >> seems wrong, but that may be better discussed during IETF LC so >> I'm not requesting a change now. > > This was deliberate to avoid the precertificate being a valid > certificate, as requested by CAs. Ben, doesn't the new poison critical extension requirement mean that this Basic Constraints hack is no longer needed? The poison critical extension means that a precert cannot be used as a cert. Is that not invalid enough?!? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From benl@google.com Thu Dec 20 03:38:08 2012 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 ADEE921F85DC for ; Thu, 20 Dec 2012 03:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.859 X-Spam-Level: X-Spam-Status: No, score=-101.859 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_URI_EQUALS=1.666, 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 rvMw8eGOJtgO for ; Thu, 20 Dec 2012 03:38:08 -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 B2B7621F85DA for ; Thu, 20 Dec 2012 03:38:07 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hm11so4222308wib.8 for ; Thu, 20 Dec 2012 03:38:06 -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=b5o9fyNKgLa1al/jl6br3JCLp/yySTV464qgMzHl650=; b=mQZ32r0Q5ZQGWS+xLxyG2VEf+VeT+PnfCT0g3zsSPASSmW3APbmajbjMCwCz68PyPS yLb02ttNnBh2e4NJmTG2+Tkme0k8KTigX6q01NNBONWkHtyM3mqWoX8SjvoT858/kPYX k6ISRV5d5tlpcEsOIJJ0oNinHQ2jQi9N2Tl0KeHAn463/xcSQI26KvzUTjAIUCI03tO4 w7gF77y/cnYeaaWeY7c1vrungxwI1Hb+eBarm4XvC/ff1X/WAQC6nXVp+ZBzTDSJF/Rl tfZj+Uyf9/s17jf7BVrsVIHWDy3FXX3IU+FnCU1UxoqAeBr4mPhfAKIUx+dwT0QIF9Wd Kvwg== 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=b5o9fyNKgLa1al/jl6br3JCLp/yySTV464qgMzHl650=; b=W4SR+Roeu+qI5fxHKwCDipVhJH1rRuJCe2aFHXyq8nohaFA53NaAJOqeDF7y7s5Qfs l8uCb1YjUTCO4xSGfdT4UHsWYKQ79693bMaQ2psUPzaCi4q/IH01i2eTZKbneWiHUeuN eDwWxAZziwbprKzX9EcUptRo1nB+v/2sbbaVPVpJUOCqKyiXOOHZF0W1vQfGomTR7gBN DT+AGPk0JCFqnG/8JLk1YlIYx/+V7p8/TTB2CTFEtsKSxi6UclFaixAb9c5mkzl5RPSK O5Mulvodq893KKYglFRuMThfxVRSQAINynaWwJlpTiCN/pkXwOXG8pwQLPJsduax9rhU Tc3A== MIME-Version: 1.0 Received: by 10.180.109.195 with SMTP id hu3mr9142056wib.31.1356003486571; Thu, 20 Dec 2012 03:38:06 -0800 (PST) Received: by 10.194.51.35 with HTTP; Thu, 20 Dec 2012 03:38:06 -0800 (PST) In-Reply-To: <50D2F5C8.4040807@cs.tcd.ie> References: <50D2DF5C.6040605@cs.tcd.ie> <50D2F5C8.4040807@cs.tcd.ie> Date: Thu, 20 Dec 2012 11:38:06 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkpg1fVc4k2c0jqXc3aByvlWARyEwZsm/qqDCzHBfQZYABMhRhzlIBiDpggODBl+h8/f+PmMk3yP9dQl/v3lThA6QFMyu87bvvJGCPcpH/WGLZKiRSExQlOkPCkdq8sBXVYkpeQmI8x6TNUi0EIsex78gOxKuh2EB+uHNR5bZ+ocgRBp1u39MKGGrEzLa8HoaJL0zPI Cc: "therightkey@ietf.org" Subject: Re: [therightkey] version -04 things to fix before/during IETF LC 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, 20 Dec 2012 11:38:08 -0000 On 20 December 2012 11:26, Stephen Farrell wrote: > > > On 12/20/2012 11:20 AM, Ben Laurie wrote: >> On 20 December 2012 09:50, Stephen Farrell wrote: >>> - Having a thing with basicConstraints.cA==false issue precerts >>> seems wrong, but that may be better discussed during IETF LC so >>> I'm not requesting a change now. >> >> This was deliberate to avoid the precertificate being a >> certificate, as requested by CAs. > > Well it avoids the precert issuer being a CA. The precert is > still syntactically a cert. And you need to use the precert > issuer private key to make a precert. Some s/w might refuse > if it saw that cert for the precert issuer that has .cA==false. I missed out the word "valid", sorry. And you are correct that it might be a problem for software. Emilia and I have already debated removing it - how about I may it a MAY? > > No reason why you can't make it happen in principle, but > I've no idea if needing s/w like that'd be a real barrier > or not. > > S. > >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey >> >> From benl@google.com Thu Dec 20 03:38:48 2012 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 0D80821F850B for ; Thu, 20 Dec 2012 03:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.823 X-Spam-Level: X-Spam-Status: No, score=-101.823 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_URI_EQUALS=1.666, 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 s2BVLvc10DNa for ; Thu, 20 Dec 2012 03:38:47 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7D59121F84EE for ; Thu, 20 Dec 2012 03:38:46 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id hn14so1889362wib.3 for ; Thu, 20 Dec 2012 03:38:45 -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=6hdngkrnR6t1o3wKrMXfrVKia2huNolyUCRwvGQ9pm0=; b=BHfGh7lYzB7dRmxFQyvUSps7w5VD24u0llto5hFDrDoLsUq7d7xTjwA/b0VyOnzA9d zvFYieU27mI8ymsBGsxjX8Nu92mgR/C5BPUVUPHgZnOv4bZxajiFveKxNGlZBLheOLzK 4JD8KJ87mkWwGzZsnANzL5xBbvuAYRYCF6zWdChf/IW1bVhXW1H4DtXzQnhoS0lsr9lS QX80HWUJQo2Z/fOcDrABuE2q5RyXWaL/cEFcxk8XbVkxnQL2lxnn2L6w36I6JrvKlXpe Zcyy5vp1d3WTG63lBL2WTJ07gOXfI31S3Fr/XaW+sWALQVpWEfUSOSUxrbDOBildqXsh qsUg== 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=6hdngkrnR6t1o3wKrMXfrVKia2huNolyUCRwvGQ9pm0=; b=joIzaJqZKfSO3n+nUL+mbBGm2gwwxyxb0gyimto/IWIUkptmYQPTshRXLR+khs+CsC BaGyA4GGZRXa+2MnAsuIGimKfBkzHllJLy6CO36SvgK3JGNR3gUWUQGz2gWWuUhyhdnK k3yZeP7VXnKncm8+7UznWT4DrKitRE7cSoVN8H1N+ewv5Fayz4DYszgmOBDSqcL/WBLO abHSUp9eT/CfuN15YIqajNftfV1WVKuMbkMdbMxlwpvaiMBUVJgnCexdDowz8uPXEk8d WlqxUg6xyMk9/4KvCLI6hAnHanh+8FKK8IM5h9C1C0d5vmq7ium4LFdMqi4qjx2IdjQ3 1fIw== MIME-Version: 1.0 Received: by 10.180.83.169 with SMTP id r9mr16457614wiy.10.1356003525542; Thu, 20 Dec 2012 03:38:45 -0800 (PST) Received: by 10.194.51.35 with HTTP; Thu, 20 Dec 2012 03:38:45 -0800 (PST) In-Reply-To: <50D2F655.3040306@comodo.com> References: <50D2DF5C.6040605@cs.tcd.ie> <50D2F655.3040306@comodo.com> Date: Thu, 20 Dec 2012 11:38:45 +0000 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnomHNAhKzJMr+/VhF0/LF/Sy+2kzKucp825HLlEPCs/crPHCwiNZJvNapnQ3NCxyZMcpFVbx/yDuujGZf7BmJWJQ9Ii3YaBDd5Zam+cUumfGllDr9wR2Y03GH2FvY/Dy1JvJrUD+sWrzk7QT7aHcMy/6BQ206FTQUw3z9G0xVAf/8zDaJKKLrUIMYTDFbH4DIIo/W6 Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] version -04 things to fix before/during IETF LC 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, 20 Dec 2012 11:38:48 -0000 On 20 December 2012 11:28, Rob Stradling wrote: > On 20/12/12 11:20, Ben Laurie wrote: >> >> On 20 December 2012 09:50, Stephen Farrell >> wrote: >>> >>> - Having a thing with basicConstraints.cA==false issue precerts >>> seems wrong, but that may be better discussed during IETF LC so >>> I'm not requesting a change now. >> >> >> This was deliberate to avoid the precertificate being a valid >> certificate, as requested by CAs. > > > Ben, doesn't the new poison critical extension requirement mean that this > Basic Constraints hack is no longer needed? > > The poison critical extension means that a precert cannot be used as a cert. > Is that not invalid enough?!? Probably. From benl@google.com Thu Dec 20 03:39:50 2012 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 8295021F87FA for ; Thu, 20 Dec 2012 03:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.312 X-Spam-Level: X-Spam-Status: No, score=-100.312 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, SARE_URI_EQUALS=1.666, 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 0zEixyXRg4Vo for ; Thu, 20 Dec 2012 03:39:50 -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 DB38321F87F9 for ; Thu, 20 Dec 2012 03:39:49 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq7so1086197wib.5 for ; Thu, 20 Dec 2012 03:39:49 -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=EnxxH30OrqHmOr7FQzvsFCcEpoD0pIeBVDpW//mb7cw=; b=a50c0zFG0c2jl8ISdBbd2w16Q89r1VMvmQq8DprcuShTsIzP/8JR3Yza7LufUKhmL1 aR1jkI5XHSe56N+oYKgY0kxYsdiimRGMQL6ezq6bJAWVddG6XA6fpMSjuAsP95L9p4WE C0Q7CI35zsnhe5w47bmMB7ObqkVGUKJyxO2caMJI2R/g7CMnqdME+bBXh7V19Lx+f16Q 7fdZcHxsQ8x0acsR/u+Bw86eOgOqQL6hWIKK4bwk9YyHkB0BGdNt+0nObcjwZuBlr+8p Yr2Hy38tiCBrh5AcFmzAZBW6wmKlwB3gY7zaBrw/TgPI1p5hHx//cEYALMYPva2U3FYP JY6Q== 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=EnxxH30OrqHmOr7FQzvsFCcEpoD0pIeBVDpW//mb7cw=; b=cvdFouqb0iacWd5r39+HyIDgWjexp873to+U3N3N5sZPf1pA9Y0NQpIrY4XEE3tUaS HRGfkrGuERJZ7BBW19seaGAaCoyoRoMoJzG5qZpuby8Gnrp7xv4YbRX6YL85eRcQxBtn ++r9mHyGsi99o+jb3PM/rZuNYu/jdkfJRfXwwkNOjsdoGN9lGQGya+mOY2FOHfdLHAXp 5SP8O0m9TQRg7DEyv1PbROh3KG4nTLzZnX/iuG7XX4VIBOJxfGQ9wp5M4vEGT3IUAl0D UhAO0KLi6QcFsCcpfKCWrVwUtVpoVby/4jwTJRqoIVMw6OONwOfoWlPS2Rayu/K18nZ5 iN+A== MIME-Version: 1.0 Received: by 10.180.107.67 with SMTP id ha3mr9150515wib.31.1356003588909; Thu, 20 Dec 2012 03:39:48 -0800 (PST) Received: by 10.194.51.35 with HTTP; Thu, 20 Dec 2012 03:39:48 -0800 (PST) In-Reply-To: References: <50D2DF5C.6040605@cs.tcd.ie> <50D2F655.3040306@comodo.com> Date: Thu, 20 Dec 2012 11:39:48 +0000 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlzmUKlz56JAyhvXsEzrYqf4z5tIXNPdNb14M5+7O9zjCiDzETwALiMMNmKYyc5r0ljuLlU86h3LXfr1hPX+XQmheu1p5g4F4Icc2KYevmLAVcJeSaNXOGFvOOVNglcggDAOzeKFTbLTI/N63Inlai6XyFHoE7WZZPjkNwSvVdscmyYDamJUBknvmEwy9OZWI+xQ2y0 Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] version -04 things to fix before/during IETF LC 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, 20 Dec 2012 11:39:50 -0000 On 20 December 2012 11:38, Ben Laurie wrote: > On 20 December 2012 11:28, Rob Stradling wrote: >> On 20/12/12 11:20, Ben Laurie wrote: >>> >>> On 20 December 2012 09:50, Stephen Farrell >>> wrote: >>>> >>>> - Having a thing with basicConstraints.cA==false issue precerts >>>> seems wrong, but that may be better discussed during IETF LC so >>>> I'm not requesting a change now. >>> >>> >>> This was deliberate to avoid the precertificate being a valid >>> certificate, as requested by CAs. >> >> >> Ben, doesn't the new poison critical extension requirement mean that this >> Basic Constraints hack is no longer needed? >> >> The poison critical extension means that a precert cannot be used as a cert. >> Is that not invalid enough?!? > > Probably. I've removed it. From benl@google.com Thu Dec 20 03:41:27 2012 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 457E421F8A6E for ; Thu, 20 Dec 2012 03:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.845 X-Spam-Level: X-Spam-Status: No, score=-102.845 tagged_above=-999 required=5 tests=[AWL=0.132, 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 aJVc4uaKRpd8 for ; Thu, 20 Dec 2012 03:41:26 -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 5F24221F88C0 for ; Thu, 20 Dec 2012 03:41:26 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id dt10so1459087wgb.27 for ; Thu, 20 Dec 2012 03:41:25 -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=aSzBBJ/bFui9uRJrPPtgHSysLHmkXrYF8gVboCEqbhQ=; b=oFIR9cF+MlQMJsboYMhMAFqKKXVNX0OZtfZKy3P//4vA4Gpe+gbuXcPkJDX9m1es1d XD56fm/ovGyaelR9viXqEP6RWFHaddD+DbAOP0eKjDkuqNecMd41Yaf4TXwoFXyKUB9a SbAh/kzHT/bZNCR2N96ZNRF6w9RReNuSP6/Qb4yclK6GAbj5uEWaTuLq7/48S38E3Drx jJFjRVoT6ydXGw3q1/e2ivZu82r3afY+tFREOBV/PYwYzikr5/UCVMF8DafXbSP50C4F tMaYsiQ7Ld4JyEX52KziRCsECW+pSjYzpdXSwH+moBjB1PX9S9UV0+j7n+MvQfOEBHo8 82hg== 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=aSzBBJ/bFui9uRJrPPtgHSysLHmkXrYF8gVboCEqbhQ=; b=Uqxlr2+GcRKRlhqkNjYZl8Ggx4AjFnC8bHl0+BTSFMVnRdP4H7rB+rRYhxKTvV1I3n MFojumt3F/R673Q3PDQ1GYA6xzpPXhgBEOK5XaEZfChuzU6h4u1CQMsLIdo+tBX2vdWh sgesbmJCRgVeVw4DCxQjqJh1N0ihYIoMmFQQqZ872CH9rhW3EwRHbf8mZyK4BIbCXbgC yTAOylC1IFze3R43mumUG6CEsxEWecmCzaFDKLqkwBBo289iZZx4DUKXyDSPY/OIG1Xd 8KHtsR2BaZN/rew5CSckekHqysPKB/6BDxBjxOlGKlwRBnzPSK3eFkT0cTu7LFQ+k7sE CP2Q== MIME-Version: 1.0 Received: by 10.180.107.67 with SMTP id ha3mr9159891wib.31.1356003685566; Thu, 20 Dec 2012 03:41:25 -0800 (PST) Received: by 10.194.51.35 with HTTP; Thu, 20 Dec 2012 03:41:25 -0800 (PST) In-Reply-To: <50D2DF5C.6040605@cs.tcd.ie> References: <50D2DF5C.6040605@cs.tcd.ie> Date: Thu, 20 Dec 2012 11:41:25 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmj3eEFOX6VVE02OVeVLrLMgQnIFNH7lUuHzlcGSbmfVupl7YMxB81aBvUyr3tYvCJLFv5fHd3cdOnGoYcB2GuxQ8DztUuXfnF9peIzKPE+FVKbxobeze93tEO2O0+s95aKnqn1iC+EJRk1fxuozyu1PwOcJ/umt2IzenkByVNXGba15rVXBEz39/JYFH7zsQgkLLbd Cc: "therightkey@ietf.org" Subject: Re: [therightkey] version -04 things to fix before/during IETF LC 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, 20 Dec 2012 11:41:27 -0000 On 20 December 2012 09:50, Stephen Farrell wrote: > - The poison extension: you say it has ASN.1 NULL data, but extensions > have OCTET STRING syntax. Do you mean an ASN.1 NULL (0x05 0x00) is > encoded as the value of the OCTET STRING or that the OCTET STRING > has zero length? This can be fixed after IETF LC, or now, if you > know what you're code does, but needs fixing. Extensions have OCTET STRING containing valid DER syntax :-) We mean what we say: ASN.1 NULL data. What would you like us to fix? From stephen.farrell@cs.tcd.ie Thu Dec 20 03:48:26 2012 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 D132021F846B for ; Thu, 20 Dec 2012 03:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.361 X-Spam-Level: X-Spam-Status: No, score=-102.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 ZawFIvWzbgUZ for ; Thu, 20 Dec 2012 03:48:26 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA3D21F8231 for ; Thu, 20 Dec 2012 03:48:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4C832BE3B; Thu, 20 Dec 2012 11:48:04 +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 uqtd1-37vPAf; Thu, 20 Dec 2012 11:48:03 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.44.68.76]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 34767BE1E; Thu, 20 Dec 2012 11:48:03 +0000 (GMT) Message-ID: <50D2FAF3.1070602@cs.tcd.ie> Date: Thu, 20 Dec 2012 11:48:03 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: <50D2DF5C.6040605@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] version -04 things to fix before/during IETF LC 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, 20 Dec 2012 11:48:26 -0000 On 12/20/2012 11:41 AM, Ben Laurie wrote: > On 20 December 2012 09:50, Stephen Farrell wrote: >> - The poison extension: you say it has ASN.1 NULL data, but extensions >> have OCTET STRING syntax. Do you mean an ASN.1 NULL (0x05 0x00) is >> encoded as the value of the OCTET STRING or that the OCTET STRING >> has zero length? This can be fixed after IETF LC, or now, if you >> know what you're code does, but needs fixing. > > Extensions have OCTET STRING containing valid DER syntax :-) > > We mean what we say: ASN.1 NULL data. > > What would you like us to fix? Explicitly say that the ASN.1 NULL (0x05 0x00) is the value of the OCTET STRING. People have gotten NULL messed up before like that, mainly in AlgorithmIdentifier, but quite a few did it. They assumed because it said "NULL" that meant that nothing is put into the DER encoding. That breaks interop. Now in this case, since you're trying to deliberately break interop for those precerts you could defend the ambiguity I guess, but it makes me hold my nose even so;-) S. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > From rob.stradling@comodo.com Thu Dec 20 04:02:20 2012 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 6D34D21F85E8 for ; Thu, 20 Dec 2012 04:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 JroeeTVgdk1i for ; Thu, 20 Dec 2012 04:02:19 -0800 (PST) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 731E721F85D0 for ; Thu, 20 Dec 2012 04:02:19 -0800 (PST) Received: (qmail 2355 invoked from network); 20 Dec 2012 12:02:17 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 20 Dec 2012 12:02:17 -0000 Received: (qmail 31703 invoked by uid 1000); 20 Dec 2012 12:02:17 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 20 Dec 2012 12:02:17 +0000 Message-ID: <50D2FE49.70409@comodo.com> Date: Thu, 20 Dec 2012 12:02:17 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "therightkey@ietf.org" References: <50D2DF5C.6040605@cs.tcd.ie> <50D2FAF3.1070602@cs.tcd.ie> In-Reply-To: <50D2FAF3.1070602@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ben Laurie , Stephen Farrell Subject: Re: [therightkey] version -04 things to fix before/during IETF LC 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, 20 Dec 2012 12:02:20 -0000 On 20/12/12 11:48, Stephen Farrell wrote: >> We mean what we say: ASN.1 NULL data. >> >> What would you like us to fix? > > Explicitly say that the ASN.1 NULL (0x05 0x00) is the > value of the OCTET STRING. People have gotten NULL messed up > before like that, mainly in AlgorithmIdentifier, but quite > a few did it. They assumed because it said "NULL" that meant > that nothing is put into the DER encoding. That breaks > interop. In case it helps... I just looked at RFC5280 and its predecessors for inspiration on how best to specify the syntax of certificate extensions. RFC2459 says stuff like... id-ce-basicConstraints OBJECT IDENTIFIER ::= {id-ce 19} basicConstraints EXTENSION ::= { SYNTAX BasicConstraintsSyntax IDENTIFIED BY id-ce-basicConstraints } BasicConstraintsSyntax ::= SEQUENCE { cA BOOLEAN DEFAULT FALSE, pathLenConstraint INTEGER (0..MAX) OPTIONAL } ...but RFC3280 and RFC5280 replaced the EXTENSION definitions with comments... -- basic constraints extension OID and syntax id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } BasicConstraints ::= SEQUENCE { cA BOOLEAN DEFAULT FALSE, pathLenConstraint INTEGER (0..MAX) OPTIONAL } > Now in this case, since you're trying to deliberately break > interop for those precerts you could defend the ambiguity > I guess, but it makes me hold my nose even so;-) > > S. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From benl@google.com Thu Dec 20 05:09:50 2012 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 7699F21F886C for ; Thu, 20 Dec 2012 05:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=0.353, 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 1GQ8Fnn1GGN2 for ; Thu, 20 Dec 2012 05:09:49 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC0821F8868 for ; Thu, 20 Dec 2012 05:09:49 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn17so4277217wib.6 for ; Thu, 20 Dec 2012 05:09:48 -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 :content-type; bh=EuQ4c4cjplK/8rOQKnA3soLvUH+eO6cZ54Hne1MjktI=; b=dKkIw49aEyksvqmV3AumdGR9dZ5ZOCTPvD6HnZO+MkW4do16/1TwEqDr/S9IhWcpUA pYoILGQqU5kmbTeb0YYCAVCEQxC/b9pPCgrj73n58UdEEUAySlWVeOKv2aoYeIDWL9ti SkJTpp6it9StTjpjyXzN+oReuZZGDtPKIK3DYRcQBzWW31gst9paWbD3t5EIt9N9Mxgo v2auS1PkO/jqDYjlGwl/MgCZqdk7tezBN2Db7b+vqEQWY8wfNx+DlRuML2CRprPLIWUH EIDbnJTDMnfsokwvl4gaJTNuohiIn2+DLCLN2QPbtTzv9eDFDQzd8f1BVIxZHIoTqhrC jB0g== 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 :content-type:x-gm-message-state; bh=EuQ4c4cjplK/8rOQKnA3soLvUH+eO6cZ54Hne1MjktI=; b=SbQ/j5QLG/fhQQLhBeZp9mlbUNHQgzo3hJuJKmx4bq//TvZ4vElVS29YrxRGBF9AMw q0Doy3vuX6I8PF0xcbOAedyb2T1orw8Ypdt85ydDIj0t3d3d9Sw7dbKIn9K1eBF4nXhW fT87dIvs2kaNqFWrQIRs02Z4kAQjvtGaIAbkS8hcoqirZLXJT+vuO80CX7FuqaulC+3d UVZngq9XqoJGjdUMDf4c9uYdNvk8s22yq1LjJc6grdAi5g+j9xICFpky4OM7QjiQMzt4 A8sJReXnFaj2hfGZi2jsaNsSgTJtviq4XOA7Vuf1RpVcRwp2YccNzKxC5Bg3MFkb2KzN gLKg== MIME-Version: 1.0 Received: by 10.194.119.33 with SMTP id kr1mr17710361wjb.4.1356008988699; Thu, 20 Dec 2012 05:09:48 -0800 (PST) Received: by 10.194.51.35 with HTTP; Thu, 20 Dec 2012 05:09:48 -0800 (PST) In-Reply-To: <20121220130811.31609.41248.idtracker@ietfa.amsl.com> References: <20121220130811.31609.41248.idtracker@ietfa.amsl.com> Date: Thu, 20 Dec 2012 13:09:48 +0000 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlTLXjbWBcHaO/ipkAMXn6iYyFzselIEEKW//FqSz/3JFKbfdbQutYWeBheKiV3LpVdwdb2h2NcNHDPiMQdEpaH55nVvqrSZzU0lbbV4VcIjDo40olh94qi0PmLO4H1QKlTBgr7Lgu+11qsUeaMEFjSKtFiwacxyjlcNyfV65UEb3ZqMTFCr8GZGYXobqL1/Cgtl/zC Subject: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-05.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, 20 Dec 2012 13:09:50 -0000 ---------- Forwarded message ---------- From: Date: 20 December 2012 13:08 Subject: New Version Notification for draft-laurie-pki-sunlight-05.txt To: benl@google.com Cc: ekasper@google.com, agl@google.com A new version of I-D, draft-laurie-pki-sunlight-05.txt has been successfully submitted by Ben Laurie and posted to the IETF repository. Filename: draft-laurie-pki-sunlight Revision: 05 Title: Certificate Transparency Creation date: 2012-12-20 WG ID: Individual Submission Number of pages: 28 URL: http://www.ietf.org/internet-drafts/draft-laurie-pki-sunlight-05.txt Status: http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight Htmlized: http://tools.ietf.org/html/draft-laurie-pki-sunlight-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-laurie-pki-sunlight-05 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 IETF Secretariat From tom@ritter.vg Thu Dec 20 05:46:48 2012 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 3BEE021F8A69 for ; Thu, 20 Dec 2012 05:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 hqYE2B0ddF+z for ; Thu, 20 Dec 2012 05:46:45 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id B88E521F8812 for ; Thu, 20 Dec 2012 05:46:44 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id fl11so3759461vcb.15 for ; Thu, 20 Dec 2012 05:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BoKFqZg6F2HjxcuBQFZ/8Y1EnT6CoZNI1nGw6zK+N4U=; b=DIXvs/VnDS+gn9OzRSMdEu9tGFomLtFldGR4Y7KFAOGOUI078Nu/L2RgpNDpmRo7/9 vI+oUnZht9WQoKkRbG6lL6FoZkxQp0wGUMcazqRENDUXcqcvl7Vo7/kqgxwnEkB3FTXr q0QRbTsRr53punA5AlfPJYWEcmuNF2gYuuN+8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=BoKFqZg6F2HjxcuBQFZ/8Y1EnT6CoZNI1nGw6zK+N4U=; b=hIFPb3UbbkECjtpIY/Pk7i/i/0IKNl4zqLekL/CUrvCQAZgro6LmBPGIbdkOFL2NsK CR1VE35Vvc4ySwf31qHMveg28hsggf7pTVVoBNh6zJtBI3+OXHJU/WH1d0JaRMvQvZji Yd/8c3NXDgyGgCivgkHPPG1di9jtfVPdJzcGyOXtGDYWvJGcPdLP3I8XzXo/43SGBAP5 h5A0skHbhKZSy3xf/QDtcQhawMtMEOfRJNEyAbPLWAt+QB/6eGqkFpqiiyNo0k38xPxa OjO0eJhP8VFRgptZ0LpbIKcpDCZPJjq+oeG1hPPN43It02bRwKusK8kHr0pxozAHP63P 83Kg== Received: by 10.52.98.134 with SMTP id ei6mr12479640vdb.114.1356011204007; Thu, 20 Dec 2012 05:46:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.255.104 with HTTP; Thu, 20 Dec 2012 05:46:23 -0800 (PST) In-Reply-To: References: <20121219211603.15506.12874.idtracker@ietfa.amsl.com> <50D23DEC.9020308@cs.tcd.ie> From: Tom Ritter Date: Thu, 20 Dec 2012 08:46:23 -0500 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQljt6bfpOe99FFphWeU1ETm1I+tar3YXTYeLxBnNMuqkZp0fszMMFvWM7NwvONTE8p08qin Cc: therightkey@ietf.org Subject: Re: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-04.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, 20 Dec 2012 13:46:48 -0000 On 20 December 2012 04:47, Ben Laurie wrote: >> RE: DANE/Self-Signed Certs >> >> [Note: this effectively excludes self-signed and DANE-based >> certificates until some mechanism to control spam for those >> certificates is found - the authors welcome suggestions]. >> >> >> Suggestion: >> >> Logs MAY accept certificates without a complete chain if querying >> the Common Name in the certificate indicates the certificate is >> deployed on a webserver or included in DNS records. Logs MAY >> set policies around subdomains and paths to maintain availability. >> >> If what you're trying to avoid is bloating the Merkle Tree, then >> reaching out for a TLS handshake or DNS records could work. Even if >> they were spoofed/middled/whatever - the log isn't certifying they're >> valid, only that they're public. In the future, someone could submit >> a DNS signature chain and bypass the need for the log to reach out, >> but that'd require defining new APIs and structures, and that's too >> much. > > I kinda like this suggestion, but it doesn't seem like it would > actually be much of a barrier to spam. Of course, if we make it a MAY > it would be no skin off my nose - but I doubt Google will implement > the MAY. Poop, since Google's the only person committed to running a log so far... I figured requiring a spammer to generate a valid key & certificate, and deploy it on a reachable DNS name would be enough of a cost offset from the log; and on the DANE side requiring them to deploy to a signed DNSSEC record would be likewise. And the subdomain restrictions mean you could go so far as to require a new domain name for each entry, plus rate limiting at no resubmissions for a domain per hour/day. -tom From rob.stradling@comodo.com Thu Dec 20 06:07:08 2012 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 3C1BA21F8626 for ; Thu, 20 Dec 2012 06:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URI_EQUALS=1.666] 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 Yne2zHWdXDMx for ; Thu, 20 Dec 2012 06:06:56 -0800 (PST) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 94BBA21F860A for ; Thu, 20 Dec 2012 06:06:55 -0800 (PST) Received: (qmail 13450 invoked from network); 20 Dec 2012 14:06:54 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 20 Dec 2012 14:06:54 -0000 Received: (qmail 32506 invoked by uid 1000); 20 Dec 2012 14:06:54 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 20 Dec 2012 14:06:54 +0000 Message-ID: <50D31B7D.3080204@comodo.com> Date: Thu, 20 Dec 2012 14:06:53 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: <50D2DF5C.6040605@cs.tcd.ie> <50D2F655.3040306@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] version -04 things to fix before/during IETF LC 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, 20 Dec 2012 14:07:08 -0000 On 20/12/12 11:39, Ben Laurie wrote: > On 20 December 2012 11:38, Ben Laurie wrote: >> On 20 December 2012 11:28, Rob Stradling wrote: >>> On 20/12/12 11:20, Ben Laurie wrote: >>>> >>>> On 20 December 2012 09:50, Stephen Farrell >>>> wrote: >>>>> >>>>> - Having a thing with basicConstraints.cA==false issue precerts >>>>> seems wrong, but that may be better discussed during IETF LC so >>>>> I'm not requesting a change now. >>>> >>>> >>>> This was deliberate to avoid the precertificate being a valid >>>> certificate, as requested by CAs. >>> >>> >>> Ben, doesn't the new poison critical extension requirement mean that this >>> Basic Constraints hack is no longer needed? >>> >>> The poison critical extension means that a precert cannot be used as a cert. >>> Is that not invalid enough?!? >> >> Probably. > > I've removed it. Ben, I see that "(note that the log may relax standard validation rules to allow this, so long as the final signed certificate will be valid)" is still present in -05. I think I see why... Am I correct that the Issuer and Authority Key Identifier fields in a precertificate MUST match the Subject and Subject Key Identifier fields in "the CA certificate that will sign the final certificate", even if the precertificate is actually signed by the private key that corresponds to a Precertificate Signing Certificate? If yes, then I think it might be worth emphasizing this point. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From benl@google.com Thu Dec 20 06:48:14 2012 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 D72EF21F884F for ; Thu, 20 Dec 2012 06:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.856 X-Spam-Level: X-Spam-Status: No, score=-102.856 tagged_above=-999 required=5 tests=[AWL=0.121, 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 8AySUegcQKOl for ; Thu, 20 Dec 2012 06:48:14 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id E9E3321F8830 for ; Thu, 20 Dec 2012 06:48:13 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fg15so1531410wgb.33 for ; Thu, 20 Dec 2012 06:48:13 -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=uhceI/87/YLYldCLZyAXhKwPF7j+Nua1VP4kZkWp1+8=; b=ecWSFeQoSP2qtynRqqv4iS6C0Qr+X69KSwUmnKfyxe72YFy1eHQSzp2QvKtAibeI8c kzFIzrN5WItGsCUZIgayXvb7jAu1Lrqv9DlQBdBvnnv+0pczKC6nEmTz4YxBS/At3Wcx Gs/AoUlJnTrXuS5GJsVecZbBJCUGvUiCTgmFMRMXrLwkqtYKTSFEjJk6yrBLZOVdSZx5 RuOhmLDDhZin4IUap9QVjr8E+AtNFETk9tgqf7lA3sCIcIYle1xKvMFkVQi6VEUDI7eN N3MkQ50AZhYYbG9Wd42xbEb7HxdQuBNv5gkTiD9Un0ZKBPWs9dnl54xQIOyQ72e9CpAu PP/Q== 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=uhceI/87/YLYldCLZyAXhKwPF7j+Nua1VP4kZkWp1+8=; b=h7HoCq+1FRNQ3WWtlLzalvgHe8VpwpYglBCJY6tlQrgyedVnRmAlANhlesYn0feuE1 uRBMb9o3IEw9ioyjK2j6TDHqcvq3bubzpdcyHF2a5a2QbajkGPAgbs0NdvjQ+3O6BKdE 1eAm5rl3/aXTYoLUB70WnkYX3A6v4r1l/J2WoLu1J11KAYR1dhZZwFUTkuuw/a00NA3C mbd6nr0ipH4qqesnJCuI3/VRl4ijRLpZorasb7zWNIDSrtjX6Qnpc2T5H+ZGaM+zPYr7 7wZ47WqCU9162ugU3HR3tINr6WMsbiicJ95XIZaEMrtleRZV/b1LmsYU+xabYpHa70Ux ZMtQ== MIME-Version: 1.0 Received: by 10.180.87.228 with SMTP id bb4mr388312wib.31.1356014813342; Thu, 20 Dec 2012 06:46:53 -0800 (PST) Received: by 10.194.51.35 with HTTP; Thu, 20 Dec 2012 06:46:53 -0800 (PST) In-Reply-To: References: <20121219211603.15506.12874.idtracker@ietfa.amsl.com> <50D23DEC.9020308@cs.tcd.ie> Date: Thu, 20 Dec 2012 14:46:53 +0000 Message-ID: From: Ben Laurie To: Tom Ritter Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkY7dCA8IMIiZgM+y/2LyV9qzRidMuMww5+cfZt9cqrnM9bBoQR7QKIEXKZiK1hbVoOagaUDRkUKmQddV1ZF67TvZILdap8CB23uDPCus+xxlBokjc54+77DQmKLJxqv2HRe2yKHhY4wR5inHcAbyMT4nbuo8n2WJER7ho6FuoMdybXqjfbnD5MxnYuHooFOZ+QowsD Cc: therightkey@ietf.org Subject: Re: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-04.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, 20 Dec 2012 14:48:15 -0000 On 20 December 2012 13:46, Tom Ritter wrote: > On 20 December 2012 04:47, Ben Laurie wrote: >>> RE: DANE/Self-Signed Certs >>> >>> [Note: this effectively excludes self-signed and DANE-based >>> certificates until some mechanism to control spam for those >>> certificates is found - the authors welcome suggestions]. >>> >>> >>> Suggestion: >>> >>> Logs MAY accept certificates without a complete chain if querying >>> the Common Name in the certificate indicates the certificate is >>> deployed on a webserver or included in DNS records. Logs MAY >>> set policies around subdomains and paths to maintain availability. >>> >>> If what you're trying to avoid is bloating the Merkle Tree, then >>> reaching out for a TLS handshake or DNS records could work. Even if >>> they were spoofed/middled/whatever - the log isn't certifying they're >>> valid, only that they're public. In the future, someone could submit >>> a DNS signature chain and bypass the need for the log to reach out, >>> but that'd require defining new APIs and structures, and that's too >>> much. >> >> I kinda like this suggestion, but it doesn't seem like it would >> actually be much of a barrier to spam. Of course, if we make it a MAY >> it would be no skin off my nose - but I doubt Google will implement >> the MAY. > > > Poop, since Google's the only person committed to running a log so far... > > I figured requiring a spammer to generate a valid key & certificate, > and deploy it on a reachable DNS name would be enough of a cost offset > from the log; and on the DANE side requiring them to deploy to a > signed DNSSEC record would be likewise. And the subdomain > restrictions mean you could go so far as to require a new domain name > for each entry, plus rate limiting at no resubmissions for a domain > per hour/day. Well, I'm certainly prepared to consider solutions - particularly for DANE backed records. So far, however, the DNSSEC people haven't shown much interest. However, rather than log DANE-based certificates, it makes more sense, as previously discussed, to log DNSSEC key records. I did have an idea for anti-spam there, which I'll write up properly some time soon - but in short, each domain from the root down has its own log for delegations. If it wishes it can also log subdelegations, or it can instead subdelegate the log. So, anyone wanting to create large numbers of subdomains could be required by their parent's log to run their own log, but small users could be serviced directly by the parent's log. From benl@google.com Thu Dec 20 06:49:58 2012 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 1E71A21F8526 for ; Thu, 20 Dec 2012 06:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.032 X-Spam-Level: X-Spam-Status: No, score=-102.032 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_URI_EQUALS=1.666, 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 jxiFs8Ph72QT for ; Thu, 20 Dec 2012 06:49:57 -0800 (PST) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by ietfa.amsl.com (Postfix) with ESMTP id 61A0021F842F for ; Thu, 20 Dec 2012 06:49:57 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id r5so1631095wey.35 for ; Thu, 20 Dec 2012 06:49:56 -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=6wmygUNR7hukyuP5ehc0I9tLw1yUWSX/cJCjj860MPo=; b=h+ka5htMyhu7MOEgbBP8N0/smEjBRefymNwNKDfH5bYmkIKx3WMj9mR2MUki6fEmnY MH0TT40GWrJDdB2diU5RUAt/yEry1ToIoDEe30wS62e8/z/fUDhxSwM+69J0qZmdxfpT s+u3zeendKu/H9sLVE6eFTzUxCHrWI9+xeMFsN76ekfiYLqH9weiR2cjFmhGMQjDvKJs PBoJOibBbCRxa6dkiFMZ/gTlfXU6Y9w6CpTOGIsdIka/161TghqXaWJMmvG0GX0hYdCw /k5G64RmhzR/pifIguWadHzBNDqiWcmmBIFUlJhBLR3tttSXouhWRhYixS5tQ8md8wD9 KiGw== 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=6wmygUNR7hukyuP5ehc0I9tLw1yUWSX/cJCjj860MPo=; b=lRIUQJNnJnQ+NXm+iuZFgkjq2Rp/IxLgriE50xP2Rx9ufIdyvuj7ossXkKDmTf6/bc J38u2pmPDzS8VZX42Gzp7WTgrWSA/JZcqzw5kBuXzSlX3/qjjY0EckHNB7vPqhOrndLM l40CX7KiMA+nJQbZ2jn0fnbua1BpvbzP8Hv5VLObWlI4TwflNaAe/tRldGaYNP8pZAlT MYkwfxEEksbGbzZjY3qDYSggrIqk9wCZygYDkCRfRBa4ku9t20FbT4nkU0Qyp2vnaIsc OTCY6IYyQVKfegr1sxTEMMzz/kKemvvYsXPzcIY+pFu96gJE3L7BmesY1KiUU6kxpi4Z r0tQ== MIME-Version: 1.0 Received: by 10.180.100.197 with SMTP id fa5mr10216656wib.32.1356014996242; Thu, 20 Dec 2012 06:49:56 -0800 (PST) Received: by 10.194.51.35 with HTTP; Thu, 20 Dec 2012 06:49:56 -0800 (PST) In-Reply-To: <50D31B7D.3080204@comodo.com> References: <50D2DF5C.6040605@cs.tcd.ie> <50D2F655.3040306@comodo.com> <50D31B7D.3080204@comodo.com> Date: Thu, 20 Dec 2012 14:49:56 +0000 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmSfg/P23EX8j9kjDyLpK7iuGSUOGlrfBjAG7Baxy87NAlyYOzzlued5ib4FtU6qX06nrwCQY9YaOkWmhvIEQ8iooUkqdULwb4rhw8IVMYaYsVKnrDqXVlVZwwHca1mJTHmsIQKpSC62U/v1xJluus1yDbi26oBupsBjkVlI3irAuBg//kKzSOeqtSVIiBzmo8lUz3+ Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] version -04 things to fix before/during IETF LC 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, 20 Dec 2012 14:49:58 -0000 On 20 December 2012 14:06, Rob Stradling wrote: > On 20/12/12 11:39, Ben Laurie wrote: >> >> On 20 December 2012 11:38, Ben Laurie wrote: >>> >>> On 20 December 2012 11:28, Rob Stradling >>> wrote: >>>> >>>> On 20/12/12 11:20, Ben Laurie wrote: >>>>> >>>>> >>>>> On 20 December 2012 09:50, Stephen Farrell >>>>> wrote: >>>>>> >>>>>> >>>>>> - Having a thing with basicConstraints.cA==false issue precerts >>>>>> seems wrong, but that may be better discussed during IETF LC so >>>>>> I'm not requesting a change now. >>>>> >>>>> >>>>> >>>>> This was deliberate to avoid the precertificate being a valid >>>>> certificate, as requested by CAs. >>>> >>>> >>>> >>>> Ben, doesn't the new poison critical extension requirement mean that >>>> this >>>> Basic Constraints hack is no longer needed? >>>> >>>> The poison critical extension means that a precert cannot be used as a >>>> cert. >>>> Is that not invalid enough?!? >>> >>> >>> Probably. >> >> >> I've removed it. > > > Ben, I see that "(note that the log may relax standard validation rules to > allow this, so long as the final signed certificate will be valid)" is still > present in -05. I think I see why... > > Am I correct that the Issuer and Authority Key Identifier fields in a > precertificate MUST match the Subject and Subject Key Identifier fields in > "the CA certificate that will sign the final certificate", even if the > precertificate is actually signed by the private key that corresponds to a > Precertificate Signing Certificate? > > If yes, then I think it might be worth emphasizing this point. Right now the log actually replaces these with the right things, rather than requiring the pre-cert to contain them. But again, we are happy to be guided by CAs on the best thing to do here. The reason for that note was actually for things like path length constraints that might get violated by inserting an extra intermediate. > > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > From paul.hoffman@vpnc.org Thu Dec 20 13:21:27 2012 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 09FC721F8A77 for ; Thu, 20 Dec 2012 13:21:27 -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 XB7FfVa03ytj for ; Thu, 20 Dec 2012 13:21:26 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 48BC521F8A51 for ; Thu, 20 Dec 2012 13:21:26 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qBKLLO4p003026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Dec 2012 14:21:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Dec 2012 13:21:23 -0800 References: <20121220193358.31474.25301.idtracker@ietfa.amsl.com> To: "therightkey@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [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, 20 Dec 2012 21:21:27 -0000 Extra points for you *not* replying to this message, but creating a new = message with a new, useful Subject: line. Begin forwarded message: > From: The IESG > Subject: Last Call: (Certificate = Transparency) to Experimental RFC > Date: December 20, 2012 11:33:58 AM PST > To: IETF-Announce > Reply-To: ietf@ietf.org >=20 >=20 > The IESG has received a request from an individual submitter to = consider > the following document: > - 'Certificate Transparency' > as Experimental RFC >=20 > 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. >=20 > Abstract >=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 From stephen.farrell@cs.tcd.ie Thu Dec 20 13:35:15 2012 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 A289D21F89FB for ; Thu, 20 Dec 2012 13:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 P7u5myHwUpHS for ; Thu, 20 Dec 2012 13:35:14 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1C33221F8994 for ; Thu, 20 Dec 2012 13:35:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B990DBE3E for ; Thu, 20 Dec 2012 21:34:51 +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 lMVvpQpjlAV0 for ; Thu, 20 Dec 2012 21:34:46 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.44.68.76]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BF383BE1C for ; Thu, 20 Dec 2012 21:34:46 +0000 (GMT) Message-ID: <50D38475.9080701@cs.tcd.ie> Date: Thu, 20 Dec 2012 21:34:45 +0000 From: Stephen Farrell 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" References: <20121220193358.31474.25301.idtracker@ietfa.amsl.com> In-Reply-To: <20121220193358.31474.25301.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 X-Forwarded-Message-Id: <20121220193358.31474.25301.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [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, 20 Dec 2012 21:35:15 -0000 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. From rob.stradling@comodo.com Thu Dec 27 03:27:31 2012 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 D1BDE21F8D24 for ; Thu, 27 Dec 2012 03:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] 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 g3FHypCZge5N for ; Thu, 27 Dec 2012 03:27:31 -0800 (PST) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id DB28421F8CF3 for ; Thu, 27 Dec 2012 03:27:29 -0800 (PST) Received: (qmail 23166 invoked from network); 27 Dec 2012 11:27:19 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 27 Dec 2012 11:27:19 -0000 Received: (qmail 25717 invoked by uid 1000); 27 Dec 2012 11:27:19 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 27 Dec 2012 11:27:19 +0000 Message-ID: <50DC3096.1030002@comodo.com> Date: Thu, 27 Dec 2012 11:27:18 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Laurie References: <50D2DF5C.6040605@cs.tcd.ie> <50D2F655.3040306@comodo.com> <50D31B7D.3080204@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] version -04 things to fix before/during IETF LC 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, 27 Dec 2012 11:27:31 -0000 On 20/12/12 14:49, Ben Laurie wrote: >> Ben, I see that "(note that the log may relax standard validation rules to >> allow this, so long as the final signed certificate will be valid)" is still >> present in -05. I think I see why... >> >> Am I correct that the Issuer and Authority Key Identifier fields in a >> precertificate MUST match the Subject and Subject Key Identifier fields in >> "the CA certificate that will sign the final certificate", even if the >> precertificate is actually signed by the private key that corresponds to a >> Precertificate Signing Certificate? >> >> If yes, then I think it might be worth emphasizing this point. > > Right now the log actually replaces these with the right things, > rather than requiring the pre-cert to contain them. But again, we are > happy to be guided by CAs on the best thing to do here. > > The reason for that note was actually for things like path length > constraints that might get violated by inserting an extra > intermediate. Ah, I see. I'll be using the "CA certificate that will sign the final certificate" option when I implement this for Comodo, so I don't really have any opinions on what "the best thing to do here" is. If any CAs intend to use Precertificate Signing Certificates but are unable to tweak their CA software to "relax standard validation rules", then they should speak up now! -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online