From dcarella@linagora.com Wed Jun 1 07:00:11 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3868DE085A for ; Wed, 1 Jun 2011 07:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 uon2lOvMU9ar for ; Wed, 1 Jun 2011 07:00:10 -0700 (PDT) Received: from alderaan.linagora.com (alderaan.linagora.com [109.197.183.74]) by ietfa.amsl.com (Postfix) with ESMTP id D516EE0807 for ; Wed, 1 Jun 2011 07:00:09 -0700 (PDT) Received: from [10.75.129.124] (unknown [10.75.129.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by alderaan.linagora.com (Postfix) with ESMTPSA id 8075D429EE3 for ; Wed, 1 Jun 2011 16:00:08 +0200 (CEST) Message-ID: <4DE645E7.4000909@linagora.com> Date: Wed, 01 Jun 2011 16:00:07 +0200 From: David CARELLA Organization: LINAGORA User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: PKIX References: <4DE3BE48.5040506@linagora.com> In-Reply-To: <4DE3BE48.5040506@linagora.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pkix] Best practices for Certificate Policy OIDs in certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:00:11 -0000 Nobody to answer my questions? Links or documents are welcome. Are my questions not clear? or too long? Regards, David On 05/30/2011 05:56 PM, David CARELLA wrote: > Hi all, > > After reading RFC 5280, § 4.2.1.4 Certificate Policies, I have several > questions about the best practices on certificate policies: > - certificate policies writing (number of documents), > - setting the certificate policy OIDs (and qualifiers) in CA and end > entities certificates. > > I suppose that I have: > - entities and theirs certificates: > - Root CA, > - Sub CA 1 (Intermediate CA), issued by Root CA, > - Sub CA 2 (End CA), issued by Sub CA 1, > - End entities (EE), issued by Sub CA 2; > - certificate policies: > - Root CA certificate policy (describe Root CA and Sub CA 1): OID-0, > - Sub CA 1 certificate policy (describe Sub CA 1 and Sub CA 2): OID-1, > - Sub CA 2 certificate policy (describe Sub CA 2 and End entities): > OID-2. > > > Which is the best practice, for certificate policies writing? > 1. One certificate policy (CP) by CA (cf. above), > i.e.: > - one CP for Root CA, > - one CP for each level 1 Sub CA, > - and one CP for each level 2 Sub CA, > 2. One certificate policy for Root CA and level 1 Sub CA, > and one certificate policy for each level 2 Sub CA (as End CA), > 3. Other case? > > > Which is the best technical practice, among the following examples, or > other cases? > > --- Example 1 > According to RFC 5280, and strictly respected. > > Root CA: Certificate policy: > - policyIdentifier: anyPolicy [2.5.29.32.0] > - policyQualifiers: - cPSuri: URI > > Sub CA 1: Certificate policy: > - policyIdentifier: anyPolicy [2.5.29.32.0] > - policyQualifiers: - cPSuri: URI > > Sub CA 2: Certificate policy: > - policyIdentifier: anyPolicy [2.5.29.32.0] > - policyQualifiers: - cPSuri: URI > > End entity: Certificate policy: > - policyIdentifier: OID (OID-2) > > --> E.g. URI = http://pki.project.org/cps/ > > > --- Example 2 > According to RFC 5280, and according to what I saw in Firefox > ("conformed" built-in CAs). > > Root CA: Certificate policy: > - policyIdentifier: anyPolicy [2.5.29.32.0] > - policyQualifiers: - cPSuri: URI > > Sub CA 1: Certificate policy: > - policyIdentifier: anyPolicy [2.5.29.32.0] > - policyQualifiers: - cPSuri: URI > > Sub CA 2: Certificate policy: > - policyIdentifier: OID (OID-2) > - policyQualifiers: - cPSuri: URI > > End entity: Certificate policy: > - policyIdentifier: OID (OID-2) > - policyQualifiers: > - cPSuri: URI > - userNotice: - explicitText: text (if need) > > --> E.g. URI = http://pki.project.org/cps/ > > > --- Example 3 > Sometimes, I saw the following case (for the Sub CA 2, from my example > 2), but it isn't conformed to the recommendations described in RFC 5280, > because there are two OIDs, and cPSuri isn't needful for OID!=anyPolicy. > Is it still a good practice? > > Sub CA 2: > Certificate policy: > - policyIdentifier: OID (OID-2) > - policyQualifiers: - cPSuri: URI > Certificate policy: > - policyIdentifier: anyPolicy [2.5.29.32.0] > > --> E.g. URI = http://pki.project.org/cps/ > > > Best regards, > David CARELLA > > > ------------------------------------------------------------------------ > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From housley@vigilsec.com Wed Jun 1 07:12:18 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E63E06F6 for ; Wed, 1 Jun 2011 07:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 G62qgqWptzMh for ; Wed, 1 Jun 2011 07:12:17 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 55101E079C for ; Wed, 1 Jun 2011 07:11:56 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id BD2CEF24099; Wed, 1 Jun 2011 10:11:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id EuDlt5V8A9mn; Wed, 1 Jun 2011 10:11:54 -0400 (EDT) Received: from [172.21.129.48] (unknown [63.164.30.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 99041F24090; Wed, 1 Jun 2011 10:11:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Russ Housley In-Reply-To: <4DE645E7.4000909@linagora.com> Date: Wed, 1 Jun 2011 10:11:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DE3BE48.5040506@linagora.com> <4DE645E7.4000909@linagora.com> To: David CARELLA X-Mailer: Apple Mail (2.1084) Cc: PKIX Subject: Re: [pkix] Best practices for Certificate Policy OIDs in certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:12:18 -0000 Policy qualifiers are ugly. Please do not use them. Why not define a single policy that states the roles of the Root CA, Sub = CA 1, and Sub CA 2, and then use the same OID throughout. That avoids = the need for any mappings and other complexity. Russ On Jun 1, 2011, at 10:00 AM, David CARELLA wrote: > Nobody to answer my questions? > Links or documents are welcome. >=20 > Are my questions not clear? or too long? >=20 > Regards, > David >=20 > On 05/30/2011 05:56 PM, David CARELLA wrote: >> Hi all, >> After reading RFC 5280, =A7 4.2.1.4 Certificate Policies, I have = several questions about the best practices on certificate policies: >> - certificate policies writing (number of documents), >> - setting the certificate policy OIDs (and qualifiers) in CA and end = entities certificates. >> I suppose that I have: >> - entities and theirs certificates: >> - Root CA, >> - Sub CA 1 (Intermediate CA), issued by Root CA, >> - Sub CA 2 (End CA), issued by Sub CA 1, >> - End entities (EE), issued by Sub CA 2; >> - certificate policies: >> - Root CA certificate policy (describe Root CA and Sub CA 1): = OID-0, >> - Sub CA 1 certificate policy (describe Sub CA 1 and Sub CA 2): = OID-1, >> - Sub CA 2 certificate policy (describe Sub CA 2 and End = entities): OID-2. >> Which is the best practice, for certificate policies writing? >> 1. One certificate policy (CP) by CA (cf. above), >> i.e.: >> - one CP for Root CA, >> - one CP for each level 1 Sub CA, >> - and one CP for each level 2 Sub CA, >> 2. One certificate policy for Root CA and level 1 Sub CA, >> and one certificate policy for each level 2 Sub CA (as End CA), >> 3. Other case? >> Which is the best technical practice, among the following examples, = or other cases? >> --- Example 1 >> According to RFC 5280, and strictly respected. >> Root CA: Certificate policy: >> - policyIdentifier: anyPolicy [2.5.29.32.0] >> - policyQualifiers: - cPSuri: URI >> Sub CA 1: Certificate policy: >> - policyIdentifier: anyPolicy [2.5.29.32.0] >> - policyQualifiers: - cPSuri: URI >> Sub CA 2: Certificate policy: >> - policyIdentifier: anyPolicy [2.5.29.32.0] >> - policyQualifiers: - cPSuri: URI >> End entity: Certificate policy: >> - policyIdentifier: OID (OID-2) >> --> E.g. URI =3D http://pki.project.org/cps/ >> --- Example 2 >> According to RFC 5280, and according to what I saw in Firefox = ("conformed" built-in CAs). >> Root CA: Certificate policy: >> - policyIdentifier: anyPolicy [2.5.29.32.0] >> - policyQualifiers: - cPSuri: URI >> Sub CA 1: Certificate policy: >> - policyIdentifier: anyPolicy [2.5.29.32.0] >> - policyQualifiers: - cPSuri: URI >> Sub CA 2: Certificate policy: >> - policyIdentifier: OID (OID-2) >> - policyQualifiers: - cPSuri: URI >> End entity: Certificate policy: >> - policyIdentifier: OID (OID-2) >> - policyQualifiers: >> - cPSuri: URI >> - userNotice: - explicitText: text (if need) >> --> E.g. URI =3D http://pki.project.org/cps/ >> --- Example 3 >> Sometimes, I saw the following case (for the Sub CA 2, from my = example 2), but it isn't conformed to the recommendations described in = RFC 5280, because there are two OIDs, and cPSuri isn't needful for = OID!=3DanyPolicy. >> Is it still a good practice? >> Sub CA 2: >> Certificate policy: >> - policyIdentifier: OID (OID-2) >> - policyQualifiers: - cPSuri: URI >> Certificate policy: >> - policyIdentifier: anyPolicy [2.5.29.32.0] >> --> E.g. URI =3D http://pki.project.org/cps/ >> Best regards, >> David CARELLA >> = ------------------------------------------------------------------------ >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From kent@bbn.com Wed Jun 1 11:40:11 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04F0130059 for ; Wed, 1 Jun 2011 11:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 RpRngMaUe71L for ; Wed, 1 Jun 2011 11:40:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABAC130054 for ; Wed, 1 Jun 2011 11:40:11 -0700 (PDT) Received: from dhcp89-089-178.bbn.com ([128.89.89.178]:49368 helo=[192.168.1.12]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QRqKw-000BqU-NI; Wed, 01 Jun 2011 14:40:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 1 Jun 2011 14:28:36 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 18:40:11 -0000 Folks, The CAA proposal proposes ways in which a CA can behave to reduce the likelihood of mis-issuing certs. It calls for a the domain name holder to publish a DNS record with info about the set of CAs that the DNS name holder views as authorized to issue certs for that domain. Since PKIX regularly develops standards that provide guidance re CA operation (to some extent) CAA seems to be appropriate for consideration as a PKIX work item. (I am less confident about the discussion of RP behavior, for some of the reasons cited in discussion on the PKIX list over the last few days). This proposal is currently targeted as Experimental, which seems appropriate. My one caveat to PHB is that IF CAA becomes a work item, the final form of the doc will be subject to the usual WG consensus procedures. I have discussed this with Stefan and he concurs. With that said, if PHB wants PKIX to adopt this work, the co-chairs are amenable. Steve From paul.hoffman@vpnc.org Wed Jun 1 14:19:29 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2744E090F for ; Wed, 1 Jun 2011 14:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 iQj8Rj74TvK5 for ; Wed, 1 Jun 2011 14:19:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6E580E08F5 for ; Wed, 1 Jun 2011 14:19:27 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p51LILxJ059062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Jun 2011 14:18:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 1 Jun 2011 14:18:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> References: To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 21:19:29 -0000 On Jun 1, 2011, at 11:28 AM, Stephen Kent wrote: > This proposal is currently targeted as Experimental, which seems > appropriate. We have not yet heard of Phill would want that to be the intended status = if the WG adopts it. > My one caveat to PHB is that IF CAA becomes a work item, the final > form of the doc will be subject to the usual WG consensus procedures. > I have discussed this with Stefan and he concurs. >=20 > With that said, if PHB wants PKIX to adopt this work, the co-chairs = are amenable. Earlier, Phill said "I don't think it very likely that we are going to = want to look at a complete redesign. But I could imagine people have = ideas for new property tags that could be usefully added." I see likely = changes between those two poles, and thus still am quite concerned about = whether this is a good use of WG time. FWIW, I would like to see a protocol based on the idea of "a DNS admin = tells prospective CAs who should and should not issue certificates for = the DNS name" done in the IETF under normal IETF protocol development = rules. The PKIX WG seems like a fine place to do that as long as the CA = community believes that they are likely to use our output. My concern is = that Phill has already done a lot of work on a specific manifestation of = the idea, including the non-trivial task of lining up developers and CAs = behind his protocol. If they aren't interested in what could easily be a = different protocol coming from the IETF process, there is no reason for = us to spend the time on it. --Paul Hoffman From kent@bbn.com Wed Jun 1 14:51:05 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C43E071A for ; Wed, 1 Jun 2011 14:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.311 X-Spam-Level: X-Spam-Status: No, score=-106.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 BsWNkxsKA-tr for ; Wed, 1 Jun 2011 14:51:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C4187E06CA for ; Wed, 1 Jun 2011 14:51:04 -0700 (PDT) Received: from dhcp89-089-178.bbn.com ([128.89.89.178]:49380 helo=[192.168.1.12]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QRtJg-000FCR-6T; Wed, 01 Jun 2011 17:51:04 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> Date: Wed, 1 Jun 2011 17:41:53 -0400 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 21:51:05 -0000 At 2:18 PM -0700 6/1/11, Paul Hoffman wrote: >On Jun 1, 2011, at 11:28 AM, Stephen Kent wrote: > >> This proposal is currently targeted as Experimental, which seems >> appropriate. > >We have not yet heard of Phill would want that to be the intended >status if the WG adopts it. I assumed Experimental, because that's what the current draft says, but ... > >> My one caveat to PHB is that IF CAA becomes a work item, the final >> form of the doc will be subject to the usual WG consensus procedures. >> I have discussed this with Stefan and he concurs. >> >> With that said, if PHB wants PKIX to adopt this work, the >>co-chairs are amenable. > >Earlier, Phill said "I don't think it very likely that we are going >to want to look at a complete redesign. But I could imagine people >have ideas for new property tags that could be usefully added." I >see likely changes between those two poles, and thus still am quite >concerned about whether this is a good use of WG time. We need to hear from Phil on this. >FWIW, I would like to see a protocol based on the idea of "a DNS >admin tells prospective CAs who should and should not issue >certificates for the DNS name" done in the IETF under normal IETF >protocol development rules. The PKIX WG seems like a fine place to >do that as long as the CA community believes that they are likely to >use our output. My concern is that Phill has already done a lot of >work on a specific manifestation of the idea, including the >non-trivial task of lining up developers and CAs behind his >protocol. If they aren't interested in what could easily be a >different protocol coming from the IETF process, there is no reason >for us to spend the time on it. ibid. Steve From hallam@gmail.com Wed Jun 1 16:40:13 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11ACE084C for ; Wed, 1 Jun 2011 16:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 0GQQTqxvDoEc for ; Wed, 1 Jun 2011 16:40:13 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4E2DE07C5 for ; Wed, 1 Jun 2011 16:40:12 -0700 (PDT) Received: by gxk19 with SMTP id 19so170099gxk.31 for ; Wed, 01 Jun 2011 16:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b4C+ZBKkN/UiKtWfp3gEoGiFABMJ6NomUkmD+TNYFAc=; b=UMVk4+0QKT1sV65BWNTu/lN2bOBHnUpBX9aDpYQh//StgGkkGJ2oxVgwWAL6I+k3Fx yhdXXDr+L/PaPYx+8/2b3mzHc4iSon6PJ43hkO1lnhkFkIzrIUlVsDr2Jho2XY649A4r 0Hf/4Qzr1Xm4kvoLfzJxfmXFkrShaKE6RWUgM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=o7FZlk4QUIAB2WMUUIE+uZaqsyMMdOY68rDHVHyE0IaI1s7fPZ1Lkp2EK/df6UbGoH jxOAECtYhY1k9AsvXqyeUSfFuTzNSiiRwMWYmwZ9eNccJTL/eEJiyH7z/JhIbYsh/mHV 9wZfJOkWf64aAdVoPvrw64kvGmTKhmjW0q4r0= MIME-Version: 1.0 Received: by 10.100.56.29 with SMTP id e29mr34235ana.129.1306971612287; Wed, 01 Jun 2011 16:40:12 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Wed, 1 Jun 2011 16:40:12 -0700 (PDT) In-Reply-To: References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> Date: Wed, 1 Jun 2011 19:40:12 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: multipart/alternative; boundary=001485f860e6ae946c04a4af0a12 Cc: pkix@ietf.org, Paul Hoffman Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 23:40:14 -0000 --001485f860e6ae946c04a4af0a12 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 1, 2011 at 5:41 PM, Stephen Kent wrote: > At 2:18 PM -0700 6/1/11, Paul Hoffman wrote: > >> On Jun 1, 2011, at 11:28 AM, Stephen Kent wrote: >> >> This proposal is currently targeted as Experimental, which seems >>> appropriate. >>> >> >> We have not yet heard of Phill would want that to be the intended status >> if the WG adopts it. >> > > I assumed Experimental, because that's what the current draft says, but ... I would prefer to work to make a standard. The long term objective was to make this a standard, the unknown being how many iterations on the public spec might be necessary to get it working. There is a possible difference here between the CAA record and the CAA standard that emerges from PKIX. If the WG decides to change the syntax of the record we have to recycle through the DNS world and request a new RR code. If at that point there is a legacy base of CAA records deployed it will probably be necessary to document that as Informational or Experimental for the sake of having a fixed point to refer to. >> My one caveat to PHB is that IF CAA becomes a work item, the final >>> form of the doc will be subject to the usual WG consensus procedures. >>> I have discussed this with Stefan and he concurs. >>> >> Well of course, the whole point of doing this is really about handing over change control. > With that said, if PHB wants PKIX to adopt this work, the co-chairs are >>> amenable. >>> >> >> Earlier, Phill said "I don't think it very likely that we are going to >> want to look at a complete redesign. But I could imagine people have ideas >> for new property tags that could be usefully added." I see likely changes >> between those two poles, and thus still am quite concerned about whether >> this is a good use of WG time. >> > > We need to hear from Phil on this. Given that the origin of PKIX was to develop a profile of an existing ITU standard, I hardly see how our proposal is likely to prove 'too well finished for PKIX to consider worth time'. I have tried to anticipate the type of comments that might arise in the area of 'style' and aligned CAA with PKIX style tropes accordingly: ASN.1, OIDs etc and I have tried to do the necessary prep work on the DNS side. FWIW, I would like to see a protocol based on the idea of "a DNS admin >> tells prospective CAs who should and should not issue certificates for the >> DNS name" done in the IETF under normal IETF protocol development rules. The >> PKIX WG seems like a fine place to do that as long as the CA community >> believes that they are likely to use our output. My concern is that Phill >> has already done a lot of work on a specific manifestation of the idea, >> including the non-trivial task of lining up developers and CAs behind his >> protocol. If they aren't interested in what could easily be a different >> protocol coming from the IETF process, there is no reason for us to spend >> the time on it. > > Well I guess it might be a matter of personal preference, but I prefer that when people make a proposal to be reviewed by 100+ people that they first iterate the proposal a few times amongst a small group of people who are likely to anticipate 80-90% of the issues. The point of the standards process in my view is to document the specification and to hand over change control so that additional use cases can be considered. It is of course necessary to fix any bugs in the spec that are discovered but I have never seen it suggested before that 'insufficient bugs to correct' might be an obstacle to adoption as a standards proposal. Any commercial backing for CAA is for the 'CAA approach' rather than a particular realization thereof. I have of course raised this proposal in CABForum as a forum likely to end up considering future standards layered on top of the CAA approach. But what I said there is that they should consider IETF/PKIX as the venue for the technical discussion and participate directly there. -- Website: http://hallambaker.com/ --001485f860e6ae946c04a4af0a12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 1, 2011 at 5:41 PM, Stephen Kent <kent@bbn.com> wrote:
At 2:18 PM -0700 6/1/11, Paul Hoffman wrote:
On Jun 1, 2011, at 11:28 AM, Stephen Kent wrote:

=A0This proposal is currently targeted as Experimental, which seems
=A0appropriate.

We have not yet heard of Phill would want that to be the intended status if= the WG adopts it.

I assumed Experimental, because that's what the current draft says, but= ...

I would prefer to work to make a stand= ard.=A0

The long term objective was to make this a= standard, the unknown being how many iterations on the public spec might b= e necessary to get it working.


There is a possible difference here betw= een the CAA record and the CAA standard that emerges from PKIX. If the WG d= ecides to change the syntax of the record we have to recycle through the DN= S world and request a new RR code. If at that point there is a legacy base = of CAA records deployed it will probably be necessary to document that as I= nformational or Experimental for the sake of having a fixed point to refer = to.


=A0My one caveat to PHB is that IF CAA becomes a work item, the final
=A0form of the doc will be subject to the usual WG consensus procedures. =A0I have discussed this with Stefan and he concurs.

Well of course, the whole poi= nt of doing this is really about handing over change control.


=A0
=A0With that said, if PHB wants PKIX to adopt this work, the co-chairs are = amenable.

Earlier, Phill said "I don't think it very likely that we are goin= g to want to look at a complete redesign. But I could imagine people have i= deas for new property tags that could be usefully added." I see likely= changes between those two poles, and thus still am quite concerned about w= hether this is a good use of WG time.

We need to hear from Phil on this.

Given th= at the origin of PKIX was to develop a profile of an existing ITU standard,= I hardly see how our proposal is likely to prove 'too well finished fo= r PKIX to consider worth time'.

I have tried to anticipate the type of comments that mi= ght arise in the area of 'style' and aligned CAA with PKIX style tr= opes accordingly: ASN.1, OIDs etc and I have tried to do the necessary prep= work on the DNS side.


FWIW, I would like to see a protocol based on the idea of "a DNS admin= tells prospective CAs who should and should not issue certificates for the= DNS name" done in the IETF under normal IETF protocol development rul= es. The PKIX WG seems like a fine place to do that as long as the CA commun= ity believes that they are likely to use our output. My concern is that Phi= ll has already done a lot of work on a specific manifestation of the idea, = including the non-trivial task of lining up developers and CAs behind his p= rotocol. If they aren't interested in what could easily be a different = protocol coming from the IETF process, there is no reason for us to spend t= he time on it.

Well I guess it might be a matter of= personal preference, but I prefer that when people make a proposal to be r= eviewed by 100+ people that they first iterate the proposal a few times amo= ngst a small group of people who are likely to anticipate 80-90% of the iss= ues.=A0

The point of the standards process in my view is to doc= ument the specification and to hand over change control so that additional = use cases can be considered. It is of course necessary to fix any bugs in t= he spec that are discovered but I have never seen it suggested before that = 'insufficient bugs to correct' might be an obstacle to adoption as = a standards proposal.

Any commercial backing for CAA is for the 'CAA appr= oach' rather than a particular realization thereof.=A0


I have of course raised this proposal in CABForum a= s a forum likely to end up considering future standards layered on top of t= he CAA approach. But what I said there is that they should consider IETF/PK= IX as the venue for the technical discussion and participate directly there= .

--
Website: ht= tp://hallambaker.com/

--001485f860e6ae946c04a4af0a12-- From paul.hoffman@vpnc.org Wed Jun 1 16:53:32 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1E0E0715 for ; Wed, 1 Jun 2011 16:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 QHH-wefb0aDJ for ; Wed, 1 Jun 2011 16:53:32 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 99D29E065B for ; Wed, 1 Jun 2011 16:53:31 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p51NrO4W067789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Jun 2011 16:53:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 1 Jun 2011 16:53:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 23:53:32 -0000 On Jun 1, 2011, at 4:40 PM, Phillip Hallam-Baker wrote: > Well of course, the whole point of doing this is really about handing = over change control. Works for me. I support the PKIX WG adopting as a work item (wording = taken from the CAA draft's text) "DNS Resource Records that allow a DNS = domain name holder to specify the certificate signing certificate(s) = authorized to issue certificates for that domain". --Paul Hoffman From mike-list@pobox.com Wed Jun 1 17:12:47 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70BCE0758; Wed, 1 Jun 2011 17:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 lgYLHiC-vZQR; Wed, 1 Jun 2011 17:12:47 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by ietfa.amsl.com (Postfix) with ESMTP id 0743FE06EB; Wed, 1 Jun 2011 17:12:46 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 354EB5301; Wed, 1 Jun 2011 20:14:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=rAT14u/PnnlT 9njGwwRAjppPf6w=; b=HwzkKa8w9pOi970ZPqVd1J45cSuKi9WkpGFjYcY6zH5T 4DEqnaDsjfXAi5klw7xzFweJob+mlQuhHqdgaH8mLV7JiWYMtRwhc0qtXJ5spZtH vpXoSCkvq/coM9nbZWmzvGkdjz0uDlOApa3lusZk9hZ6KtJhnkf4EUwGVRormxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=M3OkeU u87FlFEX4q9sMWYfPWfQZZFvzj+U3ebiMPVyqzZA8lzjIDzkq7f/TascPgoYnGQe xCq/35aHqLHJPcYHaIq41csuN8V20F2vjbN/pHfAGT5fanbljUr7EXs38F7we24v zMfSBKNtvHo0qvdk1KF7ClTJIHo+xWqKktc+U= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E2B065300; Wed, 1 Jun 2011 20:14:50 -0400 (EDT) Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 1637C52FF; Wed, 1 Jun 2011 20:14:46 -0400 (EDT) Message-ID: <4DE6D575.2000808@pobox.com> Date: Wed, 01 Jun 2011 17:12:37 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Paul Hoffman References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 553A7E4E-8CAD-11E0-BCCC-D6B6226F3D4C-38729857!a-pb-sasl-sd.pobox.com Cc: pkix@ietf.org, TLS Mailing List Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 00:12:48 -0000 Paul Hoffman wrote: > > I support the PKIX WG adopting as a work item (wording taken from the CAA draft's text) "DNS Resource Records that allow a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain". I haven't read the draft, but from the quote it appears that this could improve the weakest part of TLS (as it is used today in browsers) where any of the hundreds of preinstalled root CAs is trusted to issue a certificate to any possible domain name. [CC'ed to the TLS working group] Mike From pgut001@login01.cs.auckland.ac.nz Wed Jun 1 20:54:21 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884C4E06A7 for ; Wed, 1 Jun 2011 20:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugMWUnL8Oey6 for ; Wed, 1 Jun 2011 20:54:21 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id BA568E0676 for ; Wed, 1 Jun 2011 20:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1306986861; x=1338522861; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20dcarella@linagora.com,=20pkix@ietf.org|Subject:=20 Re:=20[pkix]=20Best=20practices=20for=20Certificate=20Pol icy=20OIDs=20in=20certificates|In-Reply-To:=20<4DE645E7.4 000909@linagora.com>|Message-Id:=20|Date:=20Thu,=2002=20Jun=202011 =2015:54:17=20+1200; bh=NMU7mZHzuShGHrtl+u8UvPu0qlZ2jpfULyL3Vhtx1SE=; b=TvNfCAQ+kl4B9yBtWeUX6L3cGoxduFkRybMrCFy/QB+Yhzi4GxPqpPNa gLzTTUKJthGQvjoIPkmJlx1ZLeM4nrivhmfdQ8TeOywrsqF9sEdcuznxU iOCW3nzuuiVwcPVO8UpVdcp6Bht8EEc0W0m95NZPoWoY1VUM2TplnDWRJ o=; X-IronPort-AV: E=Sophos;i="4.65,307,1304251200"; d="scan'208";a="65190582" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Jun 2011 15:54:17 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QRyzB-0008VD-Hp; Thu, 02 Jun 2011 15:54:17 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QRyzB-0000sP-Ej; Thu, 02 Jun 2011 15:54:17 +1200 From: Peter Gutmann To: dcarella@linagora.com, pkix@ietf.org In-Reply-To: <4DE645E7.4000909@linagora.com> Message-Id: Date: Thu, 02 Jun 2011 15:54:17 +1200 Subject: Re: [pkix] Best practices for Certificate Policy OIDs in certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 03:54:21 -0000 David CARELLA writes: >Nobody to answer my questions? I think the reason no-one's replied is because the answer is "that's a policy matter". So you need to formulate a policy as to which policy you want to follow. Peter. From ynir@checkpoint.com Wed Jun 1 21:10:59 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE6AE068F; Wed, 1 Jun 2011 21:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.979 X-Spam-Level: X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 nYv4ApGYkawW; Wed, 1 Jun 2011 21:10:57 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 98CC1E0676; Wed, 1 Jun 2011 21:10:56 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p524AriS024146; Thu, 2 Jun 2011 07:10:53 +0300 X-CheckPoint: {4DE719E9-0-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 2 Jun 2011 07:10:53 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 2 Jun 2011 07:10:53 +0300 From: Yoav Nir To: "Michael D'Errico" Date: Thu, 2 Jun 2011 07:10:52 +0300 Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item Thread-Index: Acwg2w/ucXVWFeMOTFGqsb86yZzLiQ== Message-ID: <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4DE6D575.2000808@pobox.com> In-Reply-To: <4DE6D575.2000808@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , Paul Hoffman , TLS Mailing List Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 04:10:59 -0000 On Jun 2, 2011, at 3:12 AM, Michael D'Errico wrote: > Paul Hoffman wrote: >>=20 >> I support the PKIX WG adopting as a work item (wording taken from the CA= A draft's text) "DNS Resource Records that allow a DNS domain name holder t= o specify the certificate signing certificate(s) authorized to issue certif= icates for that domain". >=20 > I haven't read the draft, but from the quote it appears that > this could improve the weakest part of TLS (as it is used > today in browsers) where any of the hundreds of preinstalled > root CAs is trusted to issue a certificate to any possible > domain name. I'm not opposed to this draft, but I don't think it solves this problem. Th= e issue is not even the dozens of pre-installed root CAs, but that those ro= ot CAs can have many many affiliates, whether they're sub-CAs or registrati= on authorities.=20 The two famous attacks of the last two years have not been about Verisign o= r Comodo. The "MD5 sub-CA" was issued by RapidSSL, which is part of the "Ve= risign trust network" but not Verisign itself. In the recent case it was a = small Italian RA. In both cases the problem was an affiliate with not quite= best practices that caused the mis-issue. CAA works if all root CAs and affiliates follow it. That's hundreds or thou= sands of entities. Any one of them that fails to comply might ignore the CA= A record. PHB says that having the CAA record may aid in assigning blame, and thus pe= rhaps at some point, liability. Remains to be seen, but at least in the sho= rt term, CAA is not a panacea. That's why I believe that the DANE record that is aimed at relying parties = is a necessary complement to this work. I know I've said the opposite on th= e DANE list, but I've changed my mind since then. Yoav= From peter.sylvester@edelweb.fr Thu Jun 2 00:32:08 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E726E076D for ; Thu, 2 Jun 2011 00:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 7auuH3HzjMgm for ; Thu, 2 Jun 2011 00:32:07 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 464E7E071D for ; Thu, 2 Jun 2011 00:32:06 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id CE4FB83B1 for ; Thu, 2 Jun 2011 09:32:04 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 97D3716F69 for ; Thu, 2 Jun 2011 09:32:04 +0200 (CEST) Received: from [78.251.50.209] (unknown [78.251.50.209]) by smtps.on-x.com (Postfix) with ESMTP id 921F6782B for ; Thu, 2 Jun 2011 09:32:04 +0200 (CEST) Message-ID: <4DE73C74.3040701@edelweb.fr> Date: Thu, 02 Jun 2011 09:32:04 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [pkix] Best practices for Certificate Policy OIDs in certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 07:32:08 -0000 On 06/02/2011 05:54 AM, Peter Gutmann wrote: > David CARELLA writes: > >> Nobody to answer my questions? > I think the reason no-one's replied is because the answer is "that's a = policy > matter". So you need to formulate a policy as to which policy you want= to > follow. no, I missed the message: there is no such thing as a different policy identifier "for" a CA certif= icate. policy identifier in an (intermediate) CA certificat are a filter set by the superior CA to indicate the list of EE certficate policies that are recognized as compatible which the superCA environment. putting "anypolicy" somewhere indicates essentially that you accept everything. Sub CA 2: Certificate policy: - policyIdentifier: anyPolicy [2.5.29.32.0] - policyQualifiers: - cPSuri: URI End entity: Certificate policy: - policyIdentifier: OID (OID-2) as in this example, the anypolicy permits that OUI-2 works, but only if your initial policy set contains well, left as an exercise. (c) user-initial-policy-set: A set of certificate policy identifiers naming the policies that are acceptable to the certificate user. The user-initial-policy-set contains the special value any-policy if the user is not concerned about certificate policy. the reason for trying to have an OID for a CA is a very common misunderstanding in several policy documents which confused the OIDs that one puts into certificates which an identification of a document (seen as "Identification: oid" in te beginning of a policy statement, or as other OIDs describing documents with practices. In particular, the French "PC type"s is wrong: it says that you write in a policy statement "Le num=E9ro d=92OID du pr=E9sent document est xxxx" "the OID number of the present document is xxxx" which is not wrong by itself, but then it specifies that it this number that you put into a certificate that you issue. as a consequence, when people write "policy statement documents" for CAs which is not an unreasonable thing, it is a diffrent document, it has some OID, and well, one wants to put it into CA certificates ... into a place which is not designed for that. in such a CA "policy document", one has to write something like "this CA recognises the following policies (list of OID)" these OIDs are those that are put into EE certs of recognized CAs. to resume the confusion: a "policy oid" and an OID used to classify a "(policy) document" are different things and unrelated. Peter PS: 2 David: greetings to William From hallam@gmail.com Thu Jun 2 06:46:03 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E26DE06E3; Thu, 2 Jun 2011 06:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] 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 vYIPQhYy6uF7; Thu, 2 Jun 2011 06:46:02 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5DEE0692; Thu, 2 Jun 2011 06:46:02 -0700 (PDT) Received: by gxk19 with SMTP id 19so430784gxk.31 for ; Thu, 02 Jun 2011 06:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=prU8UQTtRwAzI3BDjsYM/Ug4VIvCMuieUEGebFRtEHY=; b=TMT5ipF/YktJ+C0csbz/P5iFCZY97f4lJtv3OSb2g+ETO/UAWNwCm0Qm5Hu1SFWW4R iAd9aeMkOKCO5PIqBrSgKbgQK7V30zJkip3hklge6vw0BTb2a1L3tISvBUtf0fu4lMpZ YDBvH8JCi59GuS6EZFPJKiV27jfagCySD4e9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xZOJmv0f8jYzU9Wnj+EDu4V1XwhGYwLkTrOQxLoSFiayi1G8oB+q9hQAeGiAsXRQNB zkCf4IJhrR+syeNgOoRQI++gdsAluwco8LfkccVpSqmZNd+afp08Ed2gWV/4D62Gmt8D FgHMAvH2UFf2rUnlObrCjIjLG7gIiIvyxPrtI= MIME-Version: 1.0 Received: by 10.101.11.14 with SMTP id o14mr461549ani.88.1307022358736; Thu, 02 Jun 2011 06:45:58 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Thu, 2 Jun 2011 06:45:58 -0700 (PDT) In-Reply-To: <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4DE6D575.2000808@pobox.com> <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> Date: Thu, 2 Jun 2011 09:45:58 -0400 Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: multipart/alternative; boundary=0016e68fcec467efc004a4badb85 Cc: "pkix@ietf.org" , Paul Hoffman , TLS Mailing List Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 13:46:03 -0000 --0016e68fcec467efc004a4badb85 Content-Type: text/plain; charset=ISO-8859-1 That is not quite right. First off, measurement of the failure rate of CAs is rather difficult because we only actually know the failure rate for CAs that self-report. It is not zero but it is close enough to being zero that people can work themselves up into a lather about it. At the end of the day buffer over-run exploits will still trump any deficiencies in the CA infrastructure. But those don't have people running round suggesting urgent remedies because they are too common to bear notice. CAs and RAs are definitely not the weakest link in the chain here. Anyone claiming that is either grandstanding or has failed to pay attention. But more importantly, an RA does not have issuing power by definition. Only a CA can issue certificates because that is the definition of a CA. The intention of CAA is that it be enforced by the CA so that an RA cannot issue a non compliant cert either. One area where I could see a possible use case for extending CAA would be to enable better RA management controls. For example the vast majority of the 'RAs' identified in the EFF study are actually intermediate roots assigned to RAs at educational institutions. Such RAs only have general issuing powers in a minority of circumstances. We had some discussion of this after my SAAG presentation. Here is the issue: some of these controls will be technical and some will be policy. Some of these controls will be the type of thing IETF likes to work on and some will not. That is why we have CABForum. And then another question that naturally comes up is how much of this we should do in phase 1 and whether we should attempt to do everything at once or to do the lowest of the low hanging fruit first, gain some experience and then add in features to support additional use cases. The final point made is that some CAs may not want to support CAA. I can't see why this would be so unless either: 1) The technology is deficient (something PKIX might fix). 2) They really want to be able to issue fraudulent certificates. 3) They resist change for the sake of it. 4) It is not yet an IETF standard Now I have no idea which of the above might apply if any. But the only way to find out is going to be to deploy. This is still a worthwhile exercise if the only effect is to identify CAs that wish to issue fraudulent certificates. The IETF does not have the power to police such CAs but others do. On Thu, Jun 2, 2011 at 12:10 AM, Yoav Nir wrote: > > On Jun 2, 2011, at 3:12 AM, Michael D'Errico wrote: > > > Paul Hoffman wrote: > >> > >> I support the PKIX WG adopting as a work item (wording taken from the > CAA draft's text) "DNS Resource Records that allow a DNS domain name holder > to specify the certificate signing certificate(s) authorized to issue > certificates for that domain". > > > > I haven't read the draft, but from the quote it appears that > > this could improve the weakest part of TLS (as it is used > > today in browsers) where any of the hundreds of preinstalled > > root CAs is trusted to issue a certificate to any possible > > domain name. > > I'm not opposed to this draft, but I don't think it solves this problem. > The issue is not even the dozens of pre-installed root CAs, but that those > root CAs can have many many affiliates, whether they're sub-CAs or > registration authorities. > > The two famous attacks of the last two years have not been about Verisign > or Comodo. The "MD5 sub-CA" was issued by RapidSSL, which is part of the > "Verisign trust network" but not Verisign itself. In the recent case it was > a small Italian RA. In both cases the problem was an affiliate with not > quite best practices that caused the mis-issue. > > CAA works if all root CAs and affiliates follow it. That's hundreds or > thousands of entities. Any one of them that fails to comply might ignore the > CAA record. > > PHB says that having the CAA record may aid in assigning blame, and thus > perhaps at some point, liability. Remains to be seen, but at least in the > short term, CAA is not a panacea. > > That's why I believe that the DANE record that is aimed at relying parties > is a necessary complement to this work. I know I've said the opposite on the > DANE list, but I've changed my mind since then. > > Yoav > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Website: http://hallambaker.com/ --0016e68fcec467efc004a4badb85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is not quite right.

First off, measurement of the f= ailure rate of CAs is rather difficult because we only actually know the fa= ilure rate for CAs that self-report. It is not zero but it is close enough = to being zero that people can work themselves up into a lather about it.=A0=

At the end of the day buffer over-run exploits will sti= ll trump any deficiencies in the CA infrastructure. But those don't hav= e people running round suggesting urgent remedies because they are too comm= on to bear notice. CAs and RAs are definitely not the weakest link in the c= hain here. Anyone claiming that is either grandstanding or has failed to pa= y attention.


But more importantly, an RA does not hav= e issuing power by definition. Only a CA can issue certificates because tha= t is the definition of a CA. The intention of CAA is that it be enforced by= the CA so that an RA cannot issue a non compliant cert either.

One area where I could see a possible use case for exte= nding CAA would be to enable better RA management controls. For example the= vast majority of the 'RAs' identified in the EFF study are actuall= y intermediate roots assigned to RAs at educational institutions. Such RAs = only have general issuing powers in a minority of circumstances.

We had some discussion of this after my SAAG presentati= on.

Here is the issue: some of these controls will= be technical and some will be policy. Some of these controls will be the t= ype of thing IETF likes to work on and some will not. That is why we have C= ABForum.

And then another question that naturally comes up is ho= w much of this we should do in phase 1 and whether we should attempt to do = everything at once or to do the lowest of the low hanging fruit first, gain= some experience and then add in features to support additional use cases.<= /div>


The final point made is that some CAs ma= y not want to support CAA. I can't see why this would be so unless eith= er:

1) The technology is deficient (something PKIX= might fix).
2) They really want to be able to issue fraudulent certificates.
=
3) They resist change for the sake of it.
4) It is not yet a= n IETF standard

Now I have no idea which of the ab= ove might apply if any. But the only way to find out is going to be to depl= oy.=A0

This is still a worthwhile exercise if the only effect = is to identify CAs that wish to issue fraudulent certificates. The IETF doe= s not have the power to police such CAs but others do.


On Thu, Jun 2, 2011 at 12:10 AM, Yoav N= ir <ynir@checkp= oint.com> wrote:

On Jun 2, 2011, at 3:12 AM, Michael D'Errico wrote:

> Paul Hoffman wrote:
>>
>> I support the PKIX WG adopting as a work item (wording taken from = the CAA draft's text) "DNS Resource Records that allow a DNS domai= n name holder to specify the certificate signing certificate(s) authorized = to issue certificates for that domain".
>
> I haven't read the draft, but from the quote it appears that
> this could improve the weakest part of TLS (as it is used
> today in browsers) where any of the hundreds of preinstalled
> root CAs is trusted to issue a certificate to any possible
> domain name.

I'm not opposed to this draft, but I don't think it sol= ves this problem. The issue is not even the dozens of pre-installed root CA= s, but that those root CAs can have many many affiliates, whether they'= re sub-CAs or registration authorities.

The two famous attacks of the last two years have not been about Verisign o= r Comodo. The "MD5 sub-CA" was issued by RapidSSL, which is part = of the "Verisign trust network" but not Verisign itself. In the r= ecent case it was a small Italian RA. In both cases the problem was an affi= liate with not quite best practices that caused the mis-issue.

CAA works if all root CAs and affiliates follow it. That's hundreds or = thousands of entities. Any one of them that fails to comply might ignore th= e CAA record.

PHB says that having the CAA record may aid in assigning blame, and thus pe= rhaps at some point, liability. Remains to be seen, but at least in the sho= rt term, CAA is not a panacea.

That's why I believe that the DANE record that is aimed at relying part= ies is a necessary complement to this work. I know I've said the opposi= te on the DANE list, but I've changed my mind since then.

Yoav
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls



--
Website: http://hallambaker.com/

--0016e68fcec467efc004a4badb85-- From kent@bbn.com Thu Jun 2 07:03:11 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8957AE0788 for ; Thu, 2 Jun 2011 07:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.407 X-Spam-Level: X-Spam-Status: No, score=-106.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 gvIaBLV-EE8I for ; Thu, 2 Jun 2011 07:03:10 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id BDD14E0780 for ; Thu, 2 Jun 2011 07:03:10 -0700 (PDT) Received: from dhcp89-089-178.bbn.com ([128.89.89.178]:49425) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QS8UQ-000MXf-8G; Thu, 02 Jun 2011 10:03:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> Date: Thu, 2 Jun 2011 10:03:06 -0400 To: Phillip Hallam-Baker From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 14:03:11 -0000 Phil, Thanks for your thorough reply. Given the other positive responses, I'm happy to adopt the CAA concept as a PKIX work item, with the intent that the target status is standards track, even if an experimental version is issued first. Fell free to submit as a PKIX 00, and Stefan or I will approve (he said as he headed off on vacation for a week ...). Steve From stefan@aaa-sec.com Thu Jun 2 07:19:22 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E37E078C for ; Thu, 2 Jun 2011 07:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.21 X-Spam-Level: X-Spam-Status: No, score=-102.21 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_21=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 gV02SWvoBH6a for ; Thu, 2 Jun 2011 07:19:22 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfa.amsl.com (Postfix) with ESMTP id A1578E0787 for ; Thu, 2 Jun 2011 07:19:20 -0700 (PDT) Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D35CE455FEA for ; Thu, 2 Jun 2011 16:19:24 +0200 (CEST) Received: (qmail 63756 invoked from network); 2 Jun 2011 14:19:19 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.205]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 2 Jun 2011 14:19:19 -0000 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 02 Jun 2011 16:19:16 +0200 From: Stefan Santesson To: Peter Sylvester , Message-ID: Thread-Topic: [pkix] Best practices for Certificate Policy OIDs in certificates In-Reply-To: <4DE73C74.3040701@edelweb.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [pkix] Best practices for Certificate Policy OIDs in certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 14:19:22 -0000 As Peter says, Adding to that is that there is a common false thought that the policy in a CA:s certificate is a statement by that CA, while in fact it is a statement by the CA above. There are no reasons for practices used to issue CA certificates to be represented as a policy OID. Such OID has no function in RFC 5280 path validation. So simplified: A CA may put a policy OID in the certificates they issue. The semantics this carry is: 1) If the issued certificate is a CA certificate: "Only the listed policies can be validated in certificates issued under this CA" 2) If the issued certificate is an EE certificate: "Only the listed policies can be valid for this certificate" A complicating fact is that the policy mechanism was originally designed to be a usability declaration and not a full statement about the procedures under which this certificate was issued. For the original purpose, the path validation processing rules are logical. It has become very confusing as the policy OID has become more of a statement about issuing procedures. It has caused CA certificate to carry policy OID that has nothing to do with usage of EE certificates, and this is in total conflict with RFC 5280 path validation. /Stefan On 11-06-02 9:32 AM, "Peter Sylvester" wrote: >On 06/02/2011 05:54 AM, Peter Gutmann wrote: >> David CARELLA writes: >> >>> Nobody to answer my questions? >> I think the reason no-one's replied is because the answer is "that's a >>policy >> matter". So you need to formulate a policy as to which policy you want >>to >> follow. >no, I missed the message: > >there is no such thing as a different policy identifier "for" a CA >certificate. >policy identifier in an (intermediate) CA certificat are a filter set by >the superior CA to indicate the list of EE certficate policies that >are recognized as compatible which the superCA environment. > >putting "anypolicy" somewhere indicates essentially that you accept >everything. > >Sub CA 2: Certificate policy: >- policyIdentifier: anyPolicy [2.5.29.32.0] >- policyQualifiers: - cPSuri: URI > >End entity: Certificate policy: >- policyIdentifier: OID (OID-2) > >as in this example, the anypolicy permits that OUI-2 works, >but only if your initial policy set contains well, left as >an exercise. > > (c) user-initial-policy-set: A set of certificate policy > identifiers naming the policies that are acceptable to the > certificate user. The user-initial-policy-set contains the > special value any-policy if the user is not concerned about > certificate policy. > >the reason for trying to have an OID for a CA is a >very common misunderstanding in several policy documents >which confused the OIDs that one puts into certificates which >an identification of a document (seen as "Identification: oid" >in te beginning of a policy statement, or as other OIDs describing >documents with practices. > >In particular, the French "PC type"s is wrong: > >it says that you write in a policy statement > >"Le num=E9ro d=B9OID du pr=E9sent document est xxxx" >"the OID number of the present document is xxxx" > >which is not wrong by itself, but then it specifies that it >this number that you put into a certificate that you issue. >as a consequence, when people write >"policy statement documents" for CAs which is not an >unreasonable thing, it is a diffrent document, >it has some OID, and well, one wants to put it into >CA certificates ... into a place which is not designed for that. > >in such a CA "policy document", one has to write something like >"this CA recognises the following policies (list of OID)" >these OIDs are those that are put into EE certs of >recognized CAs. > >to resume the confusion: > >a "policy oid" and an OID used to classify a "(policy) document" >are different things and unrelated. > >Peter >PS: >2 David: greetings to William > > > > > > > > > > > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From ynir@checkpoint.com Thu Jun 2 08:40:16 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573B8E07CC; Thu, 2 Jun 2011 08:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.53 X-Spam-Level: X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Z4Zq6YCy7-K3; Thu, 2 Jun 2011 08:40:15 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C1F95E06FD; Thu, 2 Jun 2011 08:40:14 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p52FeBKR008989; Thu, 2 Jun 2011 18:40:11 +0300 X-CheckPoint: {4DE7BB74-17-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 2 Jun 2011 18:40:11 +0300 From: Yoav Nir To: Phillip Hallam-Baker Date: Thu, 2 Jun 2011 18:37:36 +0300 Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item Thread-Index: AcwhO1t+ULi0hC8VSoeVpXSIgYhHIw== Message-ID: <7043B742-0AAA-4875-8642-764E7F41DFD5@checkpoint.com> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4DE6D575.2000808@pobox.com> <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , Paul Hoffman , TLS Mailing List Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 15:40:16 -0000 On Jun 2, 2011, at 4:45 PM, Phillip Hallam-Baker wrote: >=20 > The final point made is that some CAs may not want to support CAA. I can'= t see why this would be so unless either: >=20 > 1) The technology is deficient (something PKIX might fix). > 2) They really want to be able to issue fraudulent certificates. > 3) They resist change for the sake of it. > 4) It is not yet an IETF standard >=20 > Now I have no idea which of the above might apply if any. But the only wa= y to find out is going to be to deploy.=20 I can offer a couple of others 5) They're too lazy to care 6) It's cheaper to not do anything than to do something In late 2008, when some researchers got RapidSSL to sign a certificate requ= est that collided with their rogue sub-CA certificate, several things came = to light: - They were using MD5 10 years after RFC 2459 recommended not to - They were a ridiculously small company, with the only full-time employee= . An accountant - They were doing a bunch of other "industry worst practices" - every fiel= d in the certificate was predictable The root problem is that the RapidSSLs of the world issue certificates that= are considered by browsers to be just as valid as any DV certificate issue= d by responsible CAs. So getting a certificate that validates is as easy as= getting a rogue certificate from the worst CA or sub-CA. And with so many = to choose from, I'm sure it will be possible to find one that didn't implem= ent CAA correctly. It's still worthwhile, IMO. Because maybe that particular CA that implement= ed CAA wrong is not using MD5, or maybe they have some other security mecha= nism done right. It may very well help thwart the next researcher or hacker= . I just don't think it's the ultimate solution to the "weakest link" probl= em. Yoav From marsh@extendedsubset.com Thu Jun 2 09:07:11 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1408E07F9; Thu, 2 Jun 2011 09:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Xmx-gJq8w1Xz; Thu, 2 Jun 2011 09:07:11 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 57CABE07CC; Thu, 2 Jun 2011 09:07:11 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QSAQP-0004oW-76; Thu, 02 Jun 2011 16:07:09 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AB72E606D; Thu, 2 Jun 2011 16:07:06 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18ZaeEObNEyW+qN1tQpVBHZRJYsUTihz8k= Message-ID: <4DE7B529.9040206@extendedsubset.com> Date: Thu, 02 Jun 2011 11:07:05 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4DE6D575.2000808@pobox.com> <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" , Paul Hoffman , TLS Mailing List Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 16:07:12 -0000 On 06/02/2011 08:45 AM, Phillip Hallam-Baker wrote: > > At the end of the day buffer over-run exploits will still trump any > deficiencies in the CA infrastructure. But those don't have people > running round suggesting urgent remedies because they are too common to > bear notice. CAs and RAs are definitely not the weakest link in the > chain here. Anyone claiming that is either grandstanding or has failed > to pay attention. Well that depends entirely on the chain in question doesn't it? Not everything that uses TLS or certificates is an unpatched web browser with Adobe plugins operated by an ignorant user for the purpose of securing nothing particularly important. Over time it becomes increasingly difficult for _any_ distributed application to run over ports other than TCP 443 due to the growth of egress filtering. So stuff is bundled in with web traffic that may, in fact, be implemented for high security requirements. Perhaps a solution is to implement your own application-specific trust root that doesn't rely on the current profusion of CAs. But as an application developer I can attest to the fact that it's difficult to use standard platform TLS libraries without also trusting everything in the system root store, too. Some sites will insist on using their own in-house CAs too, which is fine, but it's further pressure on everything else to integrate/be vulnerable with the browser trust model. The net security world has changed dramatically over the last couple of years. We have to move past this broken-browser-as-least-common-denominator mentality. - Marsh From hallam@gmail.com Thu Jun 2 09:31:20 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF1EE07FC; Thu, 2 Jun 2011 09:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HD5Nc-FXcVkN; Thu, 2 Jun 2011 09:31:18 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80BBDE07FA; Thu, 2 Jun 2011 09:31:15 -0700 (PDT) Received: by gxk19 with SMTP id 19so515766gxk.31 for ; Thu, 02 Jun 2011 09:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d3H1o1MfWU+6RcBf8CWGxD6qvH6V0IkUT3snbqlwYyI=; b=N32MUR3BOUl4OhXzElbn2wL9zWCKXXFF6igVeYkiiER5fZ1kjfes7kTlys2xfQYjGS 7wS/RO3esjrANTvAMjyBcC/EBQxv0BNdoIpAY4IA9WsyNJOZ0FT4DCaK4cVzAOwSRSXp SBYRywXMHeGwg44Z4D9BhkuUGQIb8dnQg/Bcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=szE0GcwzrvDGP22jEkpvht7JN3bDzsXG+FBNO33WkrJ/fbd/J8fTrSV7f/5Vyp2d2w mlEQ4EWbjEOcvfkq1DCvu4DUKZyyY2oTQKtHPXGcVx/zbgMIwX4A9FGKMAjZwYZF6f97 Mt5D9VfVtDsV+7nRb1gX+ciEIR7mah0HqusfQ= MIME-Version: 1.0 Received: by 10.101.74.10 with SMTP id b10mr590618anl.107.1307032273119; Thu, 02 Jun 2011 09:31:13 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Thu, 2 Jun 2011 09:31:13 -0700 (PDT) In-Reply-To: <4DE7B529.9040206@extendedsubset.com> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4DE6D575.2000808@pobox.com> <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> <4DE7B529.9040206@extendedsubset.com> Date: Thu, 2 Jun 2011 12:31:13 -0400 Message-ID: From: Phillip Hallam-Baker To: Marsh Ray Content-Type: multipart/alternative; boundary=0016368e1f855969d804a4bd2a38 Cc: "pkix@ietf.org" , Paul Hoffman , TLS Mailing List Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 16:31:20 -0000 --0016368e1f855969d804a4bd2a38 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 2, 2011 at 12:07 PM, Marsh Ray wrote: > On 06/02/2011 08:45 AM, Phillip Hallam-Baker wrote: > >> >> At the end of the day buffer over-run exploits will still trump any >> deficiencies in the CA infrastructure. But those don't have people >> running round suggesting urgent remedies because they are too common to >> bear notice. CAs and RAs are definitely not the weakest link in the >> chain here. Anyone claiming that is either grandstanding or has failed >> to pay attention. >> > > Well that depends entirely on the chain in question doesn't it? > > Not everything that uses TLS or certificates is an unpatched web browser > with Adobe plugins operated by an ignorant user for the purpose of securing > nothing particularly important. > I hear you. But lets be realistic here, we are currently actually doing worse for non browser security. The weakest link in the TLS protocol is actually the end user who is for some bizarre reason expected to be looking for padlock icons and green bars and know when to look for which one. This is even more problematic when applying TLS to Web services as there isn't even a user to make the decision and no real idea of what should do that instead. CAA is not going to solve every problem associated with trust on the Internet and CA infrastructure. Nor is TLS and nor is strict security. But I do think that a combination of those three ideas can make a major step forward. That is why CAA is designed to be arbitrarily extensible with a tag-value format even though there are only two property tags currently defined. I really like the work that Paypal and Jeff Hodges have been doing and would like to have a way to eventually bring CAA into alignment there. But for the moment we have to avoid 'crossing the streams' as Stephen F. put it to me. Lets work on the part of the problem that we can while the Web Security folk work on understanding the complexities of what strict security involves. > Perhaps a solution is to implement your own application-specific trust root > that doesn't rely on the current profusion of CAs. But as an application > developer I can attest to the fact that it's difficult to use standard > platform TLS libraries without also trusting everything in the system root > store, too. Some sites will insist on using their own in-house CAs too, > which is fine, but it's further pressure on everything else to integrate/be > vulnerable with the browser trust model. > Yes and that may well end up motivating a mechanism to allow for protocol specific path properties so that enterprises can have separate CAs authorized for separate protocols. Web Services security is a big part of what I am interested in supporting here. We went into the Web Services world with certain interests promoting UDDI as the central directory to make it all work. So now we have a protocol stack predicated on the existence of a directory with no directory to work with. I have some ideas there, but again, that would be crossing the streams at this point. I think the way to get traction there will be to propose a Web Service application with some pretty severe security requirements and make that the test application for a framework designed to 'do it right'. -- Website: http://hallambaker.com/ --0016368e1f855969d804a4bd2a38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 2, 2011 at 12:07 PM, Marsh R= ay <marsh@= extendedsubset.com> wrote:
On 06/02/2011 08:45 AM, Phillip Hallam-Baker wrote:

At the end of the day buffer over-run exploits will still trump any
deficiencies in the CA infrastructure. But those don't have people
running round suggesting urgent remedies because they are too common to
bear notice. CAs and RAs are definitely not the weakest link in the
chain here. Anyone claiming that is either grandstanding or has failed
to pay attention.

Well that depends entirely on the chain in question doesn't it?

Not everything that uses TLS or certificates is an unpatched web browser wi= th Adobe plugins operated by an ignorant user for the purpose of securing n= othing particularly important.

I hear y= ou.

But lets be realistic here, we are currently actually d= oing worse for non browser security.=A0

The weakes= t link in the TLS protocol is actually the end user who is for some bizarre= reason expected to be looking for padlock icons and green bars and know wh= en to look for which one.

This is even more problematic when applying TLS to Web = services as there isn't even a user to make the decision and no real id= ea of what should do that instead.


CAA is not going to solve every problem associated with trust on the Intern= et and CA infrastructure. Nor is TLS and nor is strict security. But I do t= hink that a combination of those three ideas can make a major step forward.=

That is why CAA is designed to be arbitrarily extensibl= e with a tag-value format even though there are only two property tags curr= ently defined. I really like the work that Paypal and Jeff Hodges have been= doing and would like to have a way to eventually bring CAA into alignment = there.


But for the moment we have to avoid '= ;crossing the streams' as Stephen F. put it to me.=A0

Lets work on the part of the problem that we can while the Web Secu= rity folk work on understanding the complexities of what strict security in= volves.


=A0
Perhaps a solution is to implement your own application-specific trust root= that doesn't rely on the current profusion of CAs. But as an applicati= on developer I can attest to the fact that it's difficult to use standa= rd platform TLS libraries without also trusting everything in the system ro= ot store, too. Some sites will insist on using their own in-house CAs too, = which is fine, but it's further pressure on everything else to integrat= e/be vulnerable with the browser trust model.

Yes and that may well end up motivating a = mechanism to allow for protocol specific path properties so that enterprise= s can have separate CAs authorized for separate protocols.=A0
Web Services security is a big part of what I am interested in s= upporting here. We went into the Web Services world with certain interests = promoting UDDI as the central directory to make it all work. So now we have= a protocol stack predicated on the existence of a directory with no direct= ory to work with.


I have some ideas there, but again, that= would be crossing the streams at this point. I think the way to get tracti= on there will be to propose a Web Service application with some pretty seve= re security requirements and make that the test application for a framework= designed to 'do it right'.=A0

--0016368e1f855969d804a4bd2a38-- From hallam@gmail.com Thu Jun 2 13:23:11 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CB2E0833 for ; Thu, 2 Jun 2011 13:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ckKiJc64a1G4 for ; Thu, 2 Jun 2011 13:23:10 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 05CAFE0674 for ; Thu, 2 Jun 2011 13:23:06 -0700 (PDT) Received: by vxg33 with SMTP id 33so1207664vxg.31 for ; Thu, 02 Jun 2011 13:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4+asWo5nT1NQ2UwR2OhBLYUdsN0pj1A14YSNXkebnDQ=; b=PG7Kk3xJeJcxLYNgo8i98ZBux1tqHg40dMU5IkYwPwrwIYL3TmJoOWPVriFuS5h3tR OSqNyz7KAO2P1KwSphahJ9JRG9RSQczev9JZhrENEHooDbx1E+m9jBL3rBocK+qWq9yL K0WzsftmW9NKkHCMs7+3QcXuKuYWyTwILWZPY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nxKSiKw6kyhg+9TEE4BLIbH4nNpE1544RamCBCLigm7FqOhYR7fcSaRc0IP9WecfRm TBGQ7oUu9XKuxv8/K8x+QBf1PjHP3WhJjzOx4rjVODddTksbIQoz5gI23SnJ0GJhLlId /TPWS/LzIjniIyPGvIGbChzzUk2wh0DgbOjV8= MIME-Version: 1.0 Received: by 10.52.112.69 with SMTP id io5mr1533101vdb.94.1307046185201; Thu, 02 Jun 2011 13:23:05 -0700 (PDT) Received: by 10.52.182.65 with HTTP; Thu, 2 Jun 2011 13:23:05 -0700 (PDT) In-Reply-To: References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> Date: Thu, 2 Jun 2011 16:23:05 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: multipart/alternative; boundary=bcaec548a9f192eebc04a4c067c3 Cc: pkix@ietf.org Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 20:23:11 -0000 --bcaec548a9f192eebc04a4c067c3 Content-Type: text/plain; charset=ISO-8859-1 OK, it is submitted and waiting first draft approval. Changes in this version from donotissue-03 are: * Rights are now Trust (IETF now has change control) * Target is Standard track * Name is changed to draft-ietf-pkix-caa-00 If anything else has changed it is a mistake. On Thu, Jun 2, 2011 at 10:03 AM, Stephen Kent wrote: > Phil, > > Thanks for your thorough reply. Given the other positive responses, I'm > happy to adopt the CAA concept as a PKIX work item, with the intent that > the target status is standards track, even if an experimental version is > issued first. > > Fell free to submit as a PKIX 00, and Stefan or I will approve (he said > as he headed off on vacation for a week ...). > > Steve > > -- Website: http://hallambaker.com/ --bcaec548a9f192eebc04a4c067c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK, it is submitted and waiting first draft approval.

Ch= anges in this version from donotissue-03 are:

* Ri= ghts are now Trust (IETF now has change control)
* Target is Stan= dard track
* Name is changed to draft-ietf-pkix-caa-00

--bcaec548a9f192eebc04a4c067c3-- From paul.hoffman@vpnc.org Thu Jun 2 14:18:12 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FE5E0832 for ; Thu, 2 Jun 2011 14:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 1RPbe8bj3Jpc for ; Thu, 2 Jun 2011 14:18:11 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 37603E0664 for ; Thu, 2 Jun 2011 14:18:11 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p52LI2XE037760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Jun 2011 14:18:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 2 Jun 2011 14:18:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4992780E-FEB3-439F-9A16-B8EEC2A98429@vpnc.org> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:18:12 -0000 On Jun 2, 2011, at 1:23 PM, Phillip Hallam-Baker wrote: > OK, it is submitted and waiting first draft approval. >=20 > Changes in this version from donotissue-03 are: >=20 > * Rights are now Trust (IETF now has change control) > * Target is Standard track > * Name is changed to draft-ietf-pkix-caa-00 >=20 >=20 > If anything else has changed it is a mistake. >=20 You didn't remove section 2.3 and the related material that conflicts = with the DANE WG? --Paul Hoffman From matt@mattmccutchen.net Thu Jun 2 14:22:04 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EFFE08CD for ; Thu, 2 Jun 2011 14:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 e4CRSuGVqtcB for ; Thu, 2 Jun 2011 14:22:03 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 30794E0664 for ; Thu, 2 Jun 2011 14:22:03 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id BC848348072; Thu, 2 Jun 2011 14:22:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=E2OUs1AoRvvlGbNUMPx6P0noBfhyfjeZS05b4bEu3l5 AUvoSfm7aPS1rz82d1OgawaIjyPH2aG83vg5YL5zRKGhePyx4wqMOWtKbHIvKmaL znzdqPH2QRGJQfok2owOVe1hoNPb3ZQ1XQ7C9WuRsEWPe/35/9cwBK83/GWmXQiA = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=DudECWAyR3i22b5rwRQrAwL3rTg=; b=TJdNXdibcr W6d8nwQL3ZZliD6ZQgPyMoBGoWJQKBG5RUr4BJJFh2lq8iCPzHr/Ua4ifMEdzBIy Kp7kP4dT1JICMuRbTLL6lHunaSPX5z+G2aijWpgQeHIFY+Oxmgza8fdVlnC7lKcM iePFxaeHBvA+t3EmVtOoEGnM5GEvVGI6Q= Received: from [192.168.1.40] (pool-74-96-41-104.washdc.east.verizon.net [74.96.41.104]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPSA id D4E2934806B; Thu, 2 Jun 2011 14:22:01 -0700 (PDT) From: Matt McCutchen To: Paul Hoffman In-Reply-To: <4992780E-FEB3-439F-9A16-B8EEC2A98429@vpnc.org> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4992780E-FEB3-439F-9A16-B8EEC2A98429@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 02 Jun 2011 17:21:58 -0400 Message-ID: <1307049718.2193.100.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:22:04 -0000 On Thu, 2011-06-02 at 14:18 -0700, Paul Hoffman wrote: > On Jun 2, 2011, at 1:23 PM, Phillip Hallam-Baker wrote: > > > OK, it is submitted and waiting first draft approval. > > > > Changes in this version from donotissue-03 are: > > > > * Rights are now Trust (IETF now has change control) > > * Target is Standard track > > * Name is changed to draft-ietf-pkix-caa-00 > > > > > > If anything else has changed it is a mistake. > > > > You didn't remove section 2.3 and the related material that conflicts with the DANE WG? So the DANE WG is being territorial now? How ironic. The wisdom of the overlap in functionality is still to be discussed, but there is no "conflict". -- Matt From paul.hoffman@vpnc.org Thu Jun 2 14:30:14 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49051E06FC for ; Thu, 2 Jun 2011 14:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 8bYQAOShCTMS for ; Thu, 2 Jun 2011 14:30:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7C75AE0627 for ; Thu, 2 Jun 2011 14:30:13 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p52LU8Fh038994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Jun 2011 14:30:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <1307049718.2193.100.camel@localhost> Date: Thu, 2 Jun 2011 14:30:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0A5B68EB-E338-4922-9832-40ADDE93B2F6@vpnc.org> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4992780E-FEB3-439F-9A16-B8EEC2A98429@vpnc.org> <1307049718.2193.100.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:30:14 -0000 On Jun 2, 2011, at 2:21 PM, Matt McCutchen wrote: > On Thu, 2011-06-02 at 14:18 -0700, Paul Hoffman wrote: >> On Jun 2, 2011, at 1:23 PM, Phillip Hallam-Baker wrote: >>=20 >>> OK, it is submitted and waiting first draft approval. >>>=20 >>> Changes in this version from donotissue-03 are: >>>=20 >>> * Rights are now Trust (IETF now has change control) >>> * Target is Standard track >>> * Name is changed to draft-ietf-pkix-caa-00 >>>=20 >>>=20 >>> If anything else has changed it is a mistake. >>>=20 >>=20 >> You didn't remove section 2.3 and the related material that conflicts = with the DANE WG? >=20 > So the DANE WG is being territorial now? =20 I am a member of the DANE WG and the PKIX WG. I don't speak for either, = of course. None of us do. > How ironic. Not at all. There is always an agreement that WGs don't do protocols = that compete directly with other WGs, if for no other reason than to = make the ADs' lives easier. > The wisdom of the overlap in functionality is still to be discussed, = but > there is no "conflict". If there is significant overlap, there is conflict. There has to be a = believable amount of differentiation, where "believable" varies widely = based on time and current leadership. --Paul Hoffman From internet-drafts@ietf.org Thu Jun 2 14:33:27 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1170E08BC; Thu, 2 Jun 2011 14:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 yh+nW0qYLgjd; Thu, 2 Jun 2011 14:33:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E96AE0627; Thu, 2 Jun 2011 14:33:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110602213327.11836.65748.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2011 14:33:27 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-ocspagility-11.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:33:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : Online Certificate Status Protocol Algorithm Agility Author(s) : Stefan Santesson Phillip Hallam-Baker Filename : draft-ietf-pkix-ocspagility-11.txt Pages : 12 Date : 2011-06-02 The Online Certificate Status Protocol (OSCP) [RFC2560] requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used. This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use. This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocspagility-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ocspagility-11.txt From matt@mattmccutchen.net Thu Jun 2 14:36:46 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF328E08BC for ; Thu, 2 Jun 2011 14:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 CC4wMlpIKVWN for ; Thu, 2 Jun 2011 14:36:46 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 29FCDE087A for ; Thu, 2 Jun 2011 14:36:46 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id EC850284082; Thu, 2 Jun 2011 14:36:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=rzzeIBtYgkWQck5rirefNfX4cpRmc7m8rll+nQUc2y5 vreFlMwTEpnP+P+2AmOs+hRSaKA7FRbp/4ORpnOe5S0VA6ckM6Zt6t4Vvlgx6fmR 10PGsTyq54mtuZV3xtQqT46NuuGvyuVA2KaTpcOE5xoj9SSic/utAax8Fz15vCpg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=kZyiG9HdZC0qzwoHcBBF7+1J+10=; b=iPRQAyjiBd hHy6cXT6ZryZmwIHVderBbT1fOtZtWrtJOQXQZNJmtKKnuM3FAJ/pzr/MfJ+YCwL bI+V4WqWhvSVscjyWXa/xAYKzKfdJhdy/h1HQbuh1uKvkndSsGAZdxDPTM2guDQg KZnWoK5UEANhm3nfVX0Pv+szrfOoFqWSs= Received: from [192.168.1.40] (pool-74-96-41-104.washdc.east.verizon.net [74.96.41.104]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id 6514128406E; Thu, 2 Jun 2011 14:36:45 -0700 (PDT) From: Matt McCutchen To: Paul Hoffman In-Reply-To: <0A5B68EB-E338-4922-9832-40ADDE93B2F6@vpnc.org> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4992780E-FEB3-439F-9A16-B8EEC2A98429@vpnc.org> <1307049718.2193.100.camel@localhost> <0A5B68EB-E338-4922-9832-40ADDE93B2F6@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 02 Jun 2011 17:36:43 -0400 Message-ID: <1307050603.2193.111.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:36:46 -0000 On Thu, 2011-06-02 at 14:30 -0700, Paul Hoffman wrote: > On Jun 2, 2011, at 2:21 PM, Matt McCutchen wrote: > > On Thu, 2011-06-02 at 14:18 -0700, Paul Hoffman wrote: > >> You didn't remove section 2.3 and the related material that conflicts with the DANE WG? > > > > So the DANE WG is being territorial now? > > I am a member of the DANE WG and the PKIX WG. I don't speak for either, of course. None of us do. > > > How ironic. > > Not at all. There is always an agreement that WGs don't do protocols > that compete directly with other WGs, if for no other reason than to > make the ADs' lives easier. > If there is significant overlap, there is conflict. There has to be a > believable amount of differentiation, where "believable" varies widely > based on time and current leadership. But the determination to remove relying party enforcement from CAA is far from made at this point. -- Matt From paul.hoffman@vpnc.org Thu Jun 2 14:42:42 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF826E088F for ; Thu, 2 Jun 2011 14:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 nE7MBbI4PV99 for ; Thu, 2 Jun 2011 14:42:42 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 21AEEE0833 for ; Thu, 2 Jun 2011 14:42:41 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p52LgeiK039452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Jun 2011 14:42:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <1307050603.2193.111.camel@localhost> Date: Thu, 2 Jun 2011 14:42:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4D487CAE-D615-4B19-8C5F-7D8608B636AE@vpnc.org> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4992780E-FEB3-439F-9A16-B8EEC2A98429@vpnc.org> <1307049718.2193.100.camel@localhost> <0A5B68EB-E338-4922-9832-40ADDE93B2F6@vpnc.org> <1307050603.2193.111.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:42:43 -0000 On Jun 2, 2011, at 2:36 PM, Matt McCutchen wrote: > But the determination to remove relying party enforcement from CAA is > far from made at this point. Of course, but it also doesn't match anything that Phill talked about in = his request to have the CAA concept adopted by this WG. I sort of hoped = that Phill would stick to the CAA concept we discussed, namely giving = advice to CAs about cert issuance for a domain name. --Paul Hoffman From hallam@gmail.com Thu Jun 2 15:37:24 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5910E08BC for ; Thu, 2 Jun 2011 15:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 t+oRD6bK844p for ; Thu, 2 Jun 2011 15:37:24 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08802E08B6 for ; Thu, 2 Jun 2011 15:37:23 -0700 (PDT) Received: by vxg33 with SMTP id 33so1302769vxg.31 for ; Thu, 02 Jun 2011 15:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rJVXBt5R6E3uh/wI7Nbe5gfvdQrey4KTFH6mw/6yU+g=; b=XXkVKZzBx52+nHd8y1fFHxikSN+xKH0Kup6nZD98D5JmE9J2XaQdonWf87xhZ99BTV RldfMoAAce0ZkP/Nnmj2tyD91o8ymS8kxqtynvWeqXdiWdZqjzkEh4v/rb8cMENP6KmJ WQ+Uj/cxIrPqBSWJQUpQm0AdJwLKv1RXjuWOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Q9TSvG04bgKQ41GrCh/+jVEBWKsTrQL/N0TtoYDDcOiZLPCvM2L6D6YksR6gAq4ALd bBhqr1uCgXb8RnMBNS7wSmtAyphJ9fxAyEy9zGy6wL+fafd3OBf19z4XEHCTFGT05LwO bKTcuEhXsF+PAzhgucjaMuQDgvLGTeQBbO/Ms= MIME-Version: 1.0 Received: by 10.52.112.69 with SMTP id io5mr1699768vdb.94.1307054243312; Thu, 02 Jun 2011 15:37:23 -0700 (PDT) Received: by 10.52.182.65 with HTTP; Thu, 2 Jun 2011 15:37:23 -0700 (PDT) In-Reply-To: <0A5B68EB-E338-4922-9832-40ADDE93B2F6@vpnc.org> References: <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <4992780E-FEB3-439F-9A16-B8EEC2A98429@vpnc.org> <1307049718.2193.100.camel@localhost> <0A5B68EB-E338-4922-9832-40ADDE93B2F6@vpnc.org> Date: Thu, 2 Jun 2011 18:37:23 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=bcaec548a9f1dff4cd04a4c24746 Cc: pkix@ietf.org Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 22:37:24 -0000 --bcaec548a9f1dff4cd04a4c24746 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 2, 2011 at 5:30 PM, Paul Hoffman wrote: > On Jun 2, 2011, at 2:21 PM, Matt McCutchen wrote: > > > How ironic. > > Not at all. There is always an agreement that WGs don't do protocols that > compete directly with other WGs, if for no other reason than to make the > ADs' lives easier. Actually this is untrue I remember when Burt Kaliski proposed S/MIME to the IETF despite the fact that it was already working on PGP. SPKI was proposed at the same time as the IETF was working on PKIX. I would have thought that you knew this. Note that I am not accepting Paul's premise here, I am merely pointing out that the claim made by Paul is untrue. -- Website: http://hallambaker.com/ --bcaec548a9f1dff4cd04a4c24746 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 2, 2011 at 5:30 PM, Paul Hof= fman <paul.ho= ffman@vpnc.org> wrote:
On Jun 2, 2011, at 2:21 PM, Matt McCutchen wrote:
=A0
> How ironic.

Not at all. There is always an agreement that WGs don't do protocols th= at compete directly with other WGs, if for no other reason than to make the= ADs' lives easier.

Actually this is un= true

I remember when Burt Kaliski proposed S/MIME to the IET= F despite the fact that it was already working on PGP.

=
SPKI was proposed at the same time as the IETF was working on PKIX.

I would have thought that you knew this.

=

Note that I am not accepting Paul's premise h= ere, I am merely pointing out that the claim made by Paul is untrue.


--
Website: http://hallambaker.com/

--bcaec548a9f1dff4cd04a4c24746-- From pgut001@login01.cs.auckland.ac.nz Thu Jun 2 19:55:38 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E2FE06D7; Thu, 2 Jun 2011 19:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ALziVOGGYE9; Thu, 2 Jun 2011 19:55:37 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id ABB7CE074C; Thu, 2 Jun 2011 19:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1307069737; x=1338605737; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20hallam@gmail.com,=20ynir@checkpoint.com|Subject: =20Re:=20[TLS]=20[pkix]=20Proposing=20CAA=20as=20PKIX=20W orking=20Group=20Item|Cc:=20paul.hoffman@vpnc.org,=20pkix @ietf.org,=20tls@ietf.org|In-Reply-To:=20<7043B742-0AAA-4 875-8642-764E7F41DFD5@checkpoint.com>|Message-Id:=20|Date:=20Fri,=20 03=20Jun=202011=2014:55:34=20+1200; bh=wnYdBq8MBiWbHSTxGA5aGMJ1ClVLNjOAbWIyKY86+Lc=; b=MpP6lzJ+ov61iJ3+mYxQ2Eh+rMeTio0i36eT/FrhSToqMIgyzJIzmLyv iuVXD5khWhKZfZymM+WCCH0eilB50KwyewXeXy4I6pPUDAHCD5M+6fRYr biyLVTXqmyU2wt3YAgqR0ZpkxixSD8x1kMoAP8mF6TU0lfuqRPwGgLyXi k=; X-IronPort-AV: E=Sophos;i="4.65,313,1304251200"; d="scan'208";a="65395569" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Jun 2011 14:55:34 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QSKXu-00061N-Gc; Fri, 03 Jun 2011 14:55:34 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QSKXu-0000S2-2s; Fri, 03 Jun 2011 14:55:34 +1200 From: Peter Gutmann To: hallam@gmail.com, ynir@checkpoint.com In-Reply-To: <7043B742-0AAA-4875-8642-764E7F41DFD5@checkpoint.com> Message-Id: Date: Fri, 03 Jun 2011 14:55:34 +1200 Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 02:55:38 -0000 Yoav Nir writes: >In late 2008, when some researchers got RapidSSL to sign a certificate >request that collided with their rogue sub-CA certificate, several things >came to light: > - They were a ridiculously small company, with the only full-time employee. >An accountant I wasn't aware of this one, do you have any pointers to info on this? I guess a Webtrust audit doesn't check whether you have more than a single employee :-). Peter. From marsh@extendedsubset.com Thu Jun 2 20:54:08 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0362DE07A3; Thu, 2 Jun 2011 20:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 D0GWUXR3ACr8; Thu, 2 Jun 2011 20:54:07 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9D2E0678; Thu, 2 Jun 2011 20:54:07 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QSLST-000P6T-Fv; Fri, 03 Jun 2011 03:54:01 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D66AE601A; Fri, 3 Jun 2011 03:53:58 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18is+iucigW3xeJKZDAYuxJ2Ihv2PXGOsI= Message-ID: <4DE85AD7.8010407@extendedsubset.com> Date: Thu, 02 Jun 2011 22:53:59 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paul.hoffman@vpnc.org, tls@ietf.org, pkix@ietf.org Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 03:54:08 -0000 On 06/02/2011 09:55 PM, Peter Gutmann wrote: > Yoav Nir writes: > >> In late 2008, when some researchers got RapidSSL to sign a certificate >> request that collided with their rogue sub-CA certificate, several things >> came to light: >> - They were a ridiculously small company, with the only full-time employee. >> An accountant > > I wasn't aware of this one, do you have any pointers to info on this? I guess > a Webtrust audit doesn't check whether you have more than a single employee :-). I think he's referring to Stevens, Sotirov, et al. 2008 http://www.win.tue.nl/hashclash/rogue-ca/ which I'm sure you heard about. I hadn't heard the part about the single employee though. - Marsh From pgut001@login01.cs.auckland.ac.nz Thu Jun 2 21:03:24 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6AAE0678; Thu, 2 Jun 2011 21:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.363 X-Spam-Level: X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3SuT3RVD6Nf; Thu, 2 Jun 2011 21:03:23 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 146C3E0674; Thu, 2 Jun 2011 21:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1307073803; x=1338609803; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20marsh@extendedsubset.com,=20pgut001@cs.auckland.ac .nz|Subject:=20Re:=20[pkix]=20[TLS]=20=20Proposing=20CAA =20as=20PKIX=20Working=20Group=20Item|Cc:=20paul.hoffman@ vpnc.org,=20pkix@ietf.org,=20tls@ietf.org|In-Reply-To:=20 <4DE85AD7.8010407@extendedsubset.com>|Message-Id:=20|Date:=20Fri,=20 03=20Jun=202011=2016:03:19=20+1200; bh=OhN/axvzIYTiy73X7OYil9R21Prk+br2xAWp9hNOXoo=; b=dFzfLDrYfzTaiPdvNpVNAFAsAgifUz4y+SML3svMswbBOSoaW3O7rJ8P HYL0kqoj/0yp/TBgc45SfqVatwHLrTRZmVmwCJ9Yqk4LzDeD2+rJxiVup 1luQeM/VB8JSoQQMsw9W0tFAp55Ulp9g65R+MxHGLSzcWR50BUl91DwpG w=; X-IronPort-AV: E=Sophos;i="4.65,313,1304251200"; d="scan'208";a="65450460" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Jun 2011 16:03:20 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QSLbT-0000NU-J8; Fri, 03 Jun 2011 16:03:19 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QSLbT-000401-SQ; Fri, 03 Jun 2011 16:03:19 +1200 From: Peter Gutmann To: marsh@extendedsubset.com, pgut001@cs.auckland.ac.nz In-Reply-To: <4DE85AD7.8010407@extendedsubset.com> Message-Id: Date: Fri, 03 Jun 2011 16:03:19 +1200 Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 04:03:24 -0000 Marsh Ray writes: >I hadn't heard the part about the single employee though. That's the bit I hadn't heard before. Sounds a bit minimal for a commercial CA. Perhaps the OP confused it with Honest Achmed. Peter. From matt@mattmccutchen.net Fri Jun 3 14:30:52 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F4004E07D4; Fri, 3 Jun 2011 14:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 sQqVkDN31r+a; Fri, 3 Jun 2011 14:30:51 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id CF738E07F1; Fri, 3 Jun 2011 14:30:50 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 54D59280074; Fri, 3 Jun 2011 14:30:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=kBid7frbiVNjvV0Wz1t1gt0sOcvuNVVonIrjH1Rf/DK Cxur4giBdvAMRZ7hY9hnoCC5PaFiXU2ARzqFB6LX2w7C3P0hSBoIkcMQ/+0R54kj MAE48eNC3XC3AGyN7b/6mxI1cqkWaWxukf7eZpXWw2pE0dmd84SjhdqHPhBouXeI = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=b6knztUKFBA6dI8a3egqGzuaYQk=; b=qwsUw8XjOv DY048YvTRZIBTBSUjn9el6QFKO+e6wd7BPZUPt9tYo6R8OyNslViAA+fUSHws5Pb IML1FnM3hSMGpQ5KfNnFX1tyntJSt1MK9bsPMCDajV4IDKtXfq4yJBA7Df9ML4xA mVk0yleBoqdy0rm51VzgB5UgcfooR6rbg= Received: from [192.168.1.40] (pool-74-96-127-26.washdc.east.verizon.net [74.96.127.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPSA id BCDAC280063; Fri, 3 Jun 2011 14:30:49 -0700 (PDT) From: Matt McCutchen To: Paul Wouters In-Reply-To: References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <201106021814.p52IEkZE003911@new.toad.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 03 Jun 2011 17:30:47 -0400 Message-ID: <1307136647.1999.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org, dane@ietf.org Subject: [pkix] CSRs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 21:30:52 -0000 On Fri, 2011-06-03 at 11:46 -0400, Paul Wouters wrote: > If only we could add a DNS record in our zone and sign it to signifiy what our pubkey is... > > If you're going to trust DNS for anything, you might as well take a hint to grab the pubkey > needed from the cert. So CAs could just confirm the incoming cert request by doing a DNS > lookup of the pubkey. For those who want to support legacy clients while making the maximum possible use of DNS, this is absolutely the thing to do, except I would use the CSR or even (CSR, requested signer cert). This is just to authenticate the entire request; the CA may only honor a subset of the CSR fields according to its policies. Organizations that have a close relationship with a CA may not feel the need to duplicate their requests to the CA in the DNS, but they may find the ancestor cert and cert policy constraints to be useful controls. Hence, I would keep those options as well. Let's take further discussion of CAA to the PKIX list. -- Matt From hallam@gmail.com Fri Jun 3 14:53:35 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE66E07ED for ; Fri, 3 Jun 2011 14:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 c2JRfkzmimQi for ; Fri, 3 Jun 2011 14:53:34 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F48EE07C7 for ; Fri, 3 Jun 2011 14:53:34 -0700 (PDT) Received: by yic13 with SMTP id 13so1214265yic.31 for ; Fri, 03 Jun 2011 14:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BJc1v+ZFrBY0WA9RmmO3DpugIHWhYyJNcm1miDWDsDg=; b=oweNXjfxR9LJJMULufLTyzfoLR/TMSE1p7hFo5r4b1igbQtos8Mv01AJPMuYhbKELk o8cxyUKarzEW6NaacHKHXU4Roqi79tQ2cUfBIbC+XNO9gi6ciu+SWpWa7/dgJ7TR9drl qXlzr0Dbm0ZaOgptt0mgYHlnhXFK17G0ScYm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qvX3eTeqOtDgE1RSTRlWmGJl6QzH5On1jH01WMP0QFKLpD7NURUXLpxltoyT8s+yo/ 3RhIN9wfz5qcWuUGhylCoIALPstOefFLi3x859odSBHUs8SW3pfaf+AAE9PSg7f7+jKt z1m3W8jqn/9L2ThtPFfRQyxJ+J7DrQk5or+Qw= MIME-Version: 1.0 Received: by 10.101.194.24 with SMTP id w24mr1033013anp.151.1307138013857; Fri, 03 Jun 2011 14:53:33 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Fri, 3 Jun 2011 14:53:33 -0700 (PDT) In-Reply-To: <1307136647.1999.7.camel@localhost> References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <201106021814.p52IEkZE003911@new.toad.com> <1307136647.1999.7.camel@localhost> Date: Fri, 3 Jun 2011 17:53:33 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=001636c92c46fd071f04a4d5c88d Cc: pkix@ietf.org, Paul Wouters Subject: Re: [pkix] [dane] CSRs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 21:53:35 -0000 --001636c92c46fd071f04a4d5c88d Content-Type: text/plain; charset=ISO-8859-1 I see that as a different use case. Basically that is providing an additional authentication signal to the CA providing a form of proof of ownership of the Domain. We did discuss this type of approach early on in the design of CAA and decided to punt on it for the initial proposal as the domain name owner can achieve the same effect by only authorizing a CA after establishing an out of band agreement to use a particular authentication technique. Putting a CSR in the DNS is a subset of the possible authentication techniques and not a good one in my view as it requires the DNS to be touched on a per transaction basis. That is contrary to my understanding of the normal approach to DNS administration which is to only put information in the DNS that is intended to be persisted for a period. Admittedly certification requests are infrequent events, but even so, it is not a precedent that I would like to see. Instead I would prefer to see the DNS used to express credentials that are already employed in Certificate validation processes. For example an email address nominated as the contact address or a public key of an authorized authentication credential. So I see it as a useful complement to but not a replacement for path and policy. An email contact address would be useful even if it was not used for authentication. Management of the larger Web properties can be very complex and getting to a security person in a hurry can be a challenge. On Fri, Jun 3, 2011 at 5:30 PM, Matt McCutchen wrote: > On Fri, 2011-06-03 at 11:46 -0400, Paul Wouters wrote: > > If only we could add a DNS record in our zone and sign it to signifiy > what our pubkey is... > > > > If you're going to trust DNS for anything, you might as well take a hint > to grab the pubkey > > needed from the cert. So CAs could just confirm the incoming cert request > by doing a DNS > > lookup of the pubkey. > > For those who want to support legacy clients while making the maximum > possible use of DNS, this is absolutely the thing to do, except I would > use the CSR or even (CSR, requested signer cert). This is just to > authenticate the entire request; the CA may only honor a subset of the > CSR fields according to its policies. > > Organizations that have a close relationship with a CA may not feel the > need to duplicate their requests to the CA in the DNS, but they may find > the ancestor cert and cert policy constraints to be useful controls. > Hence, I would keep those options as well. > > Let's take further discussion of CAA to the PKIX list. > > -- > Matt > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001636c92c46fd071f04a4d5c88d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see that as a different use case. Basically that is providing an addition= al authentication signal to the CA providing a form of proof of ownership o= f the Domain.

We did discuss this type of approach early= on in the design of CAA and decided to punt on it for the initial proposal= as the domain name owner can achieve the same effect by only authorizing a= CA after establishing an out of band agreement to use a particular authent= ication technique.


Putting a CSR in the DNS is a subset of = the possible authentication techniques and not a good one in my view as it = requires the DNS to be touched on a per transaction basis. That is contrary= to my understanding of the normal approach to DNS administration which is = to only put information in the DNS that is intended to be persisted for a p= eriod. Admittedly certification requests are infrequent events, but even so= , it is not a precedent that I would like to see.

Instead I would prefer to see the DNS used to express c= redentials that are already employed in Certificate validation processes. F= or example an email address nominated as the contact address or a public ke= y of an authorized authentication credential.


So I see it as a useful complement to bu= t not a replacement for path and policy.

An email = contact address would be useful even if it was not used for authentication.= Management of the larger Web properties can be very complex and getting to= a security person in a hurry can be a challenge.


On Fri, Jun 3, 2011 at 5= :30 PM, Matt McCutchen <matt@mattmccutchen.net> wrote:
On Fri, 2011-06-03 at 11:46 -0400, Paul Wouters wrote:
> If only we could add a DNS record in our zone and sign it to signifiy = what our pubkey is...
>
> If you're going to trust DNS for anything, you might as well take = a hint to grab the pubkey
> needed from the cert. So CAs could just confirm the incoming cert requ= est by doing a DNS
> lookup of the pubkey.

For those who want to support legacy clients while making the maximum
possible use of DNS, this is absolutely the thing to do, except I would
use the CSR or even (CSR, requested signer cert). =A0This is just to
authenticate the entire request; the CA may only honor a subset of the
CSR fields according to its policies.

Organizations that have a close relationship with a CA may not feel the
need to duplicate their requests to the CA in the DNS, but they may find the ancestor cert and cert policy constraints to be useful controls.
Hence, I would keep those options as well.

Let's take further discussion of CAA to the PKIX list.

--
Matt

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--001636c92c46fd071f04a4d5c88d-- From matt@mattmccutchen.net Fri Jun 3 19:50:02 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0942E06E6 for ; Fri, 3 Jun 2011 19:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 Wr4Jdo2deLwM for ; Fri, 3 Jun 2011 19:50:01 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id B94B6E06D1 for ; Fri, 3 Jun 2011 19:50:01 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 6428820806C; Fri, 3 Jun 2011 19:50:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=OLoS/LDhV+FpJ1QVLbDidi9cZz1oHvMWa3xWxi+N8zN 0Gs79rFfN6rlxTfD6n5W1UuqNFqABM9HEHV/zA/n1w9e0uoSoSDGi00ajQGZ7Kmj M4dUA7nv/nw21OhFS7KdmcNFP0dDw0axq5HjvBg609jhD/iTwa42Soz/HliQnlG8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=aaJEirn07slz3t7IeVwDlXd70+c=; b=BQ4932ZsW3 Z2eIrAPB0e/m/r4C7PYEXJD1bLjlMYfeqsbFoIjNUrZ3MIDvDEmLa9/1T5OHVF71 shHbH7k5CKUP0+l+WjRhaYAdY3uuO16Lbx3IG3nYiICyvrpez9Yp8e20j5MX/Tva atcND4VZNVdYtZiPnP2XWcX4B8czpxMh0= Received: from [192.168.1.40] (pool-74-96-127-26.washdc.east.verizon.net [74.96.127.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPSA id E7EBB208069; Fri, 3 Jun 2011 19:50:00 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <201106021814.p52IEkZE003911@new.toad.com> <1307136647.1999.7.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Fri, 03 Jun 2011 22:49:23 -0400 Message-ID: <1307155763.1999.24.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] [dane] CSRs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 02:50:02 -0000 On Fri, 2011-06-03 at 17:53 -0400, Phillip Hallam-Baker wrote: > I see that as a different use case. Basically that is providing an > additional authentication signal to the CA providing a form of proof > of ownership of the Domain. Not really. It provides proof that the domain owner authorized the issuance of the particular certificate. It can be used as either an alternative validation mechanism or an additional requirement. Your description would correspond to publishing the subscriber's username for the CA's portal. > We did discuss this type of approach early on in the design of CAA and > decided to punt on it for the initial proposal as the domain name > owner can achieve the same effect by only authorizing a CA after > establishing an out of band agreement to use a particular > authentication technique. You are right. The CSR endorsement can be a separate protocol whose use is specified via CAA; there is no need to standardize both at once. But I do strongly desire a standardized protocol for CSR endorsement, so that the public accountability benefits of CAA can extend down to the level of the individual certificate. > Putting a CSR in the DNS is a subset of the possible authentication > techniques and not a good one in my view as it requires the DNS to be > touched on a per transaction basis. That is contrary to my > understanding of the normal approach to DNS administration which is to > only put information in the DNS that is intended to be persisted for a > period. Admittedly certification requests are infrequent events, In fact, they would typically coincide with changes to the TLSA RRset. > but even so, it is not a precedent that I would like to see. Good point. The DNS authority structure is just what we want, but DNS is not an appropriate transport. So instead, the CSR could be signed with a public key published in DNS or even with the DNSKEY itself, unless that makes people uncomfortable. > Instead I would prefer to see the DNS used to express credentials that > are already employed in Certificate validation processes. For example > an email address nominated as the contact address or a public key of > an authorized authentication credential. Mmm... For authentication of requests, you need a public key somewhere, and then an email address doesn't buy you anything extra. > An email contact address would be useful even if it was not used for > authentication. Management of the larger Web properties can be very > complex and getting to a security person in a hurry can be a > challenge. It sounds like the email address is addressing an orthogonal set of concerns. -- Matt From matt@mattmccutchen.net Fri Jun 3 20:05:08 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0684DE075E; Fri, 3 Jun 2011 20:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 RXAJptyr8C6N; Fri, 3 Jun 2011 20:05:07 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 67F04E06FC; Fri, 3 Jun 2011 20:05:07 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 3B4D863406F; Fri, 3 Jun 2011 20:05:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Fip4awCH73BhXgswecHuzUUKmzFpR5ywHIWhHWQnYgC EVQ7KoGIP46dbamRi3+6qGrMB0EXNYs/gSboV7/ipd/sUGteZGSH77/NOdtMdS5F tcVzF2+/VMBdHwxHHxbOp+jF2nbTN4BG/Y2DhhLUIh+f/CxYngTuX/Se8hsoDC1E = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=g6/Cg/zqBZ0is7fScLLeFoKNXq0=; b=hmasKAPUP8 nsQmsxn1GFZXFGJBCX2gRkfdeuha8mBJWgrmJPk63HOLeWauOT9px+bUSMzLXD1q F5KydEO3NiEzkIVEAKEIa6nREwqDXiCtEtxO59CeZetyXGdliax7GtKUg3LUxuxZ JJZWBNutbxtsUBC39NzAegdLTGshGSRRw= Received: from [192.168.1.40] (pool-74-96-127-26.washdc.east.verizon.net [74.96.127.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPSA id CA2BC63406E; Fri, 3 Jun 2011 20:05:06 -0700 (PDT) From: Matt McCutchen To: pkix@ietf.org, dane In-Reply-To: <1307136647.1999.7.camel@localhost> References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <201106021814.p52IEkZE003911@new.toad.com> <1307136647.1999.7.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Fri, 03 Jun 2011 23:05:04 -0400 Message-ID: <1307156704.1999.36.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] CSRs in CAA + automation X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 03:05:08 -0000 On Fri, 2011-06-03 at 17:30 -0400, Matt McCutchen wrote: > On Fri, 2011-06-03 at 11:46 -0400, Paul Wouters wrote: > > If you're going to trust DNS for anything, you might as well take a hint to grab the pubkey > > needed from the cert. So CAs could just confirm the incoming cert request by doing a DNS > > lookup of the pubkey. > > For those who want to support legacy clients while making the maximum > possible use of DNS, this is absolutely the thing to do, except I would > use the CSR or even (CSR, requested signer cert). This is just to > authenticate the entire request; the CA may only honor a subset of the > CSR fields according to its policies. Do you all realize what we'll be able to do with such a protocol? Just give your web server access to update its DNS data via TSIG, and it can generate a key pair, poke the DANE records into DNS, and get itself a domain-validated certificate from your favorite CA. This functionality could be in the TLS server library. (Yes, Martin, I mean "TLS and associated technologies".) At a higher level, when you register a domain from $favorite_web_host, you could check a box and have them set up the whole nine yards: DNSSEC with DS submitted to the registry, TLS, DANE, a domain-validated certificate, strict transport security, and whatever else we cook up. Phill, this may be the "easy TLS adoption" you were looking forward to. -- Matt From matt@mattmccutchen.net Sat Jun 4 09:17:15 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59917E068D for ; Sat, 4 Jun 2011 09:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 LHsyzaYb3W2z for ; Sat, 4 Jun 2011 09:17:14 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id D8E1BE0662 for ; Sat, 4 Jun 2011 09:17:14 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 5CB9963406F; Sat, 4 Jun 2011 09:17:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=vIylONjfvGV6CbJFE5tqPg7HwU2eYgZCZAAxaE0x8Me qfp4nXNz5cqxB//zqaiT8ubDjquGUQPLbqTHiHM05zztB2YWho6z/sFW6ZM9EPQt ID4bjC0yhUj4J9jMuvOCorSF0jp075pHbAksQhU94XmEvAmAyrtGQTgcdQ75JwMs = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=b+BUSynV0Wnabd+R5J9pdTM4IUc=; b=hg1k+MpUT2 TxwEzAcP/9e+ji0XgBiQH0WUK8ElsdZm7iOTpqIwjGvP7Mtxnph7daaaux4lmutE Gl2vg1OQ+o+lF8YaiVc28KozPv6Q2/GYw3qiFdBgRsVFLwZjvk1l8MUkLmdaJdN6 Lms65/zBLPbyrB2mTgc7MmVlhSKzncJ2s= Received: from [192.168.1.40] (pool-74-96-127-26.washdc.east.verizon.net [74.96.127.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPSA id E6B1763406E; Sat, 4 Jun 2011 09:17:13 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <201106021814.p52IEkZE003911@new.toad.com> <1307136647.1999.7.camel@localhost> <1307155763.1999.24.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Sat, 04 Jun 2011 12:17:12 -0400 Message-ID: <1307204232.5994.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] [dane] CSRs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 16:17:15 -0000 On Sat, 2011-06-04 at 09:35 -0400, Phillip Hallam-Baker wrote: > It does not show the party that is authorized to issue or the key that > is authorized to sign. In place of CSR, read (CSR, requested signer cert) tuple. In fact, it might make sense to have an optional field for the requested signer cert in the CSR itself. Or does the authority key identifier already serve this purpose? -- Matt From hallam@gmail.com Sat Jun 4 09:25:39 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B10EE068D for ; Sat, 4 Jun 2011 09:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 0VECQDlUl7SU for ; Sat, 4 Jun 2011 09:25:33 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 637CFE0662 for ; Sat, 4 Jun 2011 09:25:33 -0700 (PDT) Received: by yib18 with SMTP id 18so203974yib.31 for ; Sat, 04 Jun 2011 09:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=L4kmhw3sLs30csrY9PBnR+fqVJ5SZWYhTmPyp9G0OCo=; b=g6WCMlcXhb0pZoBVSfjDbC7vrjlRy92xP4QAZP0pNzrGdnE8GQn9ggMdnrzaJDzk84 31vWDVRyLTYCtbM3vQlmiChZwgCZVpaHEHPxIqNCF4QzG0oxwMn9UC9fvDM+XDfM9Wft 3Ykn9ctYeqeMI+YUFJXmvRTHPEP0JJ68p2ZZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oKvvoxEnbKFqGoi61aNPLISWr4n85UKmaGFVEw9NvzcJVM/4bU5N5pBsOLkpxMntz5 3EpOBLGBoqQJxDmKRrd+hNR/JPBjHGtWBZLBmLUiza76LFaABO9KPrdZAK+/ZbrVLydN l6Yd2d6yXvDdjFezp+BG8YtaoFH9MEhWx8h9U= MIME-Version: 1.0 Received: by 10.101.74.10 with SMTP id b10mr2059791anl.107.1307194527462; Sat, 04 Jun 2011 06:35:27 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Sat, 4 Jun 2011 06:35:27 -0700 (PDT) In-Reply-To: <1307155763.1999.24.camel@localhost> References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <201106021814.p52IEkZE003911@new.toad.com> <1307136647.1999.7.camel@localhost> <1307155763.1999.24.camel@localhost> Date: Sat, 4 Jun 2011 09:35:27 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=0016368e1f8576352204a4e2f17b Cc: pkix@ietf.org Subject: Re: [pkix] [dane] CSRs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 16:25:39 -0000 --0016368e1f8576352204a4e2f17b Content-Type: text/plain; charset=ISO-8859-1 It does not show the party that is authorized to issue or the key that is authorized to sign. It is a different risk for the same use case. But there is one specific use case for putting a CSR up that is very compelling and that is to install the CSRs for the ICANN Root Signing KSKs. On Fri, Jun 3, 2011 at 10:49 PM, Matt McCutchen wrote: > On Fri, 2011-06-03 at 17:53 -0400, Phillip Hallam-Baker wrote: > > I see that as a different use case. Basically that is providing an > > additional authentication signal to the CA providing a form of proof > > of ownership of the Domain. > > Not really. It provides proof that the domain owner authorized the > issuance of the particular certificate. It can be used as either an > alternative validation mechanism or an additional requirement. Your > description would correspond to publishing the subscriber's username for > the CA's portal. > > > We did discuss this type of approach early on in the design of CAA and > > decided to punt on it for the initial proposal as the domain name > > owner can achieve the same effect by only authorizing a CA after > > establishing an out of band agreement to use a particular > > authentication technique. > > You are right. The CSR endorsement can be a separate protocol whose use > is specified via CAA; there is no need to standardize both at once. But > I do strongly desire a standardized protocol for CSR endorsement, so > that the public accountability benefits of CAA can extend down to the > level of the individual certificate. > > > Putting a CSR in the DNS is a subset of the possible authentication > > techniques and not a good one in my view as it requires the DNS to be > > touched on a per transaction basis. That is contrary to my > > understanding of the normal approach to DNS administration which is to > > only put information in the DNS that is intended to be persisted for a > > period. Admittedly certification requests are infrequent events, > > In fact, they would typically coincide with changes to the TLSA RRset. > > > but even so, it is not a precedent that I would like to see. > > Good point. The DNS authority structure is just what we want, but DNS > is not an appropriate transport. So instead, the CSR could be signed > with a public key published in DNS or even with the DNSKEY itself, > unless that makes people uncomfortable. > > > Instead I would prefer to see the DNS used to express credentials that > > are already employed in Certificate validation processes. For example > > an email address nominated as the contact address or a public key of > > an authorized authentication credential. > > Mmm... For authentication of requests, you need a public key somewhere, > and then an email address doesn't buy you anything extra. > > > An email contact address would be useful even if it was not used for > > authentication. Management of the larger Web properties can be very > > complex and getting to a security person in a hurry can be a > > challenge. > > It sounds like the email address is addressing an orthogonal set of > concerns. > > -- > Matt > > -- Website: http://hallambaker.com/ --0016368e1f8576352204a4e2f17b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It does not show the party that is authorized to issue or the key that is a= uthorized to sign.=A0

It is a different risk for the sam= e use case.=A0


But there is one specific = use case for putting a CSR up that is very compelling and that is to instal= l the CSRs for the ICANN Root Signing KSKs.


On Fri, Jun 3, 2011 at 10:49 PM, Ma= tt McCutchen <matt@mattmccutchen.net> wrote:
On Fri, 2011-06-03 at 17:53 -0400, Phillip Hallam-Baker w= rote:
> I see that as a different use case. Basically that is providing an
> additional authentication signal to the CA providing a form of proof > of ownership of the Domain.

Not really. =A0It provides proof that the domain owner authorized the=
issuance of the particular certificate. =A0It can be used as either an
alternative validation mechanism or an additional requirement. =A0Your
description would correspond to publishing the subscriber's username fo= r
the CA's portal.

> We did discuss this type of approach early on in the design of CAA and=
> decided to punt on it for the initial proposal as the domain name
> owner can achieve the same effect by only authorizing a CA after
> establishing an out of band agreement to use a particular
> authentication technique.

You are right. =A0The CSR endorsement can be a separate protocol whos= e use
is specified via CAA; there is no need to standardize both at once. =A0But<= br> I do strongly desire a standardized protocol for CSR endorsement, so
that the public accountability benefits of CAA can extend down to the
level of the individual certificate.

> Putting a CSR in the DNS is a subset of the possible authentication > techniques and not a good one in my view as it requires the DNS to be<= br> > touched on a per transaction basis. That is contrary to my
> understanding of the normal approach to DNS administration which is to=
> only put information in the DNS that is intended to be persisted for a=
> period. Admittedly certification requests are infrequent events,

In fact, they would typically coincide with changes to the TLSA RRset= .

> but even so, it is not a precedent that I would like to see.

Good point. =A0The DNS authority structure is just what we want, but = DNS
is not an appropriate transport. =A0So instead, the CSR could be signed
with a public key published in DNS or even with the DNSKEY itself,
unless that makes people uncomfortable.

> Instead I would prefer to see the DNS used to express credentials that=
> are already employed in Certificate validation processes. For example<= br> > an email address nominated as the contact address or a public key of > an authorized authentication credential.

Mmm... For authentication of requests, you need a public key somewher= e,
and then an email address doesn't buy you anything extra.

> An email contact address would be useful even if it was not used for > authentication. Management of the larger Web properties can be very > complex and getting to a security person in a hurry can be a
> challenge.

It sounds like the email address is addressing an orthogonal set of concerns.

--
Matt




--
Website: http://hallambaker.com/

--0016368e1f8576352204a4e2f17b-- From hallam@gmail.com Sat Jun 4 11:17:52 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE2AE065B for ; Sat, 4 Jun 2011 11:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 H7IgmvxUerFP for ; Sat, 4 Jun 2011 11:17:52 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6C5E0651 for ; Sat, 4 Jun 2011 11:17:52 -0700 (PDT) Received: by yxk30 with SMTP id 30so1472320yxk.31 for ; Sat, 04 Jun 2011 11:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sVhN7VEpHeSR1iepsfGzGcHkQ+oZSC0H+oTGWTFdx54=; b=f5yrbYkEMnEjc/TjRKYVRPoRXjL0UPWDPwyPDdMhr9PuGqTRL22Xy9NhAmPP4c/ktx F3H6GweBU3PI6PRMpotoJE0TuiOQ6gOmNPYEsqYYdY8U1ro/qQ4BKghW+e6vLkp+/nie B3pewsNwFvchWzerbLG+1PWl40GCyH1YBCsXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bSjMXO2a+RfLh2h+6wHxDfQjybT34BM502nctqIsRfhQeO/3MYJAd51cHQfxO1f004 AYIS+FGPq1i5aY8vCh3kG1o6rJ6B5W9I7geAt1kdXP4MlC0f6HkFlXz6ijVYIiq2uGZr re2nWpCn8YP1gm7gYgERX8d+pVrZnTchJSWKE= MIME-Version: 1.0 Received: by 10.100.56.29 with SMTP id e29mr2201582ana.129.1307211471468; Sat, 04 Jun 2011 11:17:51 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Sat, 4 Jun 2011 11:17:51 -0700 (PDT) In-Reply-To: <1307204232.5994.2.camel@localhost> References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <201106021814.p52IEkZE003911@new.toad.com> <1307136647.1999.7.camel@localhost> <1307155763.1999.24.camel@localhost> <1307204232.5994.2.camel@localhost> Date: Sat, 4 Jun 2011 14:17:51 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=001485f860e66739fe04a4e6e3da Cc: pkix@ietf.org Subject: Re: [pkix] [dane] CSRs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 18:17:52 -0000 --001485f860e66739fe04a4e6e3da Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 4, 2011 at 12:17 PM, Matt McCutchen wrote: > On Sat, 2011-06-04 at 09:35 -0400, Phillip Hallam-Baker wrote: > > It does not show the party that is authorized to issue or the key that > > is authorized to sign. > > In place of CSR, read (CSR, requested signer cert) tuple. In fact, it > might make sense to have an optional field for the requested signer cert > in the CSR itself. Or does the authority key identifier already serve > this purpose? > This is starting to look complicated to me. I think we can break down the potential properties to: 1) General Controls Specify the authorized issuer by policy, path Specify the preferred subject authentication by email, public key Specify contact information 2) Transaction Specific Controls Specify {CSR, Issuer} of request I am not completely opposed to the transaction controls. But they look like they have to be additional options, not replacements to me. -- Website: http://hallambaker.com/ --001485f860e66739fe04a4e6e3da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jun 4, 2011 at 12:17 PM, Matt McCutchen <matt@mattmccutchen.net> = wrote:
On Sat, 2011-06-04 at 09:35 -0400, Phillip Hallam-Baker w= rote:
> It does not show the party that is authorized to issue or the key that=
> is authorized to sign.

In place of CSR, read (CSR, requested signer cert) tuple. =A0In fact,= it
might make sense to have an optional field for the requested signer cert in the CSR itself. =A0Or does the authority key identifier already serve this purpose?

This is starting to look = complicated to me.=A0

I think we can break down th= e potential properties to:

1) General Controls

Specify the authorized issuer by policy, path
Specify the preferred subject authentication by email, public key
Specify contact information


2) Tr= ansaction Specific Controls

Specify {CSR, Issuer} of request


I am not completely opposed to the transaction controls. But they = look like they have to be additional options, not replacements to me.

--001485f860e66739fe04a4e6e3da-- From matt@mattmccutchen.net Sat Jun 4 13:58:19 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A87711E8071 for ; Sat, 4 Jun 2011 13:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 kriJyHHZs5GA for ; Sat, 4 Jun 2011 13:58:18 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id C8BF822800C for ; Sat, 4 Jun 2011 13:58:18 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 5966451C063; Sat, 4 Jun 2011 13:58:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=tLLEZ/Yhpt+1GIMnqkSOv3U3QILb6kF26lOz2tp5FZm rCU+Nwl3vAOMXq9OWcdWMc+YbU/tK0k3X4f9akJIET7RJ6YkVQEeccbGkioRDMyr FThVgH0JvNaXYuXtGtGLBiHS4cpMuWKXUDcqIrwFPdmT0kRraPa1A+1k+zdfTXPs = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=w3mFvhfAUaRV7Pub2CW3v3QuWe8=; b=IomQ1nf3JM kLU42k8ICoJtnxXoRSwrfE0j62SdhPMLLu53tVCPshb5Kd5PRzzQqvb63Lv5zxOn w90l3aA86nvDCNEbtWOKUmC4Sck0LrhQdlQjdpVbnhXIHk0Lz02V2qFDVzme5gEX +Tu+T5j0FAh8tSjEkAWCPxseqQgATgv70= Received: from [192.168.1.40] (pool-74-96-127-26.washdc.east.verizon.net [74.96.127.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id DFFE651C062; Sat, 4 Jun 2011 13:58:17 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <201106021814.p52IEkZE003911@new.toad.com> <1307136647.1999.7.camel@localhost> <1307155763.1999.24.camel@localhost> <1307204232.5994.2.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Sat, 04 Jun 2011 16:58:16 -0400 Message-ID: <1307221096.5994.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] [dane] CSRs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 20:58:19 -0000 On Sat, 2011-06-04 at 14:17 -0400, Phillip Hallam-Baker wrote: > On Sat, Jun 4, 2011 at 12:17 PM, Matt McCutchen > wrote: > On Sat, 2011-06-04 at 09:35 -0400, Phillip Hallam-Baker wrote: > > It does not show the party that is authorized to issue or > the key that > > is authorized to sign. > > > In place of CSR, read (CSR, requested signer cert) tuple. In > fact, it > might make sense to have an optional field for the requested > signer cert > in the CSR itself. Or does the authority key identifier > already serve > this purpose? > > This is starting to look complicated to me. > > I think we can break down the potential properties to: > > 1) General Controls > > Specify the authorized issuer by policy, path > Specify the preferred subject authentication by email, public key > Specify contact information > > 2) Transaction Specific Controls > > Specify {CSR, Issuer} of request Where "issuer" should contain at least the DN and public key (or a hash covering them), so the system doesn't collapse if there is a DN collision. Then the request would specify the entire requested Certificate structure, except that the "signature" field is left symbolic as "sign($tbsCertificate, break_rsa($issuer_public_key))". :P > I am not completely opposed to the transaction controls. But they look > like they have to be additional options, not replacements to me. Absolutely. -- Matt From ynir@checkpoint.com Sat Jun 4 23:54:03 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FB321F8445; Sat, 4 Jun 2011 23:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] 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 MZP4WUEOhMt6; Sat, 4 Jun 2011 23:54:02 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EF51021F8444; Sat, 4 Jun 2011 23:54:01 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p556redl021536; Sun, 5 Jun 2011 09:53:41 +0300 X-CheckPoint: {4DEB347F-0-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 5 Jun 2011 09:53:40 +0300 From: Yoav Nir To: Peter Gutmann Date: Sun, 5 Jun 2011 09:53:41 +0300 Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item Thread-Index: AcwjTUzaSKIvgKIwQTaLFKFXCxvBOw== Message-ID: <81856AC0-F6FB-4321-93FE-559D5C5E2743@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" , "tls@ietf.org" Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 06:54:03 -0000 On Jun 3, 2011, at 5:55 AM, Peter Gutmann wrote: > Yoav Nir writes: >=20 >> In late 2008, when some researchers got RapidSSL to sign a certificate >> request that collided with their rogue sub-CA certificate, several thing= s >> came to light: >> - They were a ridiculously small company, with the only full-time employ= ee. >> An accountant >=20 > I wasn't aware of this one, do you have any pointers to info on this? I = guess=20 > a Webtrust audit doesn't check whether you have more than a single employ= ee :-). >=20 > Peter. I'm not sure where I've read it. Probably some blog entry about the inciden= t. Not Bruce Schneier's because his entries are still online.=20 Anyway, checking the data for now, Business Week has this: http://investing.businessweek.com/research/stocks/private/people.asp?privca= pId=3D20888814 It lists two "key executives", VP Marketing and VP Sales and no CEO/Preside= nt. Click their links, and both have other jobs at Globalsign and other com= panies. The key issue is the total lack of in-house expertise. Late in 2008, it was= n't RapidSSL that switched to MD5. Verisign did it for them: http://www.thetechherald.com/article.php/200852/2708/VeriSign-replaces-Rapi= dSSL-certificates From SChokhani@cygnacom.com Mon Jun 6 07:23:57 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1326511E814D for ; Mon, 6 Jun 2011 07:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 kvBeyYxsxP46 for ; Mon, 6 Jun 2011 07:23:56 -0700 (PDT) Received: from sottexchE1.entrust.com (sottexche1.entrust.com [216.191.252.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4956911E8154 for ; Mon, 6 Jun 2011 07:23:56 -0700 (PDT) Received: from scygexch7.cygnacom.com (10.4.60.22) by sottexchE1.entrust.com (216.191.252.21) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 6 Jun 2011 10:23:44 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 6 Jun 2011 10:23:54 -0400 From: Santosh Chokhani To: "pkix@ietf.org" Date: Mon, 6 Jun 2011 10:23:53 -0400 Thread-Topic: [pkix] Trusted responders in OCSP Thread-Index: AcweroVWju5WAE6aQuqGb4r0IbxomwFpmZoQ Message-ID: References: <4DE3513F.1060308@primekey.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Trusted responders in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 14:23:57 -0000 I finally got around to reading the current 2560 bis draft. I would vote against it since it sacrifices security explicitly stated or i= mplied in 2560. My arguments are well recorded in PKIX forum. I will not = repeat those. In addition, an OCSP client may have interoperability proble= ms with a server claiming compliance with this draft standard. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ste= fan Santesson Sent: Monday, May 30, 2011 5:47 AM To: Tomas Gustavsson; pkix@ietf.org Subject: Re: [pkix] Trusted responders in OCSP This is how I would like to change this section in RFC 2560bis http://tinyurl.com/2560bis-tr /Stefan On 11-05-30 10:11 AM, "Tomas Gustavsson" wrote: > >I agree that, also according to my experience, this is how OCSP >validation works in practice today. Wich is probably why it generally >works quite well. > >Cheers, >Tomas > >On 05/28/2011 09:24 PM, Stefan Santesson wrote: >> I'm worried about the new wording in rfc2560bis regarding trusted >> responders. >>=20 >> I've spent some time now doing actual implementation of OCSP checking >> using existing libraries and I fear that current RFC 256obis will cause >> more confusion and less interoperability, than if we keep 2560 as it is. >>=20 >> The current bis text might be all "X.509" purish but it is not very >> helpful in attaining interoperability. >>=20 >> RFC 2560 does not deal with key rollover. It seams to assume that CAs do >> what they in practice always do, i.e. They let the lifetime of their >> issuing key exceed the lifetime of any certificate they issue. >> The self designation express that the responder certificate "is THE >> certificate of the CA" that issued the cert being checked. I interpret >> this to be the CA certificate found in the cert path of the certificate >> being validated. >>=20 >> Most implementers seems to have agreed and understood this to be an easy >> check. >>=20 >> If (response signature can be verified by CA cert) {check OK} else {ceck >> FAIL} >>=20 >> The same goes for designated responders: >>=20 >> If (designated responder cert can be verified by the CA cert) {check OK} >> else {ceck FAIL} >>=20 >>=20 >> Since this is the current configuration around which interoperability is >> achieved, this is the configuration that should be promoted in >> rfc2560bis as MUST implement for OCSP clients. >> Anything else should be OPTIONAL. >>=20 >> Beyond this there are a kazillion of configuration options for allowing >> key rollover, designated responders and even (which I have seen examples >> of) designated CAs only issuing responder certs. These are all fine in >> local communities under local policy, but no one should expect a general >> OCSP client to handle them. >>=20 >> /Stefan >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From dcarella@linagora.com Mon Jun 6 08:30:30 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0331021F8447 for ; Mon, 6 Jun 2011 08:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 EKCwAFb6tHyc for ; Mon, 6 Jun 2011 08:30:29 -0700 (PDT) Received: from alderaan.linagora.com (alderaan.linagora.com [109.197.183.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9887221F8442 for ; Mon, 6 Jun 2011 08:30:28 -0700 (PDT) Received: from [10.75.129.124] (unknown [10.75.129.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by alderaan.linagora.com (Postfix) with ESMTPSA id 5A5B8429EC2; Mon, 6 Jun 2011 17:30:26 +0200 (CEST) Message-ID: <4DECF291.3000805@linagora.com> Date: Mon, 06 Jun 2011 17:30:25 +0200 From: David CARELLA Organization: LINAGORA User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010104090803070406080409" Cc: Stefan Santesson Subject: Re: [pkix] Best practices for Certificate Policy OIDs in certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 15:30:30 -0000 This is a cryptographically signed message in MIME format. --------------ms010104090803070406080409 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Thank you for your answers. Russ: CPS URI is useful for human. I need several assurance levels, then I need several policy OIDs to=20 identify each assurance level. Peter G.: My questions are about technical and practical considerations, but not=20 about functional matter. Peter S.: To resume: several CA (probably too many) have used the OID policy=20 extension to put a reference to the policy (document), and it's wrong. Is it better to write only one policy document? And write in it all=20 policy OIDs. Then if I need OID for this policy document, I create=20 another OID branch: i.e. one branch for policy, and one branch for docume= nt. P.-S.: you have greetings from William too. Stefan: Policy OIDs are set in CA certificate as CRL distribution points. Policy = OIDs (as CRL DP) are set in CA or EE certificate by the CA issuer. So, if I do not need to limit to some policies, I don't set policy OIDs=20 in CA certificates. If I need, the better is to set policy OID (e.g.=20 only one policy) in the end CA (which issuing end entity certificates). Another questions: 1. If I don't set policy OID in CA certificates (and it's always right=20 for Root CA), which is better to set? - nothing (i.e. no certificate policy extension), - anyPolicy (2.5.29.32.0). --> If I set anyPolicy in a CA certificate, must I set anyPolicy into=20 all validation path CA certificates (i.e. "from this CA to Root CA")? 2. If I write only one policy document, must I indicate in it which=20 paragraph deals with which policy (e.g. by reference to its OID)? Hypothetical example: ----------- OID-1: this authentication certificate contains digitalSignature... OID-2: this signature certificate contains nonRepudiation... ----------- 3. Some PKI projects are split in several parts: Part #1 Root CA and=20 Server CA, Part #2 Encryption CA, Part #3 Signature CA. And these parts=20 can be done during non consecutive periods: e.g. Part #1 in 2011, Part=20 #2 in 2012, and Part #3 later. So what is the best practice to write the = policy document? a. Always update the same document (with a new minor document OID),=20 and add the new policy OIDs in it? b. Create several documents: one document for each CA: e.g.: - one document for Root CA (without policy OID) - one document for Server CA (with one policy OID) - one document for Encryption CA (with one policy OID) - one document for Signature CA (with one policy OID) Best regards, David On 06/02/2011 04:19 PM, Stefan Santesson wrote: > As Peter says, >=20 > Adding to that is that there is a common false thought that the policy = in > a CA:s certificate is a statement by that CA, while in fact it is a > statement by the CA above. >=20 > There are no reasons for practices used to issue CA certificates to be > represented as a policy OID. Such OID has no function in RFC 5280 path > validation. >=20 > So simplified: > A CA may put a policy OID in the certificates they issue. The semantics= > this carry is: > 1) If the issued certificate is a CA certificate: "Only the listed > policies can be validated in certificates issued under this CA" > 2) If the issued certificate is an EE certificate: "Only the listed > policies can be valid for this certificate" >=20 > A complicating fact is that the policy mechanism was originally designe= d > to be a usability declaration and not a full statement about the > procedures under which this certificate was issued. For the original > purpose, the path validation processing rules are logical. It has becom= e > very confusing as the policy OID has become more of a statement about > issuing procedures. It has caused CA certificate to carry policy OID th= at > has nothing to do with usage of EE certificates, and this is in total > conflict with RFC 5280 path validation. >=20 > /Stefan >=20 >=20 > On 11-06-02 9:32 AM, "Peter Sylvester" wro= te: >=20 >> On 06/02/2011 05:54 AM, Peter Gutmann wrote: >>> David CARELLA writes: >>> >>>> Nobody to answer my questions? >>> I think the reason no-one's replied is because the answer is "that's = a >>> policy >>> matter". So you need to formulate a policy as to which policy you wa= nt >>> to >>> follow. >> no, I missed the message: >> >> there is no such thing as a different policy identifier "for" a CA >> certificate. >> policy identifier in an (intermediate) CA certificat are a filter set = by >> the superior CA to indicate the list of EE certficate policies that >> are recognized as compatible which the superCA environment. >> >> putting "anypolicy" somewhere indicates essentially that you accept >> everything. >> >> Sub CA 2: Certificate policy: >> - policyIdentifier: anyPolicy [2.5.29.32.0] >> - policyQualifiers: - cPSuri: URI >> >> End entity: Certificate policy: >> - policyIdentifier: OID (OID-2) >> >> as in this example, the anypolicy permits that OUI-2 works, >> but only if your initial policy set contains well, left as >> an exercise. >> >> (c) user-initial-policy-set: A set of certificate policy >> identifiers naming the policies that are acceptable to the >> certificate user. The user-initial-policy-set contains the= >> special value any-policy if the user is not concerned about= >> certificate policy. >> >> the reason for trying to have an OID for a CA is a >> very common misunderstanding in several policy documents >> which confused the OIDs that one puts into certificates which >> an identification of a document (seen as "Identification: oid" >> in te beginning of a policy statement, or as other OIDs describing >> documents with practices. >> >> In particular, the French "PC type"s is wrong: >> >> it says that you write in a policy statement >> >> "Le num=E9ro d=B9OID du pr=E9sent document est xxxx" >> "the OID number of the present document is xxxx" >> >> which is not wrong by itself, but then it specifies that it >> this number that you put into a certificate that you issue. >> as a consequence, when people write >> "policy statement documents" for CAs which is not an >> unreasonable thing, it is a diffrent document, >> it has some OID, and well, one wants to put it into >> CA certificates ... into a place which is not designed for that. >> >> in such a CA "policy document", one has to write something like >> "this CA recognises the following policies (list of OID)" >> these OIDs are those that are put into EE certs of >> recognized CAs. >> >> to resume the confusion: >> >> a "policy oid" and an OID used to classify a "(policy) document" >> are different things and unrelated. >> >> Peter >> PS: >> 2 David: greetings to William >> >> --------------ms010104090803070406080409 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMJTCC BAMwggLroAMCAQICCHZrVD9y43neMA0GCSqGSIb3DQEBBQUAMBwxGjAYBgNVBAMMEUNBIExJ TkFHT1JBIEdST1VQMB4XDTA3MDcyMzA3NTM1MVoXDTE3MDcxMDA4MDM1MVowLTESMBAGA1UE AwwJQ0EgQ09MTEFCMRcwFQYDVQQKDA5MSU5BR09SQSBHUk9VUDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALTXK0N2Wd0pQ+ucWgmy3SokSWyIWdYxr/f5KoFdHg6bwVVN3wD6 GW1Ewbi4xJsVexDIhc1S9Njb4+glYTDfSNAoRCEGfpZ+Mek741EUnS7dS467eNOnEgpZfZpv nBP5lRsQCR25DsAf236ZJtoFb9VctQmZfr1e/DN3MhH0Zqa6g+7U/G/41PAiVXvw0veLAIGR 7ZiJCzoL1UDyoZGmPChR4W6PjopLi2Oq5i2KoaXyrBL8Tap1QA6ZdvHTiM0D8ZfQrIRJTMS2 L1ymLHf/7upbAs/wH7KavjRoD3zFMLDuyq7IIe9CvwZsjM0CRCgvizS2MfhyxDqiQ1t8+H8E Wk0CAwEAAaOCATYwggEyMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgEGMB0GA1UdDgQW BBTENOWEtL52Qp29lOb6whXompCr4TAfBgNVHSMEGDAWgBQvc8LRIUDdJ9aW1CW0KYaORcMT dDBbBgNVHSAEVDBSMFAGCysGAQQB1T8VAQEBMEEwPwYIKwYBBQUHAgEWM2h0dHBzOi8vaW50 cmFuZXQubGluYWdvcmEuY29tL2Rva3V3aWtpL3N1cHBvcnQvcGtpLzA7BgNVHR8ENDAyMDCg LqAshipodHRwOi8vcGtpLmxpbmFnb3JhLmNvbS9jcmwvQUNfTE5HX0dSUC5jcmwwOAYIKwYB BQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLmxpbmFnb3JhLmNvbS9vY3NwMA0G CSqGSIb3DQEBBQUAA4IBAQBvqaK+ovlV4ndR+Ql9JWxDQFNyIz3iijlvbBhXOhN8QNcPUE3y qA1duJSqf3lmj5EmOXrSZ/HIKDD+2KkQLs6jxAdJxFNWKhrqD6Tp/PiNJQQawkK7NFp4T3I5 0VlPbTdQqYCwF62ESCR/lVcY5HyfaGH6RyGem6EkT45SH1ZiYCWQbvV84iH19NV55rjebH5r Sm1haE19rFy1LwV+zbLG/sNELVzymRKl8TFP+8l6JMBfssl/DblsNOJnoSa3LCV51U/lSrki xD3AVzW6Sl1fXP0FQ7vuOHtMdmMc6/TDVSdeQSvx7XFOnntevbRqmnj1R72QgioALF77edYX eOuUMIIECzCCAvOgAwIBAgIIMXa9e1yIL3AwDQYJKoZIhvcNAQEFBQAwLTESMBAGA1UEAwwJ Q0EgQ09MTEFCMRcwFQYDVQQKDA5MSU5BR09SQSBHUk9VUDAeFw0xMDA4MjUwOTU3MzNaFw0x MTA4MjUwOTU3MzNaMFUxGDAWBgoJkiaJk/IsZAEBDAhkY2FyZWxsYTEWMBQGA1UEAwwNRGF2 aWQgQ0FSRUxMQTEOMAwGA1UECwwFcGFyaXMxETAPBgNVBAoMCExpbmFnb3JhMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCyhGYoNsNmVRVlNcsUxJkyloZpVmPyGx2/uKW9PVxPEbB9 YMnqIQZ7y/J4Olud6Qthaxp6hi/FS6Rv9fGEVuFQRDemqjk0rRCycG1m+X/VOnnmdCHcJ5Ux qur9e9TSBfNI4BTCu/y7mhwi7dM1cRoWCVx8UlThl99r2dYjnK0UuQIDAQABo4IBiTCCAYUw CQYDVR0TBAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHwYDVR0jBBgwFoAU xDTlhLS+dkKdvZTm+sIV6JqQq+EwPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraS5saW5h Z29yYS5jb20vY3JsL0FDX0xOR19DT0xMQUIuY3JsMAsGA1UdDwQEAwIE8DAdBgNVHQ4EFgQU oGaJFBmD2h5YmX0xZyR+0LjB9vUwWwYDVR0gBFQwUjBQBgsrBgEEAdU/FQEBATBBMD8GCCsG AQUFBwIBFjNodHRwczovL2ludHJhbmV0LmxpbmFnb3JhLmNvbS9kb2t1d2lraS9zdXBwb3J0 L3BraS8wTQYIKwYBBQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vbG9jYWxob3N0Ojgw ODAvZWpiY2EvcHVibGljd2ViL3N0YXR1cy9vY3NwMCAGA1UdEQQZMBeBFWRjYXJlbGxhQGxp bmFnb3JhLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAE3Wae4lVIj7rPvzOdURuHbtGqDq18y6Q wXDV1vsVgmZ471K00lmsBGOUpVj8N8KVNu5XHZfUip4spI3kIztsUhxpUv+WoUH9R0ObmoiX pPfFxnaI+j1A5MLWkXPVpXsaFgzxU8WLZs0BBEbxKkXYauJ9GC+YhhJjHr4qLqFXNtnJhrVm fNJaQCmTo27wasnfPRIPiHfH35PYgdK/eGFMbYYY+meskWyMS6rBROGCkOUAKBqqv8MqH257 zZf51UoQ2kNUMpJiAgJhkT2yF26OnBH94tqv+X/hs74wgfhnzqtO51n7lX0GlP6cWaBLwZq7 Qh2i1BpdMPZczttSlqwMqTCCBAswggLzoAMCAQICCDF2vXtciC9wMA0GCSqGSIb3DQEBBQUA MC0xEjAQBgNVBAMMCUNBIENPTExBQjEXMBUGA1UECgwOTElOQUdPUkEgR1JPVVAwHhcNMTAw ODI1MDk1NzMzWhcNMTEwODI1MDk1NzMzWjBVMRgwFgYKCZImiZPyLGQBAQwIZGNhcmVsbGEx FjAUBgNVBAMMDURhdmlkIENBUkVMTEExDjAMBgNVBAsMBXBhcmlzMREwDwYDVQQKDAhMaW5h Z29yYTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsoRmKDbDZlUVZTXLFMSZMpaGaVZj 8hsdv7ilvT1cTxGwfWDJ6iEGe8vyeDpbnekLYWsaeoYvxUukb/XxhFbhUEQ3pqo5NK0QsnBt Zvl/1Tp55nQh3CeVMarq/XvU0gXzSOAUwrv8u5ocIu3TNXEaFglcfFJU4Zffa9nWI5ytFLkC AwEAAaOCAYkwggGFMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MB8GA1UdIwQYMBaAFMQ05YS0vnZCnb2U5vrCFeiakKvhMD4GA1UdHwQ3MDUwM6AxoC+GLWh0 dHA6Ly9wa2kubGluYWdvcmEuY29tL2NybC9BQ19MTkdfQ09MTEFCLmNybDALBgNVHQ8EBAMC BPAwHQYDVR0OBBYEFKBmiRQZg9oeWJl9MWckftC4wfb1MFsGA1UdIARUMFIwUAYLKwYBBAHV PxUBAQEwQTA/BggrBgEFBQcCARYzaHR0cHM6Ly9pbnRyYW5ldC5saW5hZ29yYS5jb20vZG9r dXdpa2kvc3VwcG9ydC9wa2kvME0GCCsGAQUFBwEBBEEwPzA9BggrBgEFBQcwAYYxaHR0cDov L2xvY2FsaG9zdDo4MDgwL2VqYmNhL3B1YmxpY3dlYi9zdGF0dXMvb2NzcDAgBgNVHREEGTAX gRVkY2FyZWxsYUBsaW5hZ29yYS5jb20wDQYJKoZIhvcNAQEFBQADggEBABN1mnuJVSI+6z78 znVEbh27Rqg6tfMukMFw1db7FYJmeO9StNJZrARjlKVY/DfClTbuVx2X1IqeLKSN5CM7bFIc aVL/lqFB/UdDm5qIl6T3xcZ2iPo9QOTC1pFz1aV7GhYM8VPFi2bNAQRG8SpF2GrifRgvmIYS Yx6+Ki6hVzbZyYa1ZnzSWkApk6Nu8GrJ3z0SD4h3x9+T2IHSv3hhTG2GGPpnrJFsjEuqwUTh gpDlACgaqr/DKh9ue82X+dVKENpDVDKSYgICYZE9shdujpwR/eLar/l/4bO+MIH4Z86rTudZ +5V9BpT+nFmgS8Gau0IdotQaXTD2XM7bUpasDKkxggI3MIICMwIBATA5MC0xEjAQBgNVBAMM CUNBIENPTExBQjEXMBUGA1UECgwOTElOQUdPUkEgR1JPVVACCDF2vXtciC9wMAkGBSsOAwIa BQCgggFUMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYw NjE1MzAyNVowIwYJKoZIhvcNAQkEMRYEFNO/BSxANZ8MVWQet4p7mvNGsgg6MEgGCSsGAQQB gjcQBDE7MDkwLTESMBAGA1UEAwwJQ0EgQ09MTEFCMRcwFQYDVQQKDA5MSU5BR09SQSBHUk9V UAIIMXa9e1yIL3AwSgYLKoZIhvcNAQkQAgsxO6A5MC0xEjAQBgNVBAMMCUNBIENPTExBQjEX MBUGA1UECgwOTElOQUdPUkEgR1JPVVACCDF2vXtciC9wMF8GCSqGSIb3DQEJDzFSMFAwCwYJ YIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgEa9HgZcAp8zPyTZX7bb wnoUkaxKG94gYpIeABycsansF+YKy37FJQay5ZJwYnPg+L8Aq4YKUGsNEoh3gzUSNHVMX1PG OxuQSenB0RVGFcsdEdOWTLgCRK/5rFJL2GTbJpl9uffXs0eslIGoJ+CnBc1emkyllLmwvwAG RWqCLcPDAAAAAAAA --------------ms010104090803070406080409-- From stefan@aaa-sec.com Mon Jun 6 09:52:53 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137AE11E8195 for ; Mon, 6 Jun 2011 09:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_21=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 rLnePS3igjjV for ; Mon, 6 Jun 2011 09:52:52 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC0C11E816E for ; Mon, 6 Jun 2011 09:52:44 -0700 (PDT) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 59D13493E11 for ; Mon, 6 Jun 2011 18:52:13 +0200 (CEST) Received: (qmail 60340 invoked from network); 6 Jun 2011 16:52:06 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.8]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 6 Jun 2011 16:52:06 -0000 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Mon, 06 Jun 2011 18:52:03 +0200 From: Stefan Santesson To: David CARELLA , Message-ID: Thread-Topic: [pkix] Best practices for Certificate Policy OIDs in certificates In-Reply-To: <4DECF291.3000805@linagora.com> Mime-version: 1.0 Content-type: text/plain; charset="windows-1254" Content-transfer-encoding: quoted-printable Subject: Re: [pkix] Best practices for Certificate Policy OIDs in certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 16:52:53 -0000 David, Unfortunately I find your reasoning very confusing and hence your questions are hard to answer. Some generics. - No, policy OIDs are not placed in CRL DPs, they are placed in the certificate policies extension. - Yes you might explain the meaning of several policy OIDs in one document. - Yes, you need to set the anyPolicy in all CA certificates, or set explicit policies in order to avoid the result set of valid policies to be empty. Root certificates are excluded from this requirement. /Stefan On 11-06-06 5:30 PM, "David CARELLA" wrote: >Hi, > >Thank you for your answers. > >Russ: >CPS URI is useful for human. >I need several assurance levels, then I need several policy OIDs to >identify each assurance level. > >Peter G.: >My questions are about technical and practical considerations, but not >about functional matter. > >Peter S.: >To resume: several CA (probably too many) have used the OID policy >extension to put a reference to the policy (document), and it's wrong. >Is it better to write only one policy document? And write in it all >policy OIDs. Then if I need OID for this policy document, I create >another OID branch: i.e. one branch for policy, and one branch for >document. >P.-S.: you have greetings from William too. > >Stefan: >Policy OIDs are set in CA certificate as CRL distribution points. Policy >OIDs (as CRL DP) are set in CA or EE certificate by the CA issuer. >So, if I do not need to limit to some policies, I don't set policy OIDs >in CA certificates. If I need, the better is to set policy OID (e.g. >only one policy) in the end CA (which issuing end entity certificates). > > >Another questions: > >1. If I don't set policy OID in CA certificates (and it's always right >for Root CA), which is better to set? >- nothing (i.e. no certificate policy extension), >- anyPolicy (2.5.29.32.0). >--> If I set anyPolicy in a CA certificate, must I set anyPolicy into >all validation path CA certificates (i.e. "from this CA to Root CA")? > >2. If I write only one policy document, must I indicate in it which >paragraph deals with which policy (e.g. by reference to its OID)? >Hypothetical example: >----------- >OID-1: this authentication certificate contains digitalSignature... >OID-2: this signature certificate contains nonRepudiation... >----------- > >3. Some PKI projects are split in several parts: Part #1 Root CA and >Server CA, Part #2 Encryption CA, Part #3 Signature CA. And these parts >can be done during non consecutive periods: e.g. Part #1 in 2011, Part >#2 in 2012, and Part #3 later. So what is the best practice to write the >policy document? > a. Always update the same document (with a new minor document OID), >and add the new policy OIDs in it? > b. Create several documents: one document for each CA: e.g.: > - one document for Root CA (without policy OID) > - one document for Server CA (with one policy OID) > - one document for Encryption CA (with one policy OID) > - one document for Signature CA (with one policy OID) > > >Best regards, >David > > >On 06/02/2011 04:19 PM, Stefan Santesson wrote: >> As Peter says, >>=20 >> Adding to that is that there is a common false thought that the policy >>in >> a CA:s certificate is a statement by that CA, while in fact it is a >> statement by the CA above. >>=20 >> There are no reasons for practices used to issue CA certificates to be >> represented as a policy OID. Such OID has no function in RFC 5280 path >> validation. >>=20 >> So simplified: >> A CA may put a policy OID in the certificates they issue. The semantics >> this carry is: >> 1) If the issued certificate is a CA certificate: "Only the listed >> policies can be validated in certificates issued under this CA" >> 2) If the issued certificate is an EE certificate: "Only the listed >> policies can be valid for this certificate" >>=20 >> A complicating fact is that the policy mechanism was originally designed >> to be a usability declaration and not a full statement about the >> procedures under which this certificate was issued. For the original >> purpose, the path validation processing rules are logical. It has become >> very confusing as the policy OID has become more of a statement about >> issuing procedures. It has caused CA certificate to carry policy OID >>that >> has nothing to do with usage of EE certificates, and this is in total >> conflict with RFC 5280 path validation. >>=20 >> /Stefan >>=20 >>=20 >> On 11-06-02 9:32 AM, "Peter Sylvester" >>wrote: >>=20 >>> On 06/02/2011 05:54 AM, Peter Gutmann wrote: >>>> David CARELLA writes: >>>> >>>>> Nobody to answer my questions? >>>> I think the reason no-one's replied is because the answer is "that's a >>>> policy >>>> matter". So you need to formulate a policy as to which policy you >>>>want >>>> to >>>> follow. >>> no, I missed the message: >>> >>> there is no such thing as a different policy identifier "for" a CA >>> certificate. >>> policy identifier in an (intermediate) CA certificat are a filter set >>>by >>> the superior CA to indicate the list of EE certficate policies that >>> are recognized as compatible which the superCA environment. >>> >>> putting "anypolicy" somewhere indicates essentially that you accept >>> everything. >>> >>> Sub CA 2: Certificate policy: >>> - policyIdentifier: anyPolicy [2.5.29.32.0] >>> - policyQualifiers: - cPSuri: URI >>> >>> End entity: Certificate policy: >>> - policyIdentifier: OID (OID-2) >>> >>> as in this example, the anypolicy permits that OUI-2 works, >>> but only if your initial policy set contains well, left as >>> an exercise. >>> >>> (c) user-initial-policy-set: A set of certificate policy >>> identifiers naming the policies that are acceptable to the >>> certificate user. The user-initial-policy-set contains the >>> special value any-policy if the user is not concerned about >>> certificate policy. >>> >>> the reason for trying to have an OID for a CA is a >>> very common misunderstanding in several policy documents >>> which confused the OIDs that one puts into certificates which >>> an identification of a document (seen as "Identification: oid" >>> in te beginning of a policy statement, or as other OIDs describing >>> documents with practices. >>> >>> In particular, the French "PC type"s is wrong: >>> >>> it says that you write in a policy statement >>> >>> "Le num=E9ro d=B9OID du pr=E9sent document est xxxx" >>> "the OID number of the present document is xxxx" >>> >>> which is not wrong by itself, but then it specifies that it >>> this number that you put into a certificate that you issue. >>> as a consequence, when people write >>> "policy statement documents" for CAs which is not an >>> unreasonable thing, it is a diffrent document, >>> it has some OID, and well, one wants to put it into >>> CA certificates ... into a place which is not designed for that. >>> >>> in such a CA "policy document", one has to write something like >>> "this CA recognises the following policies (list of OID)" >>> these OIDs are those that are put into EE certs of >>> recognized CAs. >>> >>> to resume the confusion: >>> >>> a "policy oid" and an OID used to classify a "(policy) document" >>> are different things and unrelated. >>> >>> Peter >>> PS: >>> 2 David: greetings to William >>> >>> > From koichi.sugimoto@globalsign.com Mon Jun 6 18:32:02 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A762311E8096; Mon, 6 Jun 2011 18:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DEAR_SOMETHING=1.605, 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 bTXsdE5lYO9x; Mon, 6 Jun 2011 18:32:01 -0700 (PDT) Received: from mail-pz0-f66.google.com (mail-pz0-f66.google.com [209.85.210.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5F59011E8090; Mon, 6 Jun 2011 18:32:01 -0700 (PDT) Received: by pzk7 with SMTP id 7so449896pzk.1 for ; Mon, 06 Jun 2011 18:32:00 -0700 (PDT) Received: by 10.68.22.231 with SMTP id h7mr24678pbf.25.1307410320794; Mon, 06 Jun 2011 18:32:00 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id o2sm4076833pbj.65.2011.06.06.18.32.00 (version=SSLv3 cipher=OTHER); Mon, 06 Jun 2011 18:32:00 -0700 (PDT) Received: by pzk5 with SMTP id 5so2448373pzk.31 for ; Mon, 06 Jun 2011 18:32:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.17.129 with SMTP id o1mr2256205pbd.178.1307410320002; Mon, 06 Jun 2011 18:32:00 -0700 (PDT) Received: by 10.68.52.166 with HTTP; Mon, 6 Jun 2011 18:31:59 -0700 (PDT) In-Reply-To: <81856AC0-F6FB-4321-93FE-559D5C5E2743@checkpoint.com> References: <81856AC0-F6FB-4321-93FE-559D5C5E2743@checkpoint.com> Date: Tue, 7 Jun 2011 10:31:59 +0900 Message-ID: From: koichi sugimoto To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" , "tls@ietf.org" Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 01:32:02 -0000 Dear Sirs, I've heard the fact was as follows: ------------------------------------------------------------------------- Paul Tourret and Steve Waite were independent agents assigned the responsibility of sales and marketing for the RapidSSL brand, acting under a company called Certification Services Ltd (CSL). Verisign served termination notice to CSL immediately after the announcement of the GeoTrust acquisition. CSL then later changed its name to GlobalSign Limited following successful acquisition of GlobalSign NV. RapidSSL.com was, and always had been, an SSL brand owned in full by GeoTrust Inc. GeoTrust elected to represent the brand as a business unit and as mentioned above, Paul Tourret and Steve Waite were assigned as "agents" to promote the brand. All root Certificates and infrastructure was maintained and operated alongside the GeoTrust branded roots and in infrastructure operated by GeoTrust Inc. In 2006 VeriSign acquired GeoTrust and all its assets, including the RapidSSL brand and root Certificates. Paul and Steve ceased their relationship with GeoTrust (now owned by VeriSign) in late 2006. At the time of the rogue issuance of RapidSSL root Certificates, ownership and infrastructure of maintenance had been under VeriSign's control for over 2 years. To be clear, VeriSign did not switch away from MD5 on behalf of RapidSSL, RapidSSL is just a product brand (not a company) owned in full by VeriSign. ---------------------------------------------------------------------------= --------------- Regards, Koichi Sugimoto. 2011/6/5 Yoav Nir : > > On Jun 3, 2011, at 5:55 AM, Peter Gutmann wrote: > >> Yoav Nir writes: >> >>> In late 2008, when some researchers got RapidSSL to sign a certificate >>> request that collided with their rogue sub-CA certificate, several thin= gs >>> came to light: >>> - They were a ridiculously small company, with the only full-time emplo= yee. >>> An accountant >> >> I wasn't aware of this one, do you have any pointers to info on this? = =A0I guess >> a Webtrust audit doesn't check whether you have more than a single emplo= yee :-). >> >> Peter. > > I'm not sure where I've read it. Probably some blog entry about the incid= ent. Not Bruce Schneier's because his entries are still online. > > Anyway, checking the data for now, Business Week has this: > http://investing.businessweek.com/research/stocks/private/people.asp?priv= capId=3D20888814 > > It lists two "key executives", VP Marketing and VP Sales and no CEO/Presi= dent. Click their links, and both have other jobs at Globalsign and other c= ompanies. > > The key issue is the total lack of in-house expertise. Late in 2008, it w= asn't RapidSSL that switched to MD5. Verisign did it for them: > http://www.thetechherald.com/article.php/200852/2708/VeriSign-replaces-Ra= pidSSL-certificates > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From dcarella@linagora.com Tue Jun 7 02:30:15 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF0B11E80B9 for ; Tue, 7 Jun 2011 02:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 YCpuYW5CTrQ9 for ; Tue, 7 Jun 2011 02:30:14 -0700 (PDT) Received: from alderaan.linagora.com (alderaan.linagora.com [109.197.183.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3111F11E8095 for ; Tue, 7 Jun 2011 02:30:13 -0700 (PDT) Received: from [10.75.129.124] (unknown [10.75.129.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by alderaan.linagora.com (Postfix) with ESMTPSA id F1DFF429EC4; Tue, 7 Jun 2011 11:30:09 +0200 (CEST) Message-ID: <4DEDEFA1.1090707@linagora.com> Date: Tue, 07 Jun 2011 11:30:09 +0200 From: David CARELLA Organization: LINAGORA User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090403020509010501000902" Cc: pkix@ietf.org Subject: Re: [pkix] Best practices for Certificate Policy OIDs in certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 09:30:15 -0000 This is a cryptographically signed message in MIME format. --------------ms090403020509010501000902 Content-Type: text/plain; charset=windows-1254; format=flowed Content-Transfer-Encoding: quoted-printable Hello, Of course, CRL DPs is another subject no related to policy OIDs. My English isn't good enough to put into words my mind. You had answered to my questions. Thank you. David On 06/06/2011 06:52 PM, Stefan Santesson wrote: > David, >=20 > Unfortunately I find your reasoning very confusing and hence your > questions are hard to answer. Some generics. >=20 > - No, policy OIDs are not placed in CRL DPs, they are placed in the > certificate policies extension. > - Yes you might explain the meaning of several policy OIDs in one docum= ent. > - Yes, you need to set the anyPolicy in all CA certificates, or set > explicit policies in order to avoid the result set of valid policies to= be > empty. Root certificates are excluded from this requirement. >=20 > /Stefan >=20 >=20 > On 11-06-06 5:30 PM, "David CARELLA" wrote: >=20 >> Hi, >> >> Thank you for your answers. >> >> Russ: >> CPS URI is useful for human. >> I need several assurance levels, then I need several policy OIDs to >> identify each assurance level. >> >> Peter G.: >> My questions are about technical and practical considerations, but not= >> about functional matter. >> >> Peter S.: >> To resume: several CA (probably too many) have used the OID policy >> extension to put a reference to the policy (document), and it's wrong.= >> Is it better to write only one policy document? And write in it all >> policy OIDs. Then if I need OID for this policy document, I create >> another OID branch: i.e. one branch for policy, and one branch for >> document. >> P.-S.: you have greetings from William too. >> >> Stefan: >> Policy OIDs are set in CA certificate as CRL distribution points. Poli= cy >> OIDs (as CRL DP) are set in CA or EE certificate by the CA issuer. >> So, if I do not need to limit to some policies, I don't set policy OID= s >> in CA certificates. If I need, the better is to set policy OID (e.g. >> only one policy) in the end CA (which issuing end entity certificates)= =2E >> >> >> Another questions: >> >> 1. If I don't set policy OID in CA certificates (and it's always right= >> for Root CA), which is better to set? >> - nothing (i.e. no certificate policy extension), >> - anyPolicy (2.5.29.32.0). >> --> If I set anyPolicy in a CA certificate, must I set anyPolicy into >> all validation path CA certificates (i.e. "from this CA to Root CA")? >> >> 2. If I write only one policy document, must I indicate in it which >> paragraph deals with which policy (e.g. by reference to its OID)? >> Hypothetical example: >> ----------- >> OID-1: this authentication certificate contains digitalSignature... >> OID-2: this signature certificate contains nonRepudiation... >> ----------- >> >> 3. Some PKI projects are split in several parts: Part #1 Root CA and >> Server CA, Part #2 Encryption CA, Part #3 Signature CA. And these part= s >> can be done during non consecutive periods: e.g. Part #1 in 2011, Part= >> #2 in 2012, and Part #3 later. So what is the best practice to write t= he >> policy document? >> a. Always update the same document (with a new minor document OID), >> and add the new policy OIDs in it? >> b. Create several documents: one document for each CA: e.g.: >> - one document for Root CA (without policy OID) >> - one document for Server CA (with one policy OID) >> - one document for Encryption CA (with one policy OID) >> - one document for Signature CA (with one policy OID) >> >> >> Best regards, >> David >> >> >> On 06/02/2011 04:19 PM, Stefan Santesson wrote: >>> As Peter says, >>> >>> Adding to that is that there is a common false thought that the polic= y >>> in >>> a CA:s certificate is a statement by that CA, while in fact it is a >>> statement by the CA above. >>> >>> There are no reasons for practices used to issue CA certificates to b= e >>> represented as a policy OID. Such OID has no function in RFC 5280 pat= h >>> validation. >>> >>> So simplified: >>> A CA may put a policy OID in the certificates they issue. The semanti= cs >>> this carry is: >>> 1) If the issued certificate is a CA certificate: "Only the listed >>> policies can be validated in certificates issued under this CA" >>> 2) If the issued certificate is an EE certificate: "Only the listed >>> policies can be valid for this certificate" >>> >>> A complicating fact is that the policy mechanism was originally desig= ned >>> to be a usability declaration and not a full statement about the >>> procedures under which this certificate was issued. For the original >>> purpose, the path validation processing rules are logical. It has bec= ome >>> very confusing as the policy OID has become more of a statement about= >>> issuing procedures. It has caused CA certificate to carry policy OID >>> that >>> has nothing to do with usage of EE certificates, and this is in total= >>> conflict with RFC 5280 path validation. >>> >>> /Stefan >>> >>> >>> On 11-06-02 9:32 AM, "Peter Sylvester" >>> wrote: >>> >>>> On 06/02/2011 05:54 AM, Peter Gutmann wrote: >>>>> David CARELLA writes: >>>>> >>>>>> Nobody to answer my questions? >>>>> I think the reason no-one's replied is because the answer is "that'= s a >>>>> policy >>>>> matter". So you need to formulate a policy as to which policy you >>>>> want >>>>> to >>>>> follow. >>>> no, I missed the message: >>>> >>>> there is no such thing as a different policy identifier "for" a CA >>>> certificate. >>>> policy identifier in an (intermediate) CA certificat are a filter se= t >>>> by >>>> the superior CA to indicate the list of EE certficate policies that >>>> are recognized as compatible which the superCA environment. >>>> >>>> putting "anypolicy" somewhere indicates essentially that you accept >>>> everything. >>>> >>>> Sub CA 2: Certificate policy: >>>> - policyIdentifier: anyPolicy [2.5.29.32.0] >>>> - policyQualifiers: - cPSuri: URI >>>> >>>> End entity: Certificate policy: >>>> - policyIdentifier: OID (OID-2) >>>> >>>> as in this example, the anypolicy permits that OUI-2 works, >>>> but only if your initial policy set contains well, left as >>>> an exercise. >>>> >>>> (c) user-initial-policy-set: A set of certificate policy >>>> identifiers naming the policies that are acceptable to th= e >>>> certificate user. The user-initial-policy-set contains t= he >>>> special value any-policy if the user is not concerned abo= ut >>>> certificate policy. >>>> >>>> the reason for trying to have an OID for a CA is a >>>> very common misunderstanding in several policy documents >>>> which confused the OIDs that one puts into certificates which >>>> an identification of a document (seen as "Identification: oid" >>>> in te beginning of a policy statement, or as other OIDs describing >>>> documents with practices. >>>> >>>> In particular, the French "PC type"s is wrong: >>>> >>>> it says that you write in a policy statement >>>> >>>> "Le num=E9ro d=B9OID du pr=E9sent document est xxxx" >>>> "the OID number of the present document is xxxx" >>>> >>>> which is not wrong by itself, but then it specifies that it >>>> this number that you put into a certificate that you issue. >>>> as a consequence, when people write >>>> "policy statement documents" for CAs which is not an >>>> unreasonable thing, it is a diffrent document, >>>> it has some OID, and well, one wants to put it into >>>> CA certificates ... into a place which is not designed for that. >>>> >>>> in such a CA "policy document", one has to write something like >>>> "this CA recognises the following policies (list of OID)" >>>> these OIDs are those that are put into EE certs of >>>> recognized CAs. >>>> >>>> to resume the confusion: >>>> >>>> a "policy oid" and an OID used to classify a "(policy) document" >>>> are different things and unrelated. >>>> >>>> Peter >>>> PS: >>>> 2 David: greetings to William >>>> >>>> >=20 >=20 --=20 David CARELLA Ing=E9nieur Expert PKI, Chef de projet S=E9curit=E9 LINAGORA - LGS - P=F4le S=E9curit=E9 Courriel : dcarella@linagora.com T=E9l. : +33 (0)1 46 96 63 63, poste 550 Fax : +33 (0)1 46 96 63 64 Groupe LINAGORA - www.linagora.com LinPKI, offres s=E9curit=E9 - www.linpki.org EJBCA-fr, PKI open source - www.ejbca-fr.org --------------ms090403020509010501000902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMJTCC BAMwggLroAMCAQICCHZrVD9y43neMA0GCSqGSIb3DQEBBQUAMBwxGjAYBgNVBAMMEUNBIExJ TkFHT1JBIEdST1VQMB4XDTA3MDcyMzA3NTM1MVoXDTE3MDcxMDA4MDM1MVowLTESMBAGA1UE AwwJQ0EgQ09MTEFCMRcwFQYDVQQKDA5MSU5BR09SQSBHUk9VUDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALTXK0N2Wd0pQ+ucWgmy3SokSWyIWdYxr/f5KoFdHg6bwVVN3wD6 GW1Ewbi4xJsVexDIhc1S9Njb4+glYTDfSNAoRCEGfpZ+Mek741EUnS7dS467eNOnEgpZfZpv nBP5lRsQCR25DsAf236ZJtoFb9VctQmZfr1e/DN3MhH0Zqa6g+7U/G/41PAiVXvw0veLAIGR 7ZiJCzoL1UDyoZGmPChR4W6PjopLi2Oq5i2KoaXyrBL8Tap1QA6ZdvHTiM0D8ZfQrIRJTMS2 L1ymLHf/7upbAs/wH7KavjRoD3zFMLDuyq7IIe9CvwZsjM0CRCgvizS2MfhyxDqiQ1t8+H8E Wk0CAwEAAaOCATYwggEyMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgEGMB0GA1UdDgQW BBTENOWEtL52Qp29lOb6whXompCr4TAfBgNVHSMEGDAWgBQvc8LRIUDdJ9aW1CW0KYaORcMT dDBbBgNVHSAEVDBSMFAGCysGAQQB1T8VAQEBMEEwPwYIKwYBBQUHAgEWM2h0dHBzOi8vaW50 cmFuZXQubGluYWdvcmEuY29tL2Rva3V3aWtpL3N1cHBvcnQvcGtpLzA7BgNVHR8ENDAyMDCg LqAshipodHRwOi8vcGtpLmxpbmFnb3JhLmNvbS9jcmwvQUNfTE5HX0dSUC5jcmwwOAYIKwYB BQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLmxpbmFnb3JhLmNvbS9vY3NwMA0G CSqGSIb3DQEBBQUAA4IBAQBvqaK+ovlV4ndR+Ql9JWxDQFNyIz3iijlvbBhXOhN8QNcPUE3y qA1duJSqf3lmj5EmOXrSZ/HIKDD+2KkQLs6jxAdJxFNWKhrqD6Tp/PiNJQQawkK7NFp4T3I5 0VlPbTdQqYCwF62ESCR/lVcY5HyfaGH6RyGem6EkT45SH1ZiYCWQbvV84iH19NV55rjebH5r Sm1haE19rFy1LwV+zbLG/sNELVzymRKl8TFP+8l6JMBfssl/DblsNOJnoSa3LCV51U/lSrki xD3AVzW6Sl1fXP0FQ7vuOHtMdmMc6/TDVSdeQSvx7XFOnntevbRqmnj1R72QgioALF77edYX eOuUMIIECzCCAvOgAwIBAgIIMXa9e1yIL3AwDQYJKoZIhvcNAQEFBQAwLTESMBAGA1UEAwwJ Q0EgQ09MTEFCMRcwFQYDVQQKDA5MSU5BR09SQSBHUk9VUDAeFw0xMDA4MjUwOTU3MzNaFw0x MTA4MjUwOTU3MzNaMFUxGDAWBgoJkiaJk/IsZAEBDAhkY2FyZWxsYTEWMBQGA1UEAwwNRGF2 aWQgQ0FSRUxMQTEOMAwGA1UECwwFcGFyaXMxETAPBgNVBAoMCExpbmFnb3JhMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCyhGYoNsNmVRVlNcsUxJkyloZpVmPyGx2/uKW9PVxPEbB9 YMnqIQZ7y/J4Olud6Qthaxp6hi/FS6Rv9fGEVuFQRDemqjk0rRCycG1m+X/VOnnmdCHcJ5Ux qur9e9TSBfNI4BTCu/y7mhwi7dM1cRoWCVx8UlThl99r2dYjnK0UuQIDAQABo4IBiTCCAYUw CQYDVR0TBAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHwYDVR0jBBgwFoAU xDTlhLS+dkKdvZTm+sIV6JqQq+EwPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraS5saW5h Z29yYS5jb20vY3JsL0FDX0xOR19DT0xMQUIuY3JsMAsGA1UdDwQEAwIE8DAdBgNVHQ4EFgQU oGaJFBmD2h5YmX0xZyR+0LjB9vUwWwYDVR0gBFQwUjBQBgsrBgEEAdU/FQEBATBBMD8GCCsG AQUFBwIBFjNodHRwczovL2ludHJhbmV0LmxpbmFnb3JhLmNvbS9kb2t1d2lraS9zdXBwb3J0 L3BraS8wTQYIKwYBBQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vbG9jYWxob3N0Ojgw ODAvZWpiY2EvcHVibGljd2ViL3N0YXR1cy9vY3NwMCAGA1UdEQQZMBeBFWRjYXJlbGxhQGxp bmFnb3JhLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAE3Wae4lVIj7rPvzOdURuHbtGqDq18y6Q wXDV1vsVgmZ471K00lmsBGOUpVj8N8KVNu5XHZfUip4spI3kIztsUhxpUv+WoUH9R0ObmoiX pPfFxnaI+j1A5MLWkXPVpXsaFgzxU8WLZs0BBEbxKkXYauJ9GC+YhhJjHr4qLqFXNtnJhrVm fNJaQCmTo27wasnfPRIPiHfH35PYgdK/eGFMbYYY+meskWyMS6rBROGCkOUAKBqqv8MqH257 zZf51UoQ2kNUMpJiAgJhkT2yF26OnBH94tqv+X/hs74wgfhnzqtO51n7lX0GlP6cWaBLwZq7 Qh2i1BpdMPZczttSlqwMqTCCBAswggLzoAMCAQICCDF2vXtciC9wMA0GCSqGSIb3DQEBBQUA MC0xEjAQBgNVBAMMCUNBIENPTExBQjEXMBUGA1UECgwOTElOQUdPUkEgR1JPVVAwHhcNMTAw ODI1MDk1NzMzWhcNMTEwODI1MDk1NzMzWjBVMRgwFgYKCZImiZPyLGQBAQwIZGNhcmVsbGEx FjAUBgNVBAMMDURhdmlkIENBUkVMTEExDjAMBgNVBAsMBXBhcmlzMREwDwYDVQQKDAhMaW5h Z29yYTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsoRmKDbDZlUVZTXLFMSZMpaGaVZj 8hsdv7ilvT1cTxGwfWDJ6iEGe8vyeDpbnekLYWsaeoYvxUukb/XxhFbhUEQ3pqo5NK0QsnBt Zvl/1Tp55nQh3CeVMarq/XvU0gXzSOAUwrv8u5ocIu3TNXEaFglcfFJU4Zffa9nWI5ytFLkC AwEAAaOCAYkwggGFMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MB8GA1UdIwQYMBaAFMQ05YS0vnZCnb2U5vrCFeiakKvhMD4GA1UdHwQ3MDUwM6AxoC+GLWh0 dHA6Ly9wa2kubGluYWdvcmEuY29tL2NybC9BQ19MTkdfQ09MTEFCLmNybDALBgNVHQ8EBAMC BPAwHQYDVR0OBBYEFKBmiRQZg9oeWJl9MWckftC4wfb1MFsGA1UdIARUMFIwUAYLKwYBBAHV PxUBAQEwQTA/BggrBgEFBQcCARYzaHR0cHM6Ly9pbnRyYW5ldC5saW5hZ29yYS5jb20vZG9r dXdpa2kvc3VwcG9ydC9wa2kvME0GCCsGAQUFBwEBBEEwPzA9BggrBgEFBQcwAYYxaHR0cDov L2xvY2FsaG9zdDo4MDgwL2VqYmNhL3B1YmxpY3dlYi9zdGF0dXMvb2NzcDAgBgNVHREEGTAX gRVkY2FyZWxsYUBsaW5hZ29yYS5jb20wDQYJKoZIhvcNAQEFBQADggEBABN1mnuJVSI+6z78 znVEbh27Rqg6tfMukMFw1db7FYJmeO9StNJZrARjlKVY/DfClTbuVx2X1IqeLKSN5CM7bFIc aVL/lqFB/UdDm5qIl6T3xcZ2iPo9QOTC1pFz1aV7GhYM8VPFi2bNAQRG8SpF2GrifRgvmIYS Yx6+Ki6hVzbZyYa1ZnzSWkApk6Nu8GrJ3z0SD4h3x9+T2IHSv3hhTG2GGPpnrJFsjEuqwUTh gpDlACgaqr/DKh9ue82X+dVKENpDVDKSYgICYZE9shdujpwR/eLar/l/4bO+MIH4Z86rTudZ +5V9BpT+nFmgS8Gau0IdotQaXTD2XM7bUpasDKkxggI3MIICMwIBATA5MC0xEjAQBgNVBAMM CUNBIENPTExBQjEXMBUGA1UECgwOTElOQUdPUkEgR1JPVVACCDF2vXtciC9wMAkGBSsOAwIa BQCgggFUMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYw NzA5MzAwOVowIwYJKoZIhvcNAQkEMRYEFDoN//7KM6HDl24JDmPVLzrsag8TMEgGCSsGAQQB gjcQBDE7MDkwLTESMBAGA1UEAwwJQ0EgQ09MTEFCMRcwFQYDVQQKDA5MSU5BR09SQSBHUk9V UAIIMXa9e1yIL3AwSgYLKoZIhvcNAQkQAgsxO6A5MC0xEjAQBgNVBAMMCUNBIENPTExBQjEX MBUGA1UECgwOTElOQUdPUkEgR1JPVVACCDF2vXtciC9wMF8GCSqGSIb3DQEJDzFSMFAwCwYJ YIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgJu1TiSW3hs8tzo0uVAr ujzdjA0hMk95MPG8uUPh5L3BytrZhdjRfTLa7IZQY5TqKUwYOohP1H58n612uWRVxURGee8z fzi66ROxFZiFlQbm0CTDrwad8keY31E5KYUr/Fi7W8KhW8QZ1yInNreuKMiFhiqh37JYFBf7 eokt5qeIAAAAAAAA --------------ms090403020509010501000902-- From pgut001@login01.cs.auckland.ac.nz Tue Jun 7 23:56:34 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1328611E807E; Tue, 7 Jun 2011 23:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FcCxblZTNEM; Tue, 7 Jun 2011 23:56:33 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id EE9B511E8071; Tue, 7 Jun 2011 23:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1307516193; x=1339052193; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mike-list@pobox.com,=20ynir@checkpoint.com |Subject:=20Re:=20[TLS]=20[pkix]=20Proposing=20CAA=20as =20PKIX=20Working=20Group=20Item|Cc:=20paul.hoffman@vpnc. org,=20pkix@ietf.org,=20tls@ietf.org|In-Reply-To:=20<7A11 CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> |Message-Id:=20|Date:=20Wed,=2008=20Jun=202011=2018:56:23=20+1200; bh=O2tUc5o3a1E/NNKVf+HeDFmU3abPphITTo9tj1TPDj8=; b=lL8OFgSwQioBqRlDcMGvE+r8FVz0DKpkNT6JRHoDlgnRmfbdNzGk9NnX FlfF4cUmOw8h+q9PYt5nMA0qvlUEQgc/eyAzM5vo4v2kCxNaN/y2uoZOI Xw5BCj+mjHJ33smCQqgRYSG2NIPXutnxxGUE27eziJ+zGGLGWzUwja1Wh M=; X-IronPort-AV: E=Sophos;i="4.65,337,1304251200"; d="scan'208";a="66155298" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Jun 2011 18:56:23 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QUCgh-0007ro-IA; Wed, 08 Jun 2011 18:56:23 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QUCgh-0005Mx-J4; Wed, 08 Jun 2011 18:56:23 +1200 From: Peter Gutmann To: mike-list@pobox.com, ynir@checkpoint.com In-Reply-To: <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> Message-Id: Date: Wed, 08 Jun 2011 18:56:23 +1200 Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 06:56:34 -0000 Yoav Nir writes: >CAA works if all root CAs and affiliates follow it. That's hundreds or >thousands of entities. Any one of them that fails to comply might ignore the >CAA record. That was my problem with it, any CA (and/or RA) that's already diligent about cert issuance doesn't need CAA, and any one that isn't won't use it anyway, so it doesn't address any existing problem. Peter. From ynir@checkpoint.com Wed Jun 8 00:31:03 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E680121F8476; Wed, 8 Jun 2011 00:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.496 X-Spam-Level: X-Spam-Status: No, score=-8.496 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, DEAR_SOMETHING=1.605, RCVD_IN_DNSWL_HI=-8] 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 sm47PD2AzLe2; Wed, 8 Jun 2011 00:31:03 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E7C8121F8475; Wed, 8 Jun 2011 00:31:01 -0700 (PDT) X-CheckPoint: {4DEF3337-3-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p587Tbhb017894; Wed, 8 Jun 2011 10:29:37 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 8 Jun 2011 10:29:36 +0300 From: Yoav Nir To: koichi sugimoto Date: Wed, 8 Jun 2011 10:29:35 +0300 Thread-Topic: [pkix] [TLS] Proposing CAA as PKIX Working Group Item Thread-Index: AcwlrdFQ52d6dZUqTy+rISP51yR8yw== Message-ID: References: <81856AC0-F6FB-4321-93FE-559D5C5E2743@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" , "tls@ietf.org" Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 07:31:04 -0000 On Jun 7, 2011, at 4:31 AM, koichi sugimoto wrote: > Dear Sirs, >=20 > I've heard the fact was as follows: >=20 > ------------------------------------------------------------------------- > Paul Tourret and Steve Waite were independent agents assigned the > responsibility of sales and marketing for the RapidSSL brand, acting unde= r > a company called Certification Services Ltd (CSL). Verisign served > termination notice to CSL immediately after the announcement of the > GeoTrust acquisition. CSL then later changed its name to GlobalSign > Limited following successful acquisition of GlobalSign NV. RapidSSL.com > was, and always had been, an SSL brand owned in full by GeoTrust Inc. > GeoTrust elected to represent the brand as a business unit and as > mentioned above, Paul Tourret and Steve Waite were assigned as "agents" t= o > promote the brand. All root Certificates and infrastructure was > maintained and operated alongside the GeoTrust branded roots and in > infrastructure operated by GeoTrust Inc. In 2006 VeriSign acquired > GeoTrust and all its assets, including the RapidSSL brand and root > Certificates. Paul and Steve ceased their relationship with GeoTrust (no= w > owned by VeriSign) in late 2006. At the time of the rogue issuance of > RapidSSL root Certificates, ownership and infrastructure of maintenance > had been under VeriSign's control for over 2 years. To be clear, VeriSig= n > did not switch away from MD5 on behalf of RapidSSL, RapidSSL is just a > product brand (not a company) owned in full by VeriSign. > -------------------------------------------------------------------------= ----------------- Thanks for this. The point remains, that the customers see only the RapidSSL brand, no sign = of Verisign on the homepage. And obviously they were running with a very di= fferent web application than other Verisign affiliates. Even as just a prod= uct brand, some people were assigned to handle the website and the CA, and = despite being owned by Verisign, those people apparently weren't doing a ve= ry good job. Yoav From ynir@checkpoint.com Wed Jun 8 00:32:57 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E95A21F8476; Wed, 8 Jun 2011 00:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.548 X-Spam-Level: X-Spam-Status: No, score=-9.548 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 8+KPvno+EZ6e; Wed, 8 Jun 2011 00:32:57 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE7621F8475; Wed, 8 Jun 2011 00:32:55 -0700 (PDT) X-CheckPoint: {4DEF33AA-2-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p587Woog018324; Wed, 8 Jun 2011 10:32:50 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 8 Jun 2011 10:32:49 +0300 From: Yoav Nir To: Peter Gutmann Date: Wed, 8 Jun 2011 10:32:48 +0300 Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item Thread-Index: AcwlrkRXTAB8wUHGRnqB4ujQJkVunw== Message-ID: <6201F47E-26F1-43F0-839B-78D1360D2EC4@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" , "tls@ietf.org" Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 07:32:57 -0000 On Jun 8, 2011, at 9:56 AM, Peter Gutmann wrote: > Yoav Nir writes: >=20 >> CAA works if all root CAs and affiliates follow it. That's hundreds or >> thousands of entities. Any one of them that fails to comply might ignore= the >> CAA record. >=20 > That was my problem with it, any CA (and/or RA) that's already diligent a= bout=20 > cert issuance doesn't need CAA, and any one that isn't won't use it anywa= y, so=20 > it doesn't address any existing problem. >=20 > Peter. It would have prevented what has become known as "Comodo-gate". The attacke= r subverted an RA. If the CA was doing the CAA checking, the attacker would= be foiled. If checking the CAA is delegated to the RA, it would not help, = but the draft specifically talks about certification authorities. From pgut001@login01.cs.auckland.ac.nz Wed Jun 8 00:46:20 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995B021F8503; Wed, 8 Jun 2011 00:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-RH7m4BWMvn; Wed, 8 Jun 2011 00:46:20 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id B9E9821F8502; Wed, 8 Jun 2011 00:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1307519180; x=1339055180; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pgut001@cs.auckland.ac.nz,=20ynir@checkpoint.com |Subject:=20Re:=20[TLS]=20[pkix]=20Proposing=20CAA=20as =20PKIX=20Working=20Group=20Item|Cc:=20mike-list@pobox.co m,=20paul.hoffman@vpnc.org,=20pkix@ietf.org,=0D=0A=20=20 =20=20tls@ietf.org|In-Reply-To:=20<6201F47E-26F1-43F0-839 B-78D1360D2EC4@checkpoint.com>|Message-Id:=20|Date:=20Wed,=2008=20Ju n=202011=2019:46:09=20+1200; bh=3TezGZHmIxV4TACv5M8PRhmDR8zo2Kp+hvi+/V+1rnY=; b=AkU5y/Xkrdiw61INRqhM2ohnIk7Y7e/PVJlSZxtnq15IOZvP2YjdS9k8 +7nDi/Gs9iC6LZy9oZOOu8T3XQ8v2X/PQv/KpAshMwOjvRdluf24N+OSj e4VgOzidfyM8eqst8lmh20W7NiUoZsvgWRJnSzZ+k/FmKfVwnHTcz7c9N w=; X-IronPort-AV: E=Sophos;i="4.65,337,1304251200"; d="scan'208";a="66158433" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Jun 2011 19:46:10 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QUDSr-0000yL-I7; Wed, 08 Jun 2011 19:46:09 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QUDSr-00081X-EE; Wed, 08 Jun 2011 19:46:09 +1200 From: Peter Gutmann To: pgut001@cs.auckland.ac.nz, ynir@checkpoint.com In-Reply-To: <6201F47E-26F1-43F0-839B-78D1360D2EC4@checkpoint.com> Message-Id: Date: Wed, 08 Jun 2011 19:46:09 +1200 Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 07:46:20 -0000 Yoav Nir writes: >It would have prevented what has become known as "Comodo-gate". The attacker >subverted an RA. If the CA was doing the CAA checking, the attacker would be >foiled. Uh, re-read my original text: > That was my problem with it, any CA (and/or RA) that's already diligent about > cert issuance doesn't need CAA, and any one that isn't won't use it anyway, so > it doesn't address any existing problem. What makes you class Comodo as a diligent CA? (Not wanting to re-open the Comodo bashing again, but I'd use "Comodogate" as a prime example of why CAA won't do much good). Peter. From ynir@checkpoint.com Wed Jun 8 01:38:10 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B012111E809C; Wed, 8 Jun 2011 01:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.898 X-Spam-Level: X-Spam-Status: No, score=-9.898 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 OS2GKX47gXtx; Wed, 8 Jun 2011 01:38:10 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED1411E8127; Wed, 8 Jun 2011 01:38:08 -0700 (PDT) X-CheckPoint: {4DEF42F3-3-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p588bkxo027984; Wed, 8 Jun 2011 11:37:51 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 8 Jun 2011 11:37:45 +0300 From: Yoav Nir To: Peter Gutmann Date: Wed, 8 Jun 2011 11:37:44 +0300 Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item Thread-Index: Acwlt1asQvXn+f4lQqiE84ZHpQRMsQ== Message-ID: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" , "tls@ietf.org" Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 08:38:10 -0000 On Jun 8, 2011, at 10:46 AM, Peter Gutmann wrote: > Yoav Nir writes: >=20 >> It would have prevented what has become known as "Comodo-gate". The atta= cker >> subverted an RA. If the CA was doing the CAA checking, the attacker woul= d be >> foiled. >=20 > Uh, re-read my original text: >=20 >> That was my problem with it, any CA (and/or RA) that's already diligent = about >> cert issuance doesn't need CAA, and any one that isn't won't use it anyw= ay, so >> it doesn't address any existing problem. >=20 > What makes you class Comodo as a diligent CA? What did Comodo fail to do? The RA is handing contact with the customer, so it's their job to make sure= that the customer is in fact the owner of the domain name in the certifica= te request. Without CAA, there's nothing left for Comodo to check. Yoav= From pgut001@login01.cs.auckland.ac.nz Wed Jun 8 01:53:30 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EED11E811B; Wed, 8 Jun 2011 01:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgekbfE5pile; Wed, 8 Jun 2011 01:53:29 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 69AA911E8113; Wed, 8 Jun 2011 01:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1307523210; x=1339059210; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pgut001@cs.auckland.ac.nz,=20ynir@checkpoint.com |Subject:=20Re:=20[TLS]=20[pkix]=20Proposing=20CAA=20as =20PKIX=20Working=20Group=20Item|Cc:=20mike-list@pobox.co m,=20paul.hoffman@vpnc.org,=20pkix@ietf.org,=0D=0A=20=20 =20=20tls@ietf.org|In-Reply-To:=20<6B039F9F-B66E-41A3-894 E-8F1996A87209@checkpoint.com>|Message-Id:=20|Date:=20Wed,=2008=20Ju n=202011=2020:53:26=20+1200; bh=mQGmPUxcT3d2Vq0alyPtFc2lc1e5t4tBu/CJAfiYHF0=; b=jw6oCd5FlKxtHbB/8ouMEGJMc80nFlJVwGaargey2VpDVDMe3vSGlj6X cTVhHQ9JvDNJa0bD1ji8CiecJJ8uMZbk3aTWjUPbZSNazpszv7qdZbSVN 4ASton2Gp40yXvI/WoKau3CiOGquNs9VHqc4UPR8ZfB8czJ8rErKIXuvu I=; X-IronPort-AV: E=Sophos;i="4.65,337,1304251200"; d="scan'208";a="66163827" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Jun 2011 20:53:26 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QUEVy-00035c-IB; Wed, 08 Jun 2011 20:53:26 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QUEVy-0002cB-JN; Wed, 08 Jun 2011 20:53:26 +1200 From: Peter Gutmann To: pgut001@cs.auckland.ac.nz, ynir@checkpoint.com In-Reply-To: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> Message-Id: Date: Wed, 08 Jun 2011 20:53:26 +1200 Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 08:53:30 -0000 Yoav Nir writes: >What did Comodo fail to do? Hmm, this could get back into the Comodo-bashing flamewar, so I'd prefer not to continue this one... see endless earlier threads on this. Peter. From hallam@gmail.com Wed Jun 8 05:56:13 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E2A21F8466; Wed, 8 Jun 2011 05:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 5XFGnt0X6ge1; Wed, 8 Jun 2011 05:56:12 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB57B21F8465; Wed, 8 Jun 2011 05:56:11 -0700 (PDT) Received: by gxk19 with SMTP id 19so242872gxk.31 for ; Wed, 08 Jun 2011 05:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4DKvSgqeqGU/20oCZl/vKyuSeqaNw/OyCxczAeSzsFI=; b=qRMpfes9zGNg28E/I1QH2y6T+uexpAy8V+veV9h80vm/4LaHyCqS1tAJ2E7VYIJx0S /ETNBV24J8ffW99fR/wuL45QKNkg3/3Hfjx5yn+33f8ksgX/cNSwx3NYl0OODln3Yqs9 AHeLQB0cRfkPzFAwEBf85qpiXKrFm+pFFgxmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=D2MElVWPNwOzZXkZLYxyHEV15vKJc5+xXt54KynWpTLuf8/SXetcUnObwFa8YarBxG DLJMzkCcSBrCSxs0nQSaC2UOJsBp+Wuh3CORtHoL115a702fE9NTExY2uuaE0J9t/iuX 3oN9K+K5q4CtOD4miAN+U+skN/h4IrMFGqgiE= MIME-Version: 1.0 Received: by 10.101.200.1 with SMTP id c1mr6093068anq.63.1307537771053; Wed, 08 Jun 2011 05:56:11 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Wed, 8 Jun 2011 05:56:10 -0700 (PDT) In-Reply-To: References: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> Date: Wed, 8 Jun 2011 08:56:10 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=0016e68deca85fc31c04a532dcf1 Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 12:56:13 -0000 --0016e68deca85fc31c04a532dcf1 Content-Type: text/plain; charset=ISO-8859-1 First off, I think that people need to stop using the -gate suffix. Just because a competitor decided that they would attempt to apply it does not mean it is justified. That is an old game and a rather silly one in our industry. The relevant cautionary text here being John 8:7. What differentiates companies in our industry is not whether they are breached, it is whether they give prompt, voluntary notice of breaches that occur or not. The market leaders in the CA industry have a track record of having done so. As for CAA being a response to the Iranian attack, Ben, Rob and I developed it a year earlier. The point of proposals like CAA is not whether they are 'necessary' or not, it is whether they mitigate risk. I have never seen a security control involving a human element that is guaranteed to be operated with 100% accuracy every time. So whenever there are humans involved I like to have strength in depth. There would be no problem here if browsers actually implemented revocation checking either. But we have had that in PKIX specs for 15 years and it still isn't deployed in hard fail mode. Which is rather sad when you consider that about 70% of the complexity of PKI comes from the need for revocation. --0016e68deca85fc31c04a532dcf1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable First off, I think that people need to stop using the -gate suffix. Just be= cause a competitor decided that they would attempt to apply it does not mea= n it is justified. That is an old game and a rather silly one in our indust= ry. The relevant cautionary text here being John 8:7.

What differentiates companies in our industry is not wh= ether they are breached, it is whether they give prompt, voluntary notice o= f breaches that occur or not. The market leaders in the CA industry have a = track record of having done so.


As for CAA being a response to the Irani= an attack, Ben, Rob and I developed it a year earlier.

=
The point of proposals like CAA is not whether they are 'necessary= ' or not, it is whether they mitigate risk. I have never seen a securit= y control involving a human element that is guaranteed to be operated with = 100% accuracy every time. So whenever there are humans involved I like to h= ave strength in depth.=A0

There would be no problem here if browsers actually imp= lemented revocation checking either. But we have had that in PKIX specs for= 15 years and it still isn't deployed in hard fail mode. Which is rathe= r sad when you consider that about 70% of the complexity of PKI comes from = the need for revocation.
--0016e68deca85fc31c04a532dcf1-- From hallam@gmail.com Wed Jun 8 05:57:33 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A5721F852C; Wed, 8 Jun 2011 05:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Dybddd2mWtha; Wed, 8 Jun 2011 05:57:32 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B0F1221F8558; Wed, 8 Jun 2011 05:56:51 -0700 (PDT) Received: by gxk19 with SMTP id 19so243199gxk.31 for ; Wed, 08 Jun 2011 05:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0vNTszsGe9xsKRxpYvhryin3rETsB0+1GZaEtf32eyw=; b=c7flDXWbqoo0TMwBPOkHnMVVpaA9PSqAfFD2jEZkXZh1hVrxv7uJmAcRW3NK61Mr9L TQT118dMVuK4GmbK/yjhwPoNYKkn2YDztlC2s/lP72Z00i8U0XJUmQSGIP5HTNIkQGBX ZlGDvk4rZ/DIzkQnzuoBohuyvWIhEEb7CH1Qc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hHtbxP1bgl+tusyg1HM1C0XvL5AXnqnoMgTFpwoYjHauRwIjoH2ZiuBNQkg9uNVY3g LV71lk0lAi98WDqFueXyLrBle/aA8qsI5LHF/7ybHifChNPQ2NUwoDcN4U0dHPyQZHJD cQgGUccKnxGKK2ONtvNSWbwMlT/b4ATWI4nz8= MIME-Version: 1.0 Received: by 10.101.74.10 with SMTP id b10mr5965109anl.107.1307537811157; Wed, 08 Jun 2011 05:56:51 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Wed, 8 Jun 2011 05:56:51 -0700 (PDT) In-Reply-To: References: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> Date: Wed, 8 Jun 2011 08:56:51 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=0016368e1f85c3b3ab04a532de03 Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 12:57:33 -0000 --0016368e1f85c3b3ab04a532de03 Content-Type: text/plain; charset=ISO-8859-1 sorry, that should have been, the previous year. CAA was developed in the fall of 2010. On Wed, Jun 8, 2011 at 8:56 AM, Phillip Hallam-Baker wrote: > First off, I think that people need to stop using the -gate suffix. Just > because a competitor decided that they would attempt to apply it does not > mean it is justified. That is an old game and a rather silly one in our > industry. The relevant cautionary text here being John 8:7. > > What differentiates companies in our industry is not whether they are > breached, it is whether they give prompt, voluntary notice of breaches that > occur or not. The market leaders in the CA industry have a track record of > having done so. > > > As for CAA being a response to the Iranian attack, Ben, Rob and I developed > it a year earlier. > > The point of proposals like CAA is not whether they are 'necessary' or not, > it is whether they mitigate risk. I have never seen a security control > involving a human element that is guaranteed to be operated with 100% > accuracy every time. So whenever there are humans involved I like to have > strength in depth. > > There would be no problem here if browsers actually implemented revocation > checking either. But we have had that in PKIX specs for 15 years and it > still isn't deployed in hard fail mode. Which is rather sad when you > consider that about 70% of the complexity of PKI comes from the need for > revocation. > -- Website: http://hallambaker.com/ --0016368e1f85c3b3ab04a532de03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable sorry, that should have been, the previous year. CAA was developed in the f= all of 2010.

On Wed, Jun 8, 2011 at 8:56 = AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
First off, I think that people need to stop= using the -gate suffix. Just because a competitor decided that they would = attempt to apply it does not mean it is justified. That is an old game and = a rather silly one in our industry. The relevant cautionary text here being= John 8:7.

What differentiates companies in our industry is not wh= ether they are breached, it is whether they give prompt, voluntary notice o= f breaches that occur or not. The market leaders in the CA industry have a = track record of having done so.


As for CAA being a response to the Irani= an attack, Ben, Rob and I developed it a year earlier.

=
The point of proposals like CAA is not whether they are 'necessary= ' or not, it is whether they mitigate risk. I have never seen a securit= y control involving a human element that is guaranteed to be operated with = 100% accuracy every time. So whenever there are humans involved I like to h= ave strength in depth.=A0

There would be no problem here if browsers actually imp= lemented revocation checking either. But we have had that in PKIX specs for= 15 years and it still isn't deployed in hard fail mode. Which is rathe= r sad when you consider that about 70% of the complexity of PKI comes from = the need for revocation.



--
Website: http://hallambaker.com/

--0016368e1f85c3b3ab04a532de03-- From denis.pinkas@bull.net Wed Jun 8 06:06:57 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C457511E80CE; Wed, 8 Jun 2011 06:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.342 X-Spam-Level: ** X-Spam-Status: No, score=2.342 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_BAD_ID=2.837] 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 qrfisbi+LBct; Wed, 8 Jun 2011 06:06:56 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 32C8111E80D8; Wed, 8 Jun 2011 06:06:55 -0700 (PDT) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id F186A3181E4; Wed, 8 Jun 2011 15:16:10 +0200 (CEST) Received: from B016404 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2011060815065375:6799 ; Wed, 8 Jun 2011 15:06:53 +0200 From: "Denis Pinkas" To: "pkix-bounces", "pkix" Date: Wed, 8 Jun 2011 15:06:53 +0200 Message-Id: References: MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 08/06/2011 15:06:53, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 08/06/2011 15:06:54, Serialize complete at 08/06/2011 15:06:54 Content-Type: multipart/alternative; boundary="----=_NextPart_11060815065276066417436_002" Subject: Re: [pkix] Trusted responders in OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: denis.pinkas@bull.net List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 13:06:57 -0000 ------=_NextPart_11060815065276066417436_002 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ISO-8859-1" DQpXZSBhcmUgbm90IHByb2dyZXNzaW5nIG9uIFJGQzI1NjBiaXMuDQoNCkkgd291bGQgYWxzbyB2 b3RlIGFnYWluc3QgdGhlIGN1cnJlbnQgZHJhZnQgd2hpaGMgaGFzIG1ham9yIHByb2JsZW1zLg0K DQpJIHNlbnQgYW4gZW1haWwgbGFzdCB5ZWFyICgyMDEwKSwgd2hpY2ggcHJvcG9zZXMgdGV4dCBy ZXBsYWNlbWVudHMuIEkgY29weSBpdCBhZ2FpbiBiZWxvdyBzaW5jZSB0aGV5IGFyZSBzdGlsbCBh cHBsaWNhYmxlOg0KDQoxMiBjb21tZW50cyBvbiBkcmFmdC1jb29wZXItcGtpeC1yZmMyNTYwYmlz LTAwDQoNCkZpc3Qgb2YgYWxsLCBJIGFwcHJlY2lhdGUgdGhhdCB3ZSBhcmUgaW4gdGhlIHByb2Nl c3Mgb2YgcmVwbGFjaW5nIFJGQyAyNTYwIGluc3RlYWQgb2YgdXBkYXRpbmcgaXQuIA0KSSBhbHNv IGFja25vd2xlZGdlIHRoZSBuaWNlIHdvcmsgYmVpbmcgZG9uZSBieSBEYXZpZC4gTm93LCBsZXQg dXMgY29tZSB0byB0aGUgY29tbWVudHMuDQpDb21tZW50cyAxLCAyLCAzLCA4IGFuZCA5IGFyZSBt YWpvci4NCkNvbW1lbnRzIDQsIDUgYW5kIDYgYXJlIGVkaXRvcmlhbC4NCg0KMSkgVGhlIHRleHQg c3RhdGVzIG9uIHBhZ2UgNToNCkF1dGhvcml6ZWQgT0NTUCByZXNwb25kZXJzIGZhbGwgaW50byBv bmUgb2YgdGhyZWUgY2F0ZWdvcmllczogDQppbnRlZ3JhdGVkLCBkZXNpZ25hdGVkLCBvciBsb2Nh bGx5IHRydXN0ZWQuDQpXaGlsZSBPQ1NQIHJlc3BvbmRlcnMgYmVoYXZlIHJvdWdobHkgdGhlIHNh bWUsIE9DU1AgY2xpZW50cyBzaGFsbCB1c2UgYSBkaWZmZXJlbnQgY29kZSB3aGV0aGVyIHRoZXJl IGFyZSB0YWlsb3JlZCB0byB2ZXJpZnkgdGhlIHJlc3BvbnNlcyBmcm9tIGludGVncmF0ZWQgT0NT UCByZXNwb25kZXJzLCBkZXNpZ25hdGVkIE9DU1AgcmVzcG9uZGVycywgb3IgbG9jYWxseSB0cnVz dGVkIE9DU1AgcmVzcG9uZGVycy4NClRoaXMgbWVhbnMgdGhhdCB0aGUgZG9jdW1lbnQgc2hvdWxk IGluY2x1ZGUgdGhyZWUgZGlmZmVyZW50IHNlY3Rpb25zIHRvIGRlc2NyaWJlIGludGVyb3BlcmFi aWxpdHkgcmVxdWlyZW1lbnRzIG5hbWVseSBmb3IgdGhyZWUgdHlwZXMgb2YgT0NTUCBjbGllbnRz Og0KYSkgT0NTUCBjbGllbnRzIGFibGUgdG8gaW50ZXJvcGVyYXRlIHdpdGggaW50ZWdyYXRlZCBP Q1NQIHJlc3BvbmRlcnMsDQpiKSBPQ1NQIGNsaWVudHMgYWJsZSB0byBpbnRlcm9wZXJhdGUgd2l0 aCBkZXNpZ25hdGVkIE9DU1AgcmVzcG9uZGVycywNCmMpIE9DU1AgY2xpZW50cyBhYmxlIHRvIGlu dGVyb3BlcmF0ZSB3aXRoIGxvY2FsbHkgdHJ1c3RlZCBPQ1NQIHJlc3BvbmRlcnMuDQpUaGUgZ29h bCBpcyBiZWluZyBhYmxlIHRvIHNheSwgZS5nOiCTbXkgT0NTUCBjbGllbnQgY29kZSBpcyBjb21w bGlhbnQgd2l0aCBPQ1NQIGNsaWVudCB0eXBlIDKULg0KU2VjdGlvbiAyLjMuNi4yIHNob3VsZCBi ZSByZXZpc2l0ZWQgYW5kIHNwbGl0IHRvIHRha2UgdGhpcyBjb21tZW50IGludG8gY29uc2lkZXJh dGlvbi4NCg0KMikgVGhlIHRleHQgc3RhdGVzIG9uIHBhZ2UgNToNCjEuMi4xLiAgSW50ZWdyYXRl ZCBPQ1NQIFJlc3BvbmRlcnMNCiAgIEEgcmVzcG9uZGVyIGlzIGFuIGludGVncmF0ZWQgT0NTUCBy ZXNwb25kZXIgaWYgdGhlIHN1YmplY3QNCiAgIGRpc3Rpbmd1aXNoZWQgbmFtZSAoRE4pIGluIHRo ZSBjZXJ0aWZpY2F0ZSBjb250YWluaW5nIHRoZSBwdWJsaWMga2V5DQogICByZXF1aXJlZCB0byB2 ZXJpZnkgdGhlIHNpZ25hdHVyZSBvbiB0aGUgT0NTUCByZXNwb25zZSBpcyB0aGUgc2FtZSBhcw0K ICAgdGhlIGlzc3VlciBETiBpbiB0aGUgdGFyZ2V0IGNlcnRpZmljYXRlKHMpLiAgSW4gb3RoZXIg d29yZHMsIGFuDQogICBpbnRlZ3JhdGVkIE9DU1AgcmVzcG9uZGVyIGlzIGEgcmVzcG9uZGVyIHRo YXQgcHJvdmlkZXMgcmV2b2NhdGlvbg0KICAgc3RhdHVzIGluZm9ybWF0aW9uIGZvciBpdHMgb3du IGNlcnRpZmljYXRlcy4gIEFuIGludGVncmF0ZWQgT0NTUA0KICAgcmVzcG9uZGVyIG1heSBzaWdu IGNlcnRpZmljYXRlcyBhbmQgT0NTUCByZXNwb25zZXMgdXNpbmcgdGhlIHNhbWUNCiAgIHByaXZh dGUga2V5IG9yIG1heSB1c2UgZGlmZmVyZW50IGtleXMgdG8gc2lnbiBjZXJ0aWZpY2F0ZXMgYW5k IE9DU1ANCiAgIHJlc3BvbnNlcy4NClRoZSB3b3JkaW5nIJNpbnRlZ3JhdGVkIE9DU1AgcmVzcG9u ZGVylCBkaWQgbm90IGV4aXN0ZWQgaW4gUkZDIDI1NjAuDQpSRkMgMjU2MCB3YXMgc2F5aW5nOg0K VGhlIGtleSB1c2VkIHRvIHNpZ24gdGhlIHJlc3BvbnNlIE1VU1QgYmVsb25nIHRvIG9uZSBvZiB0 aGUgZm9sbG93aW5nOg0KICAgLS0gdGhlIENBIHdobyBpc3N1ZWQgdGhlIGNlcnRpZmljYXRlIGlu IHF1ZXN0aW9uDQpCdXQgUkZDIDI1NjAgd2FzIGFsc28gc2F5aW5nOg0KICAgVGhlIGtleSB0aGF0 IHNpZ25zIGEgY2VydGlmaWNhdGUncyBzdGF0dXMgaW5mb3JtYXRpb24gbmVlZCBub3QgYmUgdGhl DQogICBzYW1lIGtleSB0aGF0IHNpZ25lZCB0aGUgY2VydGlmaWNhdGUuIEEgY2VydGlmaWNhdGUn cyBpc3N1ZXINCiAgIGV4cGxpY2l0bHkgZGVsZWdhdGVzIE9DU1Agc2lnbmluZyBhdXRob3JpdHkg YnkgaXNzdWluZyBhIGNlcnRpZmljYXRlDQogICBjb250YWluaW5nIGEgdW5pcXVlIHZhbHVlIGZv ciBleHRlbmRlZEtleVVzYWdlIGluIHRoZSBPQ1NQIHNpZ25lcidzDQogICBjZXJ0aWZpY2F0ZS4N CldoZW4gcmVhZGluZyB0aGUgdHdvIHNlY3Rpb25zIHRvZ2V0aGVyLCBpdCBtYXkgYmUgaW50ZXJw cmV0ZWQgdGhlIGZvbGxvd2luZyB3YXk6IHRoZSBrZXkgdG8gc2lnbiB0aGUgT0NTUCByZXNwb25z ZSBhbmQgdGhlIGtleSB0byBzaWduIHRoZSBjZXJ0aWZpY2F0ZSBpcyB0aGUgc2FtZSB3aGVuIHRo ZXJlIGlzIG5vIGRlbGVnYXRpb24uDQpXZSBhcmUgbm93IG9wZW5pbmcgYSBjYW4gb2Ygd29ybXMg aWYgd2UgYWxsb3cgdGhlIENBIHRvIHNpZ24gT0NTUCByZXNwb25zZXMgd2l0aCBhIGtleSBkaWZm ZXJlbnQgZnJvbSB0aGUga2V5IHdoaWNoIGluaXRpYWxseSBzaWduZWQgdGhlIGNlcnRpZmljYXRl LCBpbiBwYXJ0aWN1bGFyIHdoZW4gdGhlIENBIGNoYW5nZXMgaXRzIGlzc3Vpbmcga2V5Lg0KV2Ug bXVzdCBndWFyYW50ZWUgYmFja3dhcmQgY29tcGF0aWJpbGl0eS4gVGhpcyBtZWFucyB0aGF0IHRo ZSBDQSBNVVNUIGNvbnRpbnVlIHRvIHNpZ24gT0NTUCByZXNwb25zZXMgd2l0aCB0aGUgc2FtZSBr ZXkuIA0KQWZ0ZXIgYSBDQSBrZXkgcm9sbG92ZXIsIHRoZSBrZXkgcXVlc3Rpb24gaXMgd2hldGhl ciBPQ1NQIHJlc3BvbnNlcyBmb3Igk29sZCBjZXJ0aWZpY2F0ZXOUIGNhbiBBTFNPIGJlIHNpZ25l ZCB3aXRoIGEgbmV3IGtleS4gSWYgdGhlcmUgaXMgb25seSBvbmUgYWNjZXNzTG9jYXRpb24gaW4g dGhlIEFJQSBleHRlbnNpb24gZmllbGQsIHRoaXMgaXMgbm90IHBvc3NpYmxlIGZvciB0aGUgaW50 ZWdyYXRlZCBjYXNlLiBGb3IgYWxsb3dpbmcgdGhpcyBzY2hlbWUsIHRoaXMgd291bGQgbWVhbiB0 aGF0IHR3byBhY2Nlc3NMb2NhdGlvbiBmaWVsZHMgc2hvdWxkIGJlIHBsYWNlZCBpbiB0aGUgQUlB IGV4dGVuc2lvbi4gT25lIHdvdWxkIGJlIHBsYWNlZCBpbiBhZHZhbmNlIG9mIHRoZSBrZXkgcm9s bG92ZXIuDQpIb3dldmVyLCB0aGUgZHJhd2JhY2sgaXMgdGhhdCB3ZSB3b3VsZCBuZWVkIHRvIGRp c3Rpbmd1aXNoIGJldHdlZW4gbW9yZSB0eXBlcyBvZiBPQ1NQIGNsaWVudHMuIA0KT0NTUCBjbGll bnRzIGFibGUgdG8gdGFrZSBpbnRvIGNvbnNpZGVyYXRpb24gdGhlIHNlY29uZCBhY2Nlc3NMb2Nh dGlvbiBmaWxlZCBpbiB0aGUgQUlBIGV4dGVuc2lvbiBBTkQgYWJsZSB0byBwcm9jZXNzIHRoZSBv bGQtYnktbmV3IENBIHNlbGYgc2lnbmVkIGNlcnRpZmljYXRlLg0KVGhpcyB3b3VsZCBtYWtlIGFu IGFkZGl0aW9uYWwgdHlwZSBvZiBPQ1NQIGNsaWVudC4NCkEgY29uc2VydmF0aXZlIHNvbHV0aW9u IHRvIHRoZSBwcm9ibGVtIHdvdWxkIGJlOg0KYSkgdG8gcmVwaHJhc2UgdGhlIG5ldyBkZWZpbml0 aW9uIHdpdGg6DQogICBBIHJlc3BvbmRlciBpcyBhbiBpbnRlZ3JhdGVkIE9DU1AgcmVzcG9uZGVy IGlmIHRoZSBzdWJqZWN0DQogICBkaXN0aW5ndWlzaGVkIG5hbWUgKEROKSBpbiB0aGUgY2VydGlm aWNhdGUgY29udGFpbmluZyB0aGUgcHVibGljIGtleQ0KICAgcmVxdWlyZWQgdG8gdmVyaWZ5IHRo ZSBzaWduYXR1cmUgb24gdGhlIE9DU1AgcmVzcG9uc2UgaXMgdGhlIHNhbWUgYXMNCiAgIHRoZSBp c3N1ZXIgRE4gaW4gdGhlIHRhcmdldCBjZXJ0aWZpY2F0ZShzKSBhbmQgaWYgdGhlIGtleSB1c2Vk IHRvIA0KICAgc2lnbiB0aGUgT0NTUCByZXNwb25zZSBpcyB0aGUgc2FtZSBhcyB0aGUga2V5IHVz ZWQgdG8gc2lnbiB0aGUgDQogICBjZXJ0aWZpY2F0ZS4NCmIpIHRvIGRlbGV0ZSB0aGUgZm9sbG93 aW5nIHNlbnRlbmNlOg0KICAgQW4gaW50ZWdyYXRlZCBPQ1NQIHJlc3BvbmRlciBtYXkgc2lnbiBj ZXJ0aWZpY2F0ZXMgYW5kIE9DU1AgDQogICByZXNwb25zZXMgdXNpbmcgdGhlIHNhbWUgcHJpdmF0 ZSBrZXkgb3IgbWF5IHVzZSBkaWZmZXJlbnQga2V5cyANCiAgIHRvIHNpZ24gY2VydGlmaWNhdGVz IGFuZCBPQ1NQIHJlc3BvbnNlcy4NCmMpIHRvIGNoYW5nZSB0aGUgdGV4dCBvbiBwYWdlIDE4LiBU aGUgY3VycmVudCB0ZXh0IGlzOg0KICAgICAgV2hlbiBhIENBIHNpZ25zIE9DU1AgcmVzcG9uc2Vz IHRvIHByb3ZpZGUgcmV2b2NhdGlvbg0KICAgICAgc3RhdHVzIGluZm9ybWF0aW9uIGZvciBpdHMg b3duIGNlcnRpZmljYXRlcywgaXQgbWF5IHNpZ24gdGhlDQogICAgICByZXNwb25zZXMgdXNpbmcg dGhlIHNhbWUga2V5IGFzIHdhcyB1c2VkIHRvIHNpZ24gdGhlIHRhcmdldA0KICAgICAgY2VydGlm aWNhdGUocykgb3IgdXNpbmcgYSBkaWZmZXJlbnQga2V5LiAgT25lIHJlYXNvbiB0aGF0IGEgQ0Eg bWF5DQogICAgICBzaWduIGFuIE9DU1AgcmVzcG9uc2UgdXNpbmcgYSBkaWZmZXJlbnQga2V5IHdv dWxkIGJlIGlmIHRoZSBDQSBoYWQNCiAgICAgIHBlcmZvcm1lZCBhIGtleSByb2xsb3ZlciBzaW5j ZSBpdCBpc3N1ZWQgdGhlIHRhcmdldA0KICAgICAgY2VydGlmaWNhdGUocykuDQogICAgICAgICBO b3RlOiBTb21lIE9DU1AgY2xpZW50cywgd2hlbiBhY2NlcHRpbmcgcmVzcG9uc2VzIGZyb20gYW4N CiAgICAgICAgIGludGVncmF0ZWQgT0NTUCByZXNwb25kZXIsIHdpbGwgb25seSBhY2NlcHQgT0NT UCByZXNwb25zZXMgdGhhdA0KICAgICAgICAgYXJlIHNpZ25lZCB1c2luZyB0aGUgc2FtZSBrZXkg YXMgdGhlIHRhcmdldCBjZXJ0aWZpY2F0ZShzKS4NCkl0IHdvdWxkIGJlIGNoYW5nZWQgaW50bzoN CiAgICAgIFdoZW4gYSBDQSBzaWducyBPQ1NQIHJlc3BvbnNlcyB0byBwcm92aWRlIHJldm9jYXRp b24NCiAgICAgIHN0YXR1cyBpbmZvcm1hdGlvbiBmb3IgaXRzIG93biBjZXJ0aWZpY2F0ZXMsIGl0 IE1VU1Qgc2lnbiB0aGUNCiAgICAgIHJlc3BvbnNlcyB1c2luZyB0aGUgc2FtZSBrZXkgYXMgd2Fz IHVzZWQgdG8gc2lnbiB0aGUgdGFyZ2V0DQogICAgICBjZXJ0aWZpY2F0ZShzKS4NCmQpIHRvIGNo YW5nZSB0ZXh0IGluIHNlY3Rpb24gMi4zLjYuMiBpdGVtIDIuDQpUaGlzIHdvdWxkIHNvbHZlIHRo ZSB3aG9sZSBwcm9ibGVtIGFuZCB0aGUgbm90ZSwgb3RoZXJ3aXNlIHdlIHdvdWxkIGhhdmUgdG8g Y29uc2lkZXIgYSBmb3VydGggY2FzZSBvZiBPQ1NQIGNsaWVudC4gSSBhbSBub3Qgb3Bwb3NlZCB0 byB0aGUgZm91cnRoIGNhc2UsIGFzIGxvbmcgYXMgaXQgaXMgY2xlYXJseSBpbmRpY2F0ZWQgYWxv bmcgd2l0aCB0aGUgcmVxdWlyZW1lbnRzIHBsYWNlZCBpbiB0aGUgQ0EuDQoNCjMpIE9uIHBhZ2Ug MTggZm9yIJNEZXNpZ25hdGVkIE9DU1AgcmVzcG9uZGVyc5QgdGhlIHRleHQgc3RhdGVzOg0KICAg ICAgVGhlIENBIGRvZXMgbm90IG5lZWQgdG8gc2lnbiB0aGlzIGNlcnRpZmljYXRlIHVzaW5nIHRo ZSBzYW1lIGtleQ0KICAgICAgYXMgd2FzIHVzZWQgdG8gc2lnbiB0aGUgdGFyZ2V0IGNlcnRpZmlj YXRlKHMpLCBidXQgdGhlIGNlcnRpZmljYXRlDQogICAgICBNVVNUIGJlIGlzc3VlZCB0byB0aGUg T0NTUCByZXNwb25kZXIgZGlyZWN0bHkgYnkgdGhlIENBIHRoYXQNCiAgICAgIGlzc3VlZCB0aGUg dGFyZ2V0IGNlcnRpZmljYXRlKHMpLg0KICAgICAgICAgTm90ZTogU29tZSBPQ1NQIGNsaWVudHMs IHdoZW4gYWNjZXB0aW5nIE9DU1AgcmVzcG9uc2VzIGZyb20gYQ0KICAgICAgICAgZGVzaWduYXRl ZCBPQ1NQIHJlc3BvbmRlciwgd2lsbCBvbmx5IGFjY2VwdCBPQ1NQIHJlc3BvbnNlcyBpZg0KICAg ICAgICAgdGhlIGNlcnRpZmljYXRlIHJlcXVpcmVkIHRvIHZhbGlkYXRlIHRoZSBzaWduYXR1cmUg b24gdGhlIE9DU1ANCiAgICAgICAgIHJlc3BvbnNlIHdhcyBzaWduZWQgdXNpbmcgdGhlIHNhbWUg a2V5IGFzIHRoZSB0YXJnZXQNCiAgICAgICAgIGNlcnRpZmljYXRlKHMpLg0KV2UgaGF2ZSBhIGJh Y2t3YXJkcyBjb21wYXRpYmlsaXR5IHByb2JsZW0gaGVyZS4gDQpUb2RheSBPQ1NQIGNsaWVudHMg ZG8gbm90IGV4cGVjdCBhIG5ldyBjZXJ0aWZpY2F0ZSBpc3N1ZWQgYnkgYSBuZXcga2V5IGZyb20g dGhlIHNhbWUgQ0EuIFdlIGFyZSBmYWNlZCB3aXRoIHR3byBjaG9pY2VzOiBtYW5kYXRlIHRoZSBz YW1lIGtleSBvciBtYW5kYXRlIHRoZSBpbmNsdXNpb24gaW4gdGhlIE9DU1AgcmVzcG9uc2Ugb2Yg dHdvIE9DU1AgY2VydGlmaWNhdGVzIGZvciB0aGUgc2FtZSByZXNwb25kZXIuIEkgd291bGQgcHJl ZmVyIHRoZSBsYXRlci4NCk5vdGUgdGhhdCBjaGFuZ2VzIGFyZSBhbHNvIG5lZWRlZCBpbiBzZWN0 aW9uIDIuMy42LjIgaXRlbSAzLg0KDQo0KSBUaGUgdGV4dCBzdGF0ZXMgaW4gc2VjdGlvbiAyLjMu NS4yIGZyb20gcGFnZSAxODoNCiAgIFNpbmNlIGFuIGF1dGhvcml6ZWQgT0NTUCByZXNwb25kZXIg cHJvdmlkZXMgcmV2b2NhdGlvbiBzdGF0dXMNCiAgIGluZm9ybWF0aW9uIGZvciBvbmUgb3IgbW9y ZSBDQXMsIE9DU1AgY2xpZW50cyBuZWVkIHRvIGtub3cgaG93IHRvDQogICBjaGVjayB0aGF0IGFu IGF1dGhvcml6ZWQgcmVzcG9uZGVyJ3MgY2VydGlmaWNhdGUgaGFzIG5vdCBiZWVuDQogICByZXZv a2VkLiANClRoZSBzZW50ZW5jZSBpcyBpbmNvcnJlY3Qgc2luY2UgaXQgaXMgbm90IHRydWUgZm9y IGludGVncmF0ZWQgcmVzcG9uZGVycy4NCkNoYW5nZSBpbnRvOg0KICAgT0NTUCBjbGllbnRzIG5l ZWQgdG8ga25vdyBob3cgdG8gY2hlY2sgdGhhdCBhbiBhdXRob3JpemVkIHJlc3BvbmRlcidzIA0K ICAgY2VydGlmaWNhdGUgaGFzIG5vdCBiZWVuIHJldm9rZWQuIA0KDQo1KSBUaGUgdGV4dCBzdGF0 ZXMgaW4gc2VjdGlvbiAyLjMuNi4yIGZyb20gcGFnZSAxODoNCiAgIFN5c3RlbXMgb3IgYXBwbGlj YXRpb25zIHRoYXQgcmVseSBvbiBPQ1NQIHJlc3BvbnNlcyBNVVNUIGJlIGNhcGFibGUNCiAgIG9m IGRldGVjdGluZyBhbmQgZW5mb3JjaW5nIHVzZSBvZiB0aGUgaWQtYWQtb2NzcFNpZ25pbmcgdmFs dWUgYXMNCiAgIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMy41LjEuICBUaGV5IE1BWSBwcm92aWRl IGEgbWVhbnMgb2YgbG9jYWxseQ0KICAgY29uZmlndXJpbmcgb25lIG9yIG1vcmUgT0NTUCBzaWdu aW5nIGF1dGhvcml0aWVzLCBhbmQgc3BlY2lmeWluZyB0aGUNCiAgIHNldCBvZiBDQXMgZm9yIHdo aWNoIGVhY2ggc2lnbmluZyBhdXRob3JpdHkgaXMgdHJ1c3RlZC4NClRoZSBmaXJzdCBzZW50ZW5j ZSBpcyB1bnRydWUgZm9yIGxvY2FsbHkgdHJ1c3RlZCBPQ1NQIHJlc3BvbmRlcnMgd2hpbGUgdGhl IHNlY29uZCBzZW50ZW5jZSBpcyBvbmx5IHRydWUgZm9yIGxvY2FsbHkgdHJ1c3RlZCBPQ1NQIHJl c3BvbmRlcnMuIEFzIHN0YXRlZCBpbiB0aGUgdmVyeSBmaXJzdCBjb21tZW50LCB0aGlzIHdob2xl IHNlY3Rpb24gbmVlZHMgdG8gYmUgcmVzdHJ1Y3R1cmVkIGFjY29yZGluZyB0byB0aGUgdGhyZWUg Y2FzZXMuDQoNCjYpIFRoZSB0ZXh0IHN0YXRlcyBpbiBzZWN0aW9uIDQuMSBmcm9tIHBhZ2UgMjMg aW4gdGhlIGRpc2N1c3Npb24gYWJvdXQgdGhlIHVzZSBvZiBpbnNlY3VyZSBhbGdvcml0aG1zIGlu c2lkZSB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uLg0KICAgSW4gYXJjaGl2YWwg YXBwbGljYXRpb25zIGl0IGlzIHF1aXRlIHBvc3NpYmxlIHRoYXQgYW4gT0NTUCByZXNwb25kZXIN CiAgIG1pZ2h0IGJlIGFza2VkIHRvIHJlcG9ydCB0aGUgdmFsaWRpdHkgb2YgYSBjZXJ0aWZpY2F0 ZSBvbiBhIGRhdGUgaW4NCiAgIHRoZSBkaXN0YW50IHBhc3QuDQpUaGlzIGZ1bmN0aW9uYWxpdHkg ZG9lcyBub3QgZXhpc3Q6IHRoZXJlIGlzIG5vIGRhdGUgaW4gdGhlIHJlcXVlc3QgdG8gYXNrIHRo ZSByZXZvY2F0aW9uIGF0IGEgdGltZSBpbiB0aGUgcGFzdC4gT0NTUCByZXNwb25kZXJzIGFyZSBu b3QgcmVxdWlyZWQgdG8gcmVwb3J0IHRoZSB2YWxpZGl0eSBvZiBhIGNlcnRpZmljYXRlIG9uIGEg ZGF0ZSBpbiB0aGUgZGlzdGFudCBwYXN0LiBQbGVhc2UgZGVsZXRlLg0KNykgQWxsIHRoZSBzZWN0 aW9ucyBmcm9tIHNlY3Rpb24gRCBuZWVkIHRvIGJlIHJldmlzaXRlZCB0byB0YWtlIGludG8gY29u c2lkZXJhdGlvbnMgdGhlIHByZXZpb3VzIGNvbW1lbnRzLg0KSW4gc2VjdGlvbiBELjEsIGZpZ3Vy ZXMgMiBhbmQgMyBzaG91bGQgYmUgZGVsZXRlZC4NCkluIHNlY3Rpb24gRC4yLCBmaWd1cmUgNSBz aG91bGQgYmUgZGVsZXRlZCBiZWNhdXNlIGl0IGlzIHVubGlrZWx5IHRoYXQgYSByb290IENBIHVz ZXMgdGhlIHNhbWUga2V5IHRvIHNpZ24gT0NTUCByZXNwb25zZXMuDQpJbiBmaWd1cmUgNiwgdGhp cyBtZWFucyB0aGF0IHRoZSBjbGllbnQgTVVTVCBiZSBjYXBhYmxlIHRvIHByb2Nlc3MgdGhlIG9s ZC1ieS1uZXcgc2VsZiBzaWduZWQgY2VydGlmaWNhdGUuIFdoaWxlIGl0IGlzIGEgbmljZSBmZWF0 dXJlLCBhbGwgY2xpZW50cyBhcmUgbm90IGFibGUgdG8gZG8gaXQsIHVubGVzcyB3ZSBkZWZpbmUg YSBuZXcgY2xhc3Mgb2YgY2xpZW50cyBhYmxlIHRvIHByb2Nlc3MgdGhhdCBjYXNlLiBUaGlzIGlz IHJlbGF0ZWQgdG8gdGhlIGZpcnN0IGFuZCBzZWNvbmQgY29tbWVudCBhYm91dCB0aGUgZGlzdGlu Y3Rpb24gb2YgZGlmZmVyZW50IGNsYXNzZXMgb2YgT0NTUCBjbGllbnRzICh0aHJlZSBvciBmb3Vy KS4NCkluIGZpZ3VyZSA3LCBpdCBpcyB1bmxpa2VseSB0aGF0IGEgcm9vdCBDQSB1c2VzIHRoZSBz YW1lIGtleSB0byBzaWduIE9DU09QIHJlc3BvbnNlcy4gVGhpcyBjYXNlIHNob3VsZCBiZSBkZWxl dGVkIG9yIG1vZGlmaWVkLg0KDQo4KSBPbiBwYWdlIDM5LCB0aGUgdGV4dCBjbGVhcmx5IGluZGlj YXRlcyB0aGUgcHJvYmxlbToNCiAgIEFzIG5vdGVkIGluIFNlY3Rpb24gMi4zLjUuMSwgc29tZSBP Q1NQIGNsaWVudHMgY2Fubm90IHZhbGlkYXRlDQogICBzaWduYXR1cmVzIG9uIE9DU1AgcmVzcG9u c2VzIGNyZWF0ZWQgYnkgZGVzaWduYXRlZCBPQ1NQIHJlc3BvbmRlcnMgaWYNCiAgIHRoZSBPQ1NQ IHJlc3BvbmRlcidzIGNlcnRpZmljYXRlIGhhcyBiZWVuIHNpZ25lZCB1c2luZyBhIGRpZmZlcmVu dA0KICAga2V5IHRoYW4gdGhlIHRhcmdldCBjZXJ0aWZpY2F0ZS4gIEZpZ3VyZSA4IGRlcGljdHMg YSBDQSB0aGF0DQogICBhY2NvbW1vZGF0ZXMgdGhpcyBsaW1pdGF0aW9uIGJ5IGlzc3VpbmcgdHdv IGNlcnRpZmljYXRlcyB0byB0aGUNCiAgIGRlc2lnbmF0ZWQgT0NTUCByZXNwb25kZXIsIG9uZSBz aWduZWQgd2l0aCBpdHMgb2xkIHByaXZhdGUga2V5IGFuZA0KICAgb25lIHNpZ25lZCB3aXRoIGl0 cyBuZXcgcHJpdmF0ZSBrZXkuICBCb3RoIGNlcnRpZmljYXRlcyBpbmNsdWRlIGFuDQogICBleHRl bmRlZCBrZXkgdXNhZ2UgZXh0ZW5zaW9uIHdpdGggdGhlIGlkLWtwLU9DU1BTaWduaW5nIE9JRC4N CkluIG9yZGVyIHRvIGFjaGlldmUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgaWYgdGhlIENBIGlz c3VlcyBhbiBvbGQtYnktbmV3IHNlbGYgc2lnbmVkIGNlcnRpZmljYXRlLCB0aGVuIHRoZSBDQSBT SEFMTCBpc3N1ZSB0d28gY2VydGlmaWNhdGVzLCB3aGljaCBhbHNvIG1lYW4gdGhhdCB0aGUgT0NT UCByZXNwb25kZXIgU0hBTEwgaW5jbHVkZSBpdHMgdHdvIGNlcnRpZmljYXRlcyBpbiB0aGUgY2Vy dHMgZmllbGQgZnJvbSBCYXNpY09DU1BSZXNwb25zZS4NClRoaXMgcmVxdWlyZW1lbnQgc2hvdWxk IGJlIG1vdmVkIGluIHRoZSBub3JtYXRpdmUgcGFydCBvZiB0aGUgUkZDLg0KDQo5KSBCVFcsIHRo ZSBmaWVsZCBjZXJ0cyBpcyBub3QgZGVzY3JpYmVkIGFuZCBzaG91bGQgYmUgZGVzY3JpYmVkLiBP dGhlciBmaWVsZHMgZnJvbSBCYXNpY09DU1BSZXNwb25zZSBhcmUgbm90IGRlc2NyaWJlZCBlaXRo ZXIgISA6LSgNCg0KMTApIEluIHRoZSBjYXNlIG9mIGZpZ3VyZSA5LCB0aGUgT0NTUCByZXNwb25k ZXIgU0hBTEwgaW5jbHVkZSBhbGwgdGhyZWUgY2VydGlmaWNhdGVzIGluIHRoZSBmaWVsZCBjZXJ0 cyBmcm9tIEJhc2ljT0NTUFJlc3BvbnNlLiBUaGlzIHJlcXVpcmVtZW50IHNob3VsZCBiZSBtb3Zl ZCBpbiB0aGUgbm9ybWF0aXZlIHBhcnQgb2YgdGhlIFJGQy4NCg0KMTEpIEluIGZpZ3VyZSAxMCwg dGhlIHRleHQgaXMgbWlzc2luZyB0byBzYXkgd2hhdCB0aGUgY2xpZW50IHNoYWxsIGJlIGRvaW5n Lg0KDQoxMikgSW4gdGhlIGZpcnN0IGNvbW1lbnQsIEkgc2FpZJQgV2hpbGUgT0NTUCByZXNwb25k ZXJzIGJlaGF2ZSAqcm91Z2hseSogdGhlIHNhbWWULiBUaGVyZSBpcyBhIGRpc3RpbmN0aW9uIHRv IGludHJvZHVjZTogdGhlIG51bWJlciBvZiBjZXJ0cyB0aGF0IHRoZSBPQ1NQIHJlc3BvbnNlIFNI QUxMIGluY2x1ZGUgaW4gdGhlIGNhc2Ugb2YgdGhlIGludGVncmF0ZWQgT0NTUCByZXNwb25kZXJz Lg0KDQo6DQoNCg0KDQoNCiANCiANCg0KLS0tLS0gTWVzc2FnZSByZed1IC0tLS0tIA0KRGUgOiBw a2l4LWJvdW5jZXMgDQrAIDogcGtpeEBpZXRmLm9yZyANCkRhdGUgOiAyMDExLTA2LTA2LCAxNjoy Mzo1Mw0KU3VqZXQgOiBSZTogW3BraXhdIFRydXN0ZWQgcmVzcG9uZGVycyBpbiBPQ1NQDQoNCg0K SSBmaW5hbGx5IGdvdCBhcm91bmQgdG8gcmVhZGluZyB0aGUgY3VycmVudCAyNTYwIGJpcyBkcmFm dC4NCg0KSSB3b3VsZCB2b3RlIGFnYWluc3QgaXQgc2luY2UgaXQgc2FjcmlmaWNlcyBzZWN1cml0 eSBleHBsaWNpdGx5IHN0YXRlZCBvciBpbXBsaWVkIGluIDI1NjAuIE15IGFyZ3VtZW50cyBhcmUg d2VsbCByZWNvcmRlZCBpbiBQS0lYIGZvcnVtLiBJIHdpbGwgbm90IHJlcGVhdCB0aG9zZS4gSW4g YWRkaXRpb24sIGFuIE9DU1AgY2xpZW50IG1heSBoYXZlIGludGVyb3BlcmFiaWxpdHkgcHJvYmxl bXMgd2l0aCBhIHNlcnZlciBjbGFpbWluZyBjb21wbGlhbmNlIHdpdGggdGhpcyBkcmFmdCBzdGFu ZGFyZC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHBraXgtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZWZh biBTYW50ZXNzb24NClNlbnQ6IE1vbmRheSwgTWF5IDMwLCAyMDExIDU6NDcgQU0NClRvOiBUb21h cyBHdXN0YXZzc29uOyBwa2l4QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3BraXhdIFRydXN0ZWQg cmVzcG9uZGVycyBpbiBPQ1NQDQoNClRoaXMgaXMgaG93IEkgd291bGQgbGlrZSB0byBjaGFuZ2Ug dGhpcyBzZWN0aW9uIGluIFJGQyAyNTYwYmlzDQoNCmh0dHA6Ly90aW55dXJsLmNvbS8yNTYwYmlz LXRyDQoNCg0KL1N0ZWZhbg0KDQpPbiAxMS0wNS0zMCAxMDoxMSBBTSwgIlRvbWFzIEd1c3RhdnNz b24iIDx0b21hc0BwcmltZWtleS5zZT4gd3JvdGU6DQoNCj4NCj5JIGFncmVlIHRoYXQsIGFsc28g YWNjb3JkaW5nIHRvIG15IGV4cGVyaWVuY2UsIHRoaXMgaXMgaG93IE9DU1ANCj52YWxpZGF0aW9u IHdvcmtzIGluIHByYWN0aWNlIHRvZGF5LiBXaWNoIGlzIHByb2JhYmx5IHdoeSBpdCBnZW5lcmFs bHkNCj53b3JrcyBxdWl0ZSB3ZWxsLg0KPg0KPkNoZWVycywNCj5Ub21hcw0KPg0KPk9uIDA1LzI4 LzIwMTEgMDk6MjQgUE0sIFN0ZWZhbiBTYW50ZXNzb24gd3JvdGU6DQo+PiBJJ20gd29ycmllZCBh Ym91dCB0aGUgbmV3IHdvcmRpbmcgaW4gcmZjMjU2MGJpcyByZWdhcmRpbmcgdHJ1c3RlZA0KPj4g cmVzcG9uZGVycy4NCj4+IA0KPj4gSSd2ZSBzcGVudCBzb21lIHRpbWUgbm93IGRvaW5nIGFjdHVh bCBpbXBsZW1lbnRhdGlvbiBvZiBPQ1NQIGNoZWNraW5nDQo+PiB1c2luZyBleGlzdGluZyBsaWJy YXJpZXMgYW5kIEkgZmVhciB0aGF0IGN1cnJlbnQgUkZDIDI1Nm9iaXMgd2lsbCBjYXVzZQ0KPj4g bW9yZSBjb25mdXNpb24gYW5kIGxlc3MgaW50ZXJvcGVyYWJpbGl0eSwgdGhhbiBpZiB3ZSBrZWVw IDI1NjAgYXMgaXQgaXMuDQo+PiANCj4+IFRoZSBjdXJyZW50IGJpcyB0ZXh0IG1pZ2h0IGJlIGFs bCAiWC41MDkiIHB1cmlzaCBidXQgaXQgaXMgbm90IHZlcnkNCj4+IGhlbHBmdWwgaW4gYXR0YWlu aW5nIGludGVyb3BlcmFiaWxpdHkuDQo+PiANCj4+IFJGQyAyNTYwIGRvZXMgbm90IGRlYWwgd2l0 aCBrZXkgcm9sbG92ZXIuIEl0IHNlYW1zIHRvIGFzc3VtZSB0aGF0IENBcyBkbw0KPj4gd2hhdCB0 aGV5IGluIHByYWN0aWNlIGFsd2F5cyBkbywgaS5lLiBUaGV5IGxldCB0aGUgbGlmZXRpbWUgb2Yg dGhlaXINCj4+IGlzc3Vpbmcga2V5IGV4Y2VlZCB0aGUgbGlmZXRpbWUgb2YgYW55IGNlcnRpZmlj YXRlIHRoZXkgaXNzdWUuDQo+PiBUaGUgc2VsZiBkZXNpZ25hdGlvbiBleHByZXNzIHRoYXQgdGhl IHJlc3BvbmRlciBjZXJ0aWZpY2F0ZSAiaXMgVEhFDQo+PiBjZXJ0aWZpY2F0ZSBvZiB0aGUgQ0Ei IHRoYXQgaXNzdWVkIHRoZSBjZXJ0IGJlaW5nIGNoZWNrZWQuIEkgaW50ZXJwcmV0DQo+PiB0aGlz IHRvIGJlIHRoZSBDQSBjZXJ0aWZpY2F0ZSBmb3VuZCBpbiB0aGUgY2VydCBwYXRoIG9mIHRoZSBj ZXJ0aWZpY2F0ZQ0KPj4gYmVpbmcgdmFsaWRhdGVkLg0KPj4gDQo+PiBNb3N0IGltcGxlbWVudGVy cyBzZWVtcyB0byBoYXZlIGFncmVlZCBhbmQgdW5kZXJzdG9vZCB0aGlzIHRvIGJlIGFuIGVhc3kN Cj4+IGNoZWNrLg0KPj4gDQo+PiBJZiAocmVzcG9uc2Ugc2lnbmF0dXJlIGNhbiBiZSB2ZXJpZmll ZCBieSBDQSBjZXJ0KSB7Y2hlY2sgT0t9IGVsc2Uge2NlY2sNCj4+IEZBSUx9DQo+PiANCj4+IFRo ZSBzYW1lIGdvZXMgZm9yIGRlc2lnbmF0ZWQgcmVzcG9uZGVyczoNCj4+IA0KPj4gSWYgKGRlc2ln bmF0ZWQgcmVzcG9uZGVyIGNlcnQgY2FuIGJlIHZlcmlmaWVkIGJ5IHRoZSBDQSBjZXJ0KSB7Y2hl Y2sgT0t9DQo+PiBlbHNlIHtjZWNrIEZBSUx9DQo+PiANCj4+IA0KPj4gU2luY2UgdGhpcyBpcyB0 aGUgY3VycmVudCBjb25maWd1cmF0aW9uIGFyb3VuZCB3aGljaCBpbnRlcm9wZXJhYmlsaXR5IGlz DQo+PiBhY2hpZXZlZCwgdGhpcyBpcyB0aGUgY29uZmlndXJhdGlvbiB0aGF0IHNob3VsZCBiZSBw cm9tb3RlZCBpbg0KPj4gcmZjMjU2MGJpcyBhcyBNVVNUIGltcGxlbWVudCBmb3IgT0NTUCBjbGll bnRzLg0KPj4gQW55dGhpbmcgZWxzZSBzaG91bGQgYmUgT1BUSU9OQUwuDQo+PiANCj4+IEJleW9u ZCB0aGlzIHRoZXJlIGFyZSBhIGthemlsbGlvbiBvZiBjb25maWd1cmF0aW9uIG9wdGlvbnMgZm9y IGFsbG93aW5nDQo+PiBrZXkgcm9sbG92ZXIsIGRlc2lnbmF0ZWQgcmVzcG9uZGVycyBhbmQgZXZl biAod2hpY2ggSSBoYXZlIHNlZW4gZXhhbXBsZXMNCj4+IG9mKSBkZXNpZ25hdGVkIENBcyBvbmx5 IGlzc3VpbmcgcmVzcG9uZGVyIGNlcnRzLiBUaGVzZSBhcmUgYWxsIGZpbmUgaW4NCj4+IGxvY2Fs IGNvbW11bml0aWVzIHVuZGVyIGxvY2FsIHBvbGljeSwgYnV0IG5vIG9uZSBzaG91bGQgZXhwZWN0 IGEgZ2VuZXJhbA0KPj4gT0NTUCBjbGllbnQgdG8gaGFuZGxlIHRoZW0uDQo+PiANCj4+IC9TdGVm YW4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IHBraXggbWFpbGluZyBsaXN0DQo+PiBwa2l4QGlldGYub3Jn DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXgNCj4NCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnBraXggbWFpbGlu ZyBsaXN0DQo+cGtpeEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcGtpeA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpwa2l4IG1haWxpbmcgbGlzdA0KcGtpeEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wa2l4DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KcGtpeCBtYWlsaW5nIGxpc3QNCnBraXhAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGtpeA0K ------=_NextPart_11060815065276066417436_002 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="ISO-8859-1" PEhUTUw+PEhFQUQ+PFRJVExFPjwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJLc0RIVE1MRURMaWIu b2N4LCBGcmVlV2FyZSBIVE1MIEVkaXRvciAxLjE2NC4yLCCpIEt1cnQgU2VuZmVyIiANCm5hbWU9 R0VORVJBVE9SPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiIGxlZnRNYXJnaW49NSB0b3BNYXJnaW49NSANCiNm ZmZmZmY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5XZSBhcmUgbm90IHByb2dyZXNzaW5nIG9u IFJGQzI1NjBiaXMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JIHdvdWxkIGFsc28g dm90ZSBhZ2FpbnN0IHRoZSBjdXJyZW50IGRyYWZ0IHdoaWhjIGhhcyBtYWpvciBwcm9ibGVtcy48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkgc2VudCBhbiBlbWFpbCZuYnNwO2xhc3Qg eWVhciAoMjAxMCksIHdoaWNoIHByb3Bvc2VzIHRleHQgcmVwbGFjZW1lbnRzLiBJIA0KY29weSBp dCBhZ2FpbiBiZWxvdyBzaW5jZSB0aGV5IGFyZSBzdGlsbCBhcHBsaWNhYmxlOjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+MTIgY29tbWVudHMgb24gZHJhZnQtY29vcGVyLXBraXgtcmZj MjU2MGJpcy0wMDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+RmlzdCBvZiBhbGwsIEkg YXBwcmVjaWF0ZSB0aGF0IHdlIGFyZSBpbiB0aGUgcHJvY2VzcyBvZiByZXBsYWNpbmcgUkZDIDI1 NjAgDQppbnN0ZWFkIG9mIHVwZGF0aW5nIGl0LiA8L0RJVj4NCjxESVY+SSBhbHNvIGFja25vd2xl ZGdlIHRoZSBuaWNlIHdvcmsgYmVpbmcgZG9uZSBieSBEYXZpZC4gTm93LCBsZXQgdXMgY29tZSB0 byANCnRoZSBjb21tZW50cy48L0RJVj4NCjxESVY+Q29tbWVudHMgMSwgMiwgMywgOCBhbmQgOSBh cmUgbWFqb3IuPEJSPkNvbW1lbnRzIDQsIDUgYW5kIDYgYXJlIA0KZWRpdG9yaWFsLjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+MSkgVGhlIHRleHQgc3RhdGVzIG9uIHBhZ2UgNTo8L0RJ Vj4NCjxESVY+QXV0aG9yaXplZCBPQ1NQIHJlc3BvbmRlcnMgZmFsbCBpbnRvIG9uZSBvZiB0aHJl ZSBjYXRlZ29yaWVzOiANCjxCUj5pbnRlZ3JhdGVkLCBkZXNpZ25hdGVkLCBvciBsb2NhbGx5IHRy dXN0ZWQuPC9ESVY+DQo8RElWPldoaWxlIE9DU1AgcmVzcG9uZGVycyBiZWhhdmUgcm91Z2hseSB0 aGUgc2FtZSwgT0NTUCBjbGllbnRzIHNoYWxsIHVzZSBhIA0KZGlmZmVyZW50IGNvZGUgd2hldGhl ciB0aGVyZSBhcmUgdGFpbG9yZWQgdG8gdmVyaWZ5IHRoZSByZXNwb25zZXMgZnJvbSANCmludGVn cmF0ZWQgT0NTUCByZXNwb25kZXJzLCBkZXNpZ25hdGVkIE9DU1AgcmVzcG9uZGVycywgb3IgbG9j YWxseSB0cnVzdGVkIE9DU1AgDQpyZXNwb25kZXJzLjwvRElWPg0KPERJVj5UaGlzIG1lYW5zIHRo YXQgdGhlIGRvY3VtZW50IHNob3VsZCBpbmNsdWRlIHRocmVlIGRpZmZlcmVudCBzZWN0aW9ucyB0 byANCmRlc2NyaWJlIGludGVyb3BlcmFiaWxpdHkgcmVxdWlyZW1lbnRzIG5hbWVseSBmb3IgdGhy ZWUgdHlwZXMgb2YgT0NTUCANCmNsaWVudHM6PC9ESVY+DQo8RElWPmEpIE9DU1AgY2xpZW50cyBh YmxlIHRvIGludGVyb3BlcmF0ZSB3aXRoIGludGVncmF0ZWQgT0NTUCByZXNwb25kZXJzLDxCUj5i KSANCk9DU1AgY2xpZW50cyBhYmxlIHRvIGludGVyb3BlcmF0ZSB3aXRoIGRlc2lnbmF0ZWQgT0NT UCByZXNwb25kZXJzLDxCUj5jKSBPQ1NQIA0KY2xpZW50cyBhYmxlIHRvIGludGVyb3BlcmF0ZSB3 aXRoIGxvY2FsbHkgdHJ1c3RlZCBPQ1NQIHJlc3BvbmRlcnMuPC9ESVY+DQo8RElWPlRoZSBnb2Fs IGlzIGJlaW5nIGFibGUgdG8gc2F5LCBlLmc6IJNteSBPQ1NQIGNsaWVudCBjb2RlIGlzIGNvbXBs aWFudCB3aXRoIA0KT0NTUCBjbGllbnQgdHlwZSAylC48L0RJVj4NCjxESVY+U2VjdGlvbiAyLjMu Ni4yIHNob3VsZCBiZSByZXZpc2l0ZWQgYW5kIHNwbGl0IHRvIHRha2UgdGhpcyBjb21tZW50IGlu dG8gDQpjb25zaWRlcmF0aW9uLjwvRElWPg0KPERJVj48QlI+MikgVGhlIHRleHQgc3RhdGVzIG9u IHBhZ2UgNTo8L0RJVj4NCjxESVY+MS4yLjEuJm5ic3A7IEludGVncmF0ZWQgT0NTUCBSZXNwb25k ZXJzPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyBBIHJlc3BvbmRlciBpcyBhbiBpbnRlZ3JhdGVk IE9DU1AgcmVzcG9uZGVyIGlmIHRoZSANCnN1YmplY3Q8QlI+Jm5ic3A7Jm5ic3A7IGRpc3Rpbmd1 aXNoZWQgbmFtZSAoRE4pIGluIHRoZSBjZXJ0aWZpY2F0ZSBjb250YWluaW5nIA0KdGhlIHB1Ymxp YyBrZXk8QlI+Jm5ic3A7Jm5ic3A7IHJlcXVpcmVkIHRvIHZlcmlmeSB0aGUgc2lnbmF0dXJlIG9u IHRoZSBPQ1NQIA0KcmVzcG9uc2UgaXMgdGhlIHNhbWUgYXM8QlI+Jm5ic3A7Jm5ic3A7IHRoZSBp c3N1ZXIgRE4gaW4gdGhlIHRhcmdldCANCmNlcnRpZmljYXRlKHMpLiZuYnNwOyBJbiBvdGhlciB3 b3JkcywgYW48QlI+Jm5ic3A7Jm5ic3A7IGludGVncmF0ZWQgT0NTUCANCnJlc3BvbmRlciBpcyBh IHJlc3BvbmRlciB0aGF0IHByb3ZpZGVzIHJldm9jYXRpb248QlI+Jm5ic3A7Jm5ic3A7IHN0YXR1 cyANCmluZm9ybWF0aW9uIGZvciBpdHMgb3duIGNlcnRpZmljYXRlcy4mbmJzcDsgQW4gaW50ZWdy YXRlZCBPQ1NQPEJSPiZuYnNwOyZuYnNwOyANCnJlc3BvbmRlciBtYXkgc2lnbiBjZXJ0aWZpY2F0 ZXMgYW5kIE9DU1AgcmVzcG9uc2VzIHVzaW5nIHRoZSANCnNhbWU8QlI+Jm5ic3A7Jm5ic3A7IHBy aXZhdGUga2V5IG9yIG1heSB1c2UgZGlmZmVyZW50IGtleXMgdG8gc2lnbiBjZXJ0aWZpY2F0ZXMg DQphbmQgT0NTUDxCUj4mbmJzcDsmbmJzcDsgcmVzcG9uc2VzLjwvRElWPg0KPERJVj5UaGUgd29y ZGluZyCTaW50ZWdyYXRlZCBPQ1NQIHJlc3BvbmRlcpQgZGlkIG5vdCBleGlzdGVkIGluIFJGQyAy NTYwLjwvRElWPg0KPERJVj5SRkMgMjU2MCB3YXMgc2F5aW5nOjwvRElWPg0KPERJVj5UaGUga2V5 IHVzZWQgdG8gc2lnbiB0aGUgcmVzcG9uc2UgTVVTVCBiZWxvbmcgdG8gb25lIG9mIHRoZSANCmZv bGxvd2luZzo8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7IC0tIHRoZSBDQSB3aG8gaXNzdWVkIHRo ZSBjZXJ0aWZpY2F0ZSBpbiBxdWVzdGlvbjwvRElWPg0KPERJVj5CdXQgUkZDIDI1NjAgd2FzIGFs c28gc2F5aW5nOjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsgVGhlIGtleSB0aGF0IHNpZ25zIGEg Y2VydGlmaWNhdGUncyBzdGF0dXMgaW5mb3JtYXRpb24gbmVlZCBub3QgDQpiZSB0aGU8QlI+Jm5i c3A7Jm5ic3A7IHNhbWUga2V5IHRoYXQgc2lnbmVkIHRoZSBjZXJ0aWZpY2F0ZS4gQSBjZXJ0aWZp Y2F0ZSdzIA0KaXNzdWVyPEJSPiZuYnNwOyZuYnNwOyBleHBsaWNpdGx5IGRlbGVnYXRlcyBPQ1NQ IHNpZ25pbmcgYXV0aG9yaXR5IGJ5IGlzc3VpbmcgYSANCmNlcnRpZmljYXRlPEJSPiZuYnNwOyZu YnNwOyBjb250YWluaW5nIGEgdW5pcXVlIHZhbHVlIGZvciBleHRlbmRlZEtleVVzYWdlIGluIA0K dGhlIE9DU1Agc2lnbmVyJ3M8QlI+Jm5ic3A7Jm5ic3A7IGNlcnRpZmljYXRlLjwvRElWPg0KPERJ Vj5XaGVuIHJlYWRpbmcgdGhlIHR3byBzZWN0aW9ucyB0b2dldGhlciwgaXQgbWF5IGJlIGludGVy cHJldGVkIHRoZSBmb2xsb3dpbmcgDQp3YXk6IHRoZSBrZXkgdG8gc2lnbiB0aGUgT0NTUCByZXNw b25zZSBhbmQgdGhlIGtleSB0byBzaWduIHRoZSBjZXJ0aWZpY2F0ZSBpcyANCnRoZSBzYW1lIHdo ZW4gdGhlcmUgaXMgbm8gZGVsZWdhdGlvbi48L0RJVj4NCjxESVY+V2UgYXJlIG5vdyBvcGVuaW5n IGEgY2FuIG9mIHdvcm1zIGlmIHdlIGFsbG93IHRoZSBDQSB0byBzaWduIE9DU1AgcmVzcG9uc2Vz IA0Kd2l0aCBhIGtleSBkaWZmZXJlbnQgZnJvbSB0aGUga2V5IHdoaWNoIGluaXRpYWxseSBzaWdu ZWQgdGhlIGNlcnRpZmljYXRlLCBpbiANCnBhcnRpY3VsYXIgd2hlbiB0aGUgQ0EgY2hhbmdlcyBp dHMgaXNzdWluZyBrZXkuPC9ESVY+DQo8RElWPldlIG11c3QgZ3VhcmFudGVlIGJhY2t3YXJkIGNv bXBhdGliaWxpdHkuIFRoaXMgbWVhbnMgdGhhdCB0aGUgQ0EgTVVTVCANCmNvbnRpbnVlIHRvIHNp Z24gT0NTUCByZXNwb25zZXMgd2l0aCB0aGUgc2FtZSBrZXkuIDwvRElWPg0KPERJVj5BZnRlciBh IENBIGtleSByb2xsb3ZlciwgdGhlIGtleSBxdWVzdGlvbiBpcyB3aGV0aGVyIE9DU1AgcmVzcG9u c2VzIGZvciANCpNvbGQgY2VydGlmaWNhdGVzlCBjYW4gQUxTTyBiZSBzaWduZWQgd2l0aCBhIG5l dyBrZXkuIElmIHRoZXJlIGlzIG9ubHkgb25lIA0KYWNjZXNzTG9jYXRpb24gaW4gdGhlIEFJQSBl eHRlbnNpb24gZmllbGQsIHRoaXMgaXMgbm90IHBvc3NpYmxlIGZvciB0aGUgDQppbnRlZ3JhdGVk IGNhc2UuIEZvciBhbGxvd2luZyB0aGlzIHNjaGVtZSwgdGhpcyB3b3VsZCBtZWFuIHRoYXQgdHdv IA0KYWNjZXNzTG9jYXRpb24gZmllbGRzIHNob3VsZCBiZSBwbGFjZWQgaW4gdGhlIEFJQSBleHRl bnNpb24uIE9uZSB3b3VsZCBiZSBwbGFjZWQgDQppbiBhZHZhbmNlIG9mIHRoZSBrZXkgcm9sbG92 ZXIuPC9ESVY+DQo8RElWPkhvd2V2ZXIsIHRoZSBkcmF3YmFjayBpcyB0aGF0IHdlIHdvdWxkIG5l ZWQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBtb3JlIA0KdHlwZXMgb2YgT0NTUCBjbGllbnRzLiA8 L0RJVj4NCjxESVY+T0NTUCBjbGllbnRzIGFibGUgdG8gdGFrZSBpbnRvIGNvbnNpZGVyYXRpb24g dGhlIHNlY29uZCBhY2Nlc3NMb2NhdGlvbiANCmZpbGVkIGluIHRoZSBBSUEgZXh0ZW5zaW9uIEFO RCBhYmxlIHRvIHByb2Nlc3MgdGhlIG9sZC1ieS1uZXcgQ0Egc2VsZiBzaWduZWQgDQpjZXJ0aWZp Y2F0ZS48L0RJVj4NCjxESVY+VGhpcyB3b3VsZCBtYWtlIGFuIGFkZGl0aW9uYWwgdHlwZSBvZiBP Q1NQIGNsaWVudC48L0RJVj4NCjxESVY+QSBjb25zZXJ2YXRpdmUgc29sdXRpb24gdG8gdGhlIHBy b2JsZW0gd291bGQgYmU6PC9ESVY+DQo8RElWPmEpIHRvIHJlcGhyYXNlIHRoZSBuZXcgZGVmaW5p dGlvbiB3aXRoOjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsgQSByZXNwb25kZXIgaXMgYW4gaW50 ZWdyYXRlZCBPQ1NQIHJlc3BvbmRlciBpZiB0aGUgDQpzdWJqZWN0PEJSPiZuYnNwOyZuYnNwOyBk aXN0aW5ndWlzaGVkIG5hbWUgKEROKSBpbiB0aGUgY2VydGlmaWNhdGUgY29udGFpbmluZyANCnRo ZSBwdWJsaWMga2V5PEJSPiZuYnNwOyZuYnNwOyByZXF1aXJlZCB0byB2ZXJpZnkgdGhlIHNpZ25h dHVyZSBvbiB0aGUgT0NTUCANCnJlc3BvbnNlIGlzIHRoZSBzYW1lIGFzPEJSPiZuYnNwOyZuYnNw OyB0aGUgaXNzdWVyIEROIGluIHRoZSB0YXJnZXQgDQpjZXJ0aWZpY2F0ZShzKSBhbmQgaWYgdGhl IGtleSB1c2VkIHRvIDxCUj4mbmJzcDsmbmJzcDsgc2lnbiB0aGUgT0NTUCByZXNwb25zZSBpcyAN CnRoZSBzYW1lIGFzIHRoZSBrZXkgdXNlZCB0byBzaWduIHRoZSA8QlI+Jm5ic3A7Jm5ic3A7IGNl cnRpZmljYXRlLjwvRElWPg0KPERJVj5iKSB0byBkZWxldGUgdGhlIGZvbGxvd2luZyBzZW50ZW5j ZTo8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7IEFuIGludGVncmF0ZWQgT0NTUCByZXNwb25kZXIg bWF5IHNpZ24gY2VydGlmaWNhdGVzIGFuZCBPQ1NQIA0KPEJSPiZuYnNwOyZuYnNwOyByZXNwb25z ZXMgdXNpbmcgdGhlIHNhbWUgcHJpdmF0ZSBrZXkgb3IgbWF5IHVzZSBkaWZmZXJlbnQga2V5cyAN CjxCUj4mbmJzcDsmbmJzcDsgdG8gc2lnbiBjZXJ0aWZpY2F0ZXMgYW5kIE9DU1AgcmVzcG9uc2Vz LjwvRElWPg0KPERJVj5jKSB0byBjaGFuZ2UgdGhlIHRleHQgb24gcGFnZSAxOC4gVGhlIGN1cnJl bnQgdGV4dCBpczo8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdo ZW4gYSBDQSBzaWducyBPQ1NQIHJlc3BvbnNlcyB0byBwcm92aWRlIA0KcmV2b2NhdGlvbjxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RhdHVzIGluZm9ybWF0aW9uIGZvciBpdHMg b3duIA0KY2VydGlmaWNhdGVzLCBpdCBtYXkgc2lnbiB0aGU8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHJlc3BvbnNlcyB1c2luZyANCnRoZSBzYW1lIGtleSBhcyB3YXMgdXNlZCB0 byBzaWduIHRoZSB0YXJnZXQ8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KY2Vy dGlmaWNhdGUocykgb3IgdXNpbmcgYSBkaWZmZXJlbnQga2V5LiZuYnNwOyBPbmUgcmVhc29uIHRo YXQgYSBDQSANCm1heTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2lnbiBhbiBP Q1NQIHJlc3BvbnNlIHVzaW5nIGEgZGlmZmVyZW50IA0Ka2V5IHdvdWxkIGJlIGlmIHRoZSBDQSBo YWQ8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBlcmZvcm1lZCBhIGtleSANCnJv bGxvdmVyIHNpbmNlIGl0IGlzc3VlZCB0aGUgdGFyZ2V0PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCmNlcnRpZmljYXRlKHMpLjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTm90ZTogU29tZSBPQ1NQIGNsaWVudHMs IA0Kd2hlbiBhY2NlcHRpbmcgcmVzcG9uc2VzIGZyb20gDQphbjxCUj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50ZWdyYXRlZCBPQ1NQIA0KcmVzcG9u ZGVyLCB3aWxsIG9ubHkgYWNjZXB0IE9DU1AgcmVzcG9uc2VzIA0KdGhhdDxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXJlIHNpZ25lZCB1c2luZyB0 aGUgDQpzYW1lIGtleSBhcyB0aGUgdGFyZ2V0IGNlcnRpZmljYXRlKHMpLjwvRElWPg0KPERJVj5J dCB3b3VsZCBiZSBjaGFuZ2VkIGludG86PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBXaGVuIGEgQ0Egc2lnbnMgT0NTUCByZXNwb25zZXMgdG8gcHJvdmlkZSANCnJl dm9jYXRpb248QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0YXR1cyBpbmZvcm1h dGlvbiBmb3IgaXRzIG93biANCmNlcnRpZmljYXRlcywgaXQgTVVTVCBzaWduIHRoZTxCUj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzcG9uc2VzIHVzaW5nIA0KdGhlIHNhbWUga2V5 IGFzIHdhcyB1c2VkIHRvIHNpZ24gdGhlIHRhcmdldDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQpjZXJ0aWZpY2F0ZShzKS48L0RJVj4NCjxESVY+ZCkgdG8gY2hhbmdlIHRleHQg aW4gc2VjdGlvbiAyLjMuNi4yIGl0ZW0gMi48L0RJVj4NCjxESVY+VGhpcyB3b3VsZCBzb2x2ZSB0 aGUgd2hvbGUgcHJvYmxlbSBhbmQgdGhlIG5vdGUsIG90aGVyd2lzZSB3ZSB3b3VsZCBoYXZlIHRv IA0KY29uc2lkZXIgYSBmb3VydGggY2FzZSBvZiBPQ1NQIGNsaWVudC4gSSBhbSBub3Qgb3Bwb3Nl ZCB0byB0aGUgZm91cnRoIGNhc2UsIGFzIA0KbG9uZyBhcyBpdCBpcyBjbGVhcmx5IGluZGljYXRl ZCBhbG9uZyB3aXRoIHRoZSByZXF1aXJlbWVudHMgcGxhY2VkIGluIHRoZSANCkNBLjwvRElWPg0K PERJVj48QlI+MykgT24gcGFnZSAxOCBmb3Igk0Rlc2lnbmF0ZWQgT0NTUCByZXNwb25kZXJzlCB0 aGUgdGV4dCBzdGF0ZXM6PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUaGUgQ0EgZG9lcyBub3QgbmVlZCB0byBzaWduIHRoaXMgDQpjZXJ0aWZpY2F0ZSB1c2luZyB0 aGUgc2FtZSBrZXk8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzIHdhcyB1c2Vk IHRvIA0Kc2lnbiB0aGUgdGFyZ2V0IGNlcnRpZmljYXRlKHMpLCBidXQgdGhlIA0KY2VydGlmaWNh dGU8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1VU1QgYmUgaXNzdWVkIHRvIHRo ZSBPQ1NQIA0KcmVzcG9uZGVyIGRpcmVjdGx5IGJ5IHRoZSBDQSB0aGF0PEJSPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBpc3N1ZWQgdGhlIA0KdGFyZ2V0IGNlcnRpZmljYXRlKHMpLjwv RElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgTm90ZTogU29tZSBPQ1NQIGNsaWVudHMsIA0Kd2hlbiBhY2NlcHRpbmcgT0NTUCByZXNwb25z ZXMgZnJvbSANCmE8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRlc2lnbmF0ZWQgT0NTUCByZXNwb25kZXIsIA0Kd2lsbCBvbmx5IGFjY2VwdCBPQ1NQ IHJlc3BvbnNlcyANCmlmPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB0aGUgY2VydGlmaWNhdGUgcmVxdWlyZWQgDQp0byB2YWxpZGF0ZSB0aGUgc2ln bmF0dXJlIG9uIHRoZSANCk9DU1A8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHJlc3BvbnNlIHdhcyBzaWduZWQgDQp1c2luZyB0aGUgc2FtZSBrZXkg YXMgdGhlIA0KdGFyZ2V0PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBjZXJ0aWZpY2F0ZShzKS48L0RJVj4NCjxESVY+V2UgaGF2ZSBhIGJhY2t3YXJk cyBjb21wYXRpYmlsaXR5IHByb2JsZW0gaGVyZS4gPC9ESVY+DQo8RElWPlRvZGF5IE9DU1AgY2xp ZW50cyBkbyBub3QgZXhwZWN0IGEgbmV3IGNlcnRpZmljYXRlIGlzc3VlZCBieSBhIG5ldyBrZXkg ZnJvbSANCnRoZSBzYW1lIENBLiBXZSBhcmUgZmFjZWQgd2l0aCB0d28gY2hvaWNlczogbWFuZGF0 ZSB0aGUgc2FtZSBrZXkgb3IgbWFuZGF0ZSB0aGUgDQppbmNsdXNpb24gaW4gdGhlIE9DU1AgcmVz cG9uc2Ugb2YgdHdvIE9DU1AgY2VydGlmaWNhdGVzIGZvciB0aGUgc2FtZSByZXNwb25kZXIuIA0K SSB3b3VsZCBwcmVmZXIgdGhlIGxhdGVyLjwvRElWPg0KPERJVj5Ob3RlIHRoYXQgY2hhbmdlcyBh cmUgYWxzbyBuZWVkZWQgaW4gc2VjdGlvbiAyLjMuNi4yIGl0ZW0gMy48L0RJVj4NCjxESVY+PEJS PjQpIFRoZSB0ZXh0IHN0YXRlcyBpbiBzZWN0aW9uIDIuMy41LjIgZnJvbSBwYWdlIDE4OjwvRElW Pg0KPERJVj4mbmJzcDsmbmJzcDsgU2luY2UgYW4gYXV0aG9yaXplZCBPQ1NQIHJlc3BvbmRlciBw cm92aWRlcyByZXZvY2F0aW9uIA0Kc3RhdHVzPEJSPiZuYnNwOyZuYnNwOyBpbmZvcm1hdGlvbiBm b3Igb25lIG9yIG1vcmUgQ0FzLCBPQ1NQIGNsaWVudHMgbmVlZCB0byANCmtub3cgaG93IHRvPEJS PiZuYnNwOyZuYnNwOyBjaGVjayB0aGF0IGFuIGF1dGhvcml6ZWQgcmVzcG9uZGVyJ3MgY2VydGlm aWNhdGUgaGFzIA0Kbm90IGJlZW48QlI+Jm5ic3A7Jm5ic3A7IHJldm9rZWQuIDwvRElWPg0KPERJ Vj5UaGUgc2VudGVuY2UgaXMgaW5jb3JyZWN0IHNpbmNlIGl0IGlzIG5vdCB0cnVlIGZvciBpbnRl Z3JhdGVkIA0KcmVzcG9uZGVycy48QlI+Q2hhbmdlIGludG86PC9ESVY+DQo8RElWPiZuYnNwOyZu YnNwOyBPQ1NQIGNsaWVudHMgbmVlZCB0byBrbm93IGhvdyB0byBjaGVjayB0aGF0IGFuIGF1dGhv cml6ZWQgDQpyZXNwb25kZXIncyA8QlI+Jm5ic3A7Jm5ic3A7IGNlcnRpZmljYXRlIGhhcyBub3Qg YmVlbiByZXZva2VkLiA8L0RJVj4NCjxESVY+PEJSPjUpIFRoZSB0ZXh0IHN0YXRlcyBpbiBzZWN0 aW9uIDIuMy42LjIgZnJvbSBwYWdlIDE4OjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsgU3lzdGVt cyBvciBhcHBsaWNhdGlvbnMgdGhhdCByZWx5IG9uIE9DU1AgcmVzcG9uc2VzIE1VU1QgYmUgDQpj YXBhYmxlPEJSPiZuYnNwOyZuYnNwOyBvZiBkZXRlY3RpbmcgYW5kIGVuZm9yY2luZyB1c2Ugb2Yg dGhlIGlkLWFkLW9jc3BTaWduaW5nIA0KdmFsdWUgYXM8QlI+Jm5ic3A7Jm5ic3A7IGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDIuMy41LjEuJm5ic3A7IFRoZXkgTUFZIHByb3ZpZGUgYSANCm1lYW5zIG9m IGxvY2FsbHk8QlI+Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyaW5nIG9uZSBvciBtb3JlIE9DU1Agc2ln bmluZyANCmF1dGhvcml0aWVzLCBhbmQgc3BlY2lmeWluZyB0aGU8QlI+Jm5ic3A7Jm5ic3A7IHNl dCBvZiBDQXMgZm9yIHdoaWNoIGVhY2ggDQpzaWduaW5nIGF1dGhvcml0eSBpcyB0cnVzdGVkLjwv RElWPg0KPERJVj5UaGUgZmlyc3Qgc2VudGVuY2UgaXMgdW50cnVlIGZvciBsb2NhbGx5IHRydXN0 ZWQgT0NTUCByZXNwb25kZXJzIHdoaWxlIHRoZSANCnNlY29uZCBzZW50ZW5jZSBpcyBvbmx5IHRy dWUgZm9yIGxvY2FsbHkgdHJ1c3RlZCBPQ1NQIHJlc3BvbmRlcnMuIEFzIHN0YXRlZCBpbiANCnRo ZSB2ZXJ5IGZpcnN0IGNvbW1lbnQsIHRoaXMgd2hvbGUgc2VjdGlvbiBuZWVkcyB0byBiZSByZXN0 cnVjdHVyZWQgYWNjb3JkaW5nIHRvIA0KdGhlIHRocmVlIGNhc2VzLjwvRElWPg0KPERJVj48QlI+ NikgVGhlIHRleHQgc3RhdGVzIGluIHNlY3Rpb24gNC4xIGZyb20gcGFnZSAyMyBpbiB0aGUgZGlz Y3Vzc2lvbiBhYm91dCANCnRoZSB1c2Ugb2YgaW5zZWN1cmUgYWxnb3JpdGhtcyBpbnNpZGUgdGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbi48L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7 IEluIGFyY2hpdmFsIGFwcGxpY2F0aW9ucyBpdCBpcyBxdWl0ZSBwb3NzaWJsZSB0aGF0IGFuIE9D U1AgDQpyZXNwb25kZXI8QlI+Jm5ic3A7Jm5ic3A7IG1pZ2h0IGJlIGFza2VkIHRvIHJlcG9ydCB0 aGUgdmFsaWRpdHkgb2YgYSBjZXJ0aWZpY2F0ZSANCm9uIGEgZGF0ZSBpbjxCUj4mbmJzcDsmbmJz cDsgdGhlIGRpc3RhbnQgcGFzdC48L0RJVj4NCjxESVY+VGhpcyBmdW5jdGlvbmFsaXR5IGRvZXMg bm90IGV4aXN0OiB0aGVyZSBpcyBubyBkYXRlIGluIHRoZSByZXF1ZXN0IHRvIGFzayANCnRoZSBy ZXZvY2F0aW9uIGF0IGEgdGltZSBpbiB0aGUgcGFzdC4gT0NTUCByZXNwb25kZXJzIGFyZSBub3Qg cmVxdWlyZWQgdG8gcmVwb3J0IA0KdGhlIHZhbGlkaXR5IG9mIGEgY2VydGlmaWNhdGUgb24gYSBk YXRlIGluIHRoZSBkaXN0YW50IHBhc3QuIFBsZWFzZSANCmRlbGV0ZS48L0RJVj4NCjxESVY+Nykg QWxsIHRoZSBzZWN0aW9ucyBmcm9tIHNlY3Rpb24gRCBuZWVkIHRvIGJlIHJldmlzaXRlZCB0byB0 YWtlIGludG8gDQpjb25zaWRlcmF0aW9ucyB0aGUgcHJldmlvdXMgY29tbWVudHMuPC9ESVY+DQo8 RElWPkluIHNlY3Rpb24gRC4xLCBmaWd1cmVzIDIgYW5kIDMgc2hvdWxkIGJlIGRlbGV0ZWQuPC9E SVY+DQo8RElWPkluIHNlY3Rpb24gRC4yLCBmaWd1cmUgNSBzaG91bGQgYmUgZGVsZXRlZCBiZWNh dXNlIGl0IGlzIHVubGlrZWx5IHRoYXQgYSANCnJvb3QgQ0EgdXNlcyB0aGUgc2FtZSBrZXkgdG8g c2lnbiBPQ1NQIHJlc3BvbnNlcy48L0RJVj4NCjxESVY+SW4gZmlndXJlIDYsIHRoaXMgbWVhbnMg dGhhdCB0aGUgY2xpZW50IE1VU1QgYmUgY2FwYWJsZSB0byBwcm9jZXNzIHRoZSANCm9sZC1ieS1u ZXcgc2VsZiBzaWduZWQgY2VydGlmaWNhdGUuIFdoaWxlIGl0IGlzIGEgbmljZSBmZWF0dXJlLCBh bGwgY2xpZW50cyBhcmUgDQpub3QgYWJsZSB0byBkbyBpdCwgdW5sZXNzIHdlIGRlZmluZSBhIG5l dyBjbGFzcyBvZiBjbGllbnRzIGFibGUgdG8gcHJvY2VzcyB0aGF0IA0KY2FzZS4gVGhpcyBpcyBy ZWxhdGVkIHRvIHRoZSBmaXJzdCBhbmQgc2Vjb25kIGNvbW1lbnQgYWJvdXQgdGhlIGRpc3RpbmN0 aW9uIG9mIA0KZGlmZmVyZW50IGNsYXNzZXMgb2YgT0NTUCBjbGllbnRzICh0aHJlZSBvciBmb3Vy KS48L0RJVj4NCjxESVY+SW4gZmlndXJlIDcsIGl0IGlzIHVubGlrZWx5IHRoYXQgYSByb290IENB IHVzZXMgdGhlIHNhbWUga2V5IHRvIHNpZ24gT0NTT1AgDQpyZXNwb25zZXMuIFRoaXMgY2FzZSBz aG91bGQgYmUgZGVsZXRlZCBvciBtb2RpZmllZC48L0RJVj4NCjxESVY+PEJSPjgpIE9uIHBhZ2Ug MzksIHRoZSB0ZXh0IGNsZWFybHkgaW5kaWNhdGVzIHRoZSBwcm9ibGVtOjwvRElWPg0KPERJVj4m bmJzcDsmbmJzcDsgQXMgbm90ZWQgaW4gU2VjdGlvbiAyLjMuNS4xLCBzb21lIE9DU1AgY2xpZW50 cyBjYW5ub3QgDQp2YWxpZGF0ZTxCUj4mbmJzcDsmbmJzcDsgc2lnbmF0dXJlcyBvbiBPQ1NQIHJl c3BvbnNlcyBjcmVhdGVkIGJ5IGRlc2lnbmF0ZWQgT0NTUCANCnJlc3BvbmRlcnMgaWY8QlI+Jm5i c3A7Jm5ic3A7IHRoZSBPQ1NQIHJlc3BvbmRlcidzIGNlcnRpZmljYXRlIGhhcyBiZWVuIHNpZ25l ZCANCnVzaW5nIGEgZGlmZmVyZW50PEJSPiZuYnNwOyZuYnNwOyBrZXkgdGhhbiB0aGUgdGFyZ2V0 IGNlcnRpZmljYXRlLiZuYnNwOyBGaWd1cmUgDQo4IGRlcGljdHMgYSBDQSB0aGF0PEJSPiZuYnNw OyZuYnNwOyBhY2NvbW1vZGF0ZXMgdGhpcyBsaW1pdGF0aW9uIGJ5IGlzc3VpbmcgdHdvIA0KY2Vy dGlmaWNhdGVzIHRvIHRoZTxCUj4mbmJzcDsmbmJzcDsgZGVzaWduYXRlZCBPQ1NQIHJlc3BvbmRl ciwgb25lIHNpZ25lZCB3aXRoIA0KaXRzIG9sZCBwcml2YXRlIGtleSBhbmQ8QlI+Jm5ic3A7Jm5i c3A7IG9uZSBzaWduZWQgd2l0aCBpdHMgbmV3IHByaXZhdGUgDQprZXkuJm5ic3A7IEJvdGggY2Vy dGlmaWNhdGVzIGluY2x1ZGUgYW48QlI+Jm5ic3A7Jm5ic3A7IGV4dGVuZGVkIGtleSB1c2FnZSAN CmV4dGVuc2lvbiB3aXRoIHRoZSBpZC1rcC1PQ1NQU2lnbmluZyBPSUQuPC9ESVY+DQo8RElWPklu IG9yZGVyIHRvIGFjaGlldmUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgaWYgdGhlIENBIGlzc3Vl cyBhbiBvbGQtYnktbmV3IA0Kc2VsZiBzaWduZWQgY2VydGlmaWNhdGUsIHRoZW4gdGhlIENBIFNI QUxMIGlzc3VlIHR3byBjZXJ0aWZpY2F0ZXMsIHdoaWNoIGFsc28gDQptZWFuIHRoYXQgdGhlIE9D U1AgcmVzcG9uZGVyIFNIQUxMIGluY2x1ZGUgaXRzIHR3byBjZXJ0aWZpY2F0ZXMgaW4gdGhlIGNl cnRzIA0KZmllbGQgZnJvbSBCYXNpY09DU1BSZXNwb25zZS48L0RJVj4NCjxESVY+VGhpcyByZXF1 aXJlbWVudCBzaG91bGQgYmUgbW92ZWQgaW4gdGhlIG5vcm1hdGl2ZSBwYXJ0IG9mIHRoZSBSRkMu PC9ESVY+DQo8RElWPjxCUj45KSBCVFcsIHRoZSBmaWVsZCBjZXJ0cyBpcyBub3QgZGVzY3JpYmVk IGFuZCBzaG91bGQgYmUgZGVzY3JpYmVkLiBPdGhlciANCmZpZWxkcyBmcm9tIEJhc2ljT0NTUFJl c3BvbnNlIGFyZSBub3QgZGVzY3JpYmVkIGVpdGhlciAhIDotKDwvRElWPg0KPERJVj48QlI+MTAp IEluIHRoZSBjYXNlIG9mIGZpZ3VyZSA5LCB0aGUgT0NTUCByZXNwb25kZXIgU0hBTEwgaW5jbHVk ZSBhbGwgdGhyZWUgDQpjZXJ0aWZpY2F0ZXMgaW4gdGhlIGZpZWxkIGNlcnRzIGZyb20gQmFzaWNP Q1NQUmVzcG9uc2UuIFRoaXMgcmVxdWlyZW1lbnQgc2hvdWxkIA0KYmUgbW92ZWQgaW4gdGhlIG5v cm1hdGl2ZSBwYXJ0IG9mIHRoZSBSRkMuPC9ESVY+DQo8RElWPjxCUj4xMSkgSW4gZmlndXJlIDEw LCB0aGUgdGV4dCBpcyBtaXNzaW5nIHRvIHNheSB3aGF0IHRoZSBjbGllbnQgc2hhbGwgYmUgDQpk b2luZy48L0RJVj4NCjxESVY+PEJSPjEyKSBJbiB0aGUgZmlyc3QgY29tbWVudCwgSSBzYWlklCBX aGlsZSBPQ1NQIHJlc3BvbmRlcnMgYmVoYXZlIA0KKnJvdWdobHkqIHRoZSBzYW1llC4gVGhlcmUg aXMgYSBkaXN0aW5jdGlvbiB0byBpbnRyb2R1Y2U6IHRoZSBudW1iZXIgb2YgY2VydHMgDQp0aGF0 IHRoZSBPQ1NQIHJlc3BvbnNlIFNIQUxMIGluY2x1ZGUgaW4gdGhlIGNhc2Ugb2YgdGhlIGludGVn cmF0ZWQgT0NTUCANCnJlc3BvbmRlcnMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj46 PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4tLS0tLSBNZXNzYWdlIHJl53UgLS0tLS0g PC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkct TEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29s aWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBu b3JtYWw7IEZPTlQtU0laRTogOXB0OyBCQUNLR1JPVU5EOiAjZTRlNGU0OyBMSU5FLUhFSUdIVDog bm9ybWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtVkFSSUFOVDogbm9ybWFsOyBmb250LWNv bG9yOiBibGFjayI+PEI+RGUgDQogIDo8L0I+IDxBIGhyZWY9Im1haWx0byA6cGtpeC1ib3VuY2Vz QGlldGYub3JnIj5wa2l4LWJvdW5jZXM8L0E+IDwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iRk9O VC1XRUlHSFQ6IG5vcm1hbDsgRk9OVC1TSVpFOiA5cHQ7IExJTkUtSEVJR0hUOiBub3JtYWw7IEZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1WQVJJQU5UOiBub3JtYWwiPjxCPsAgDQogIDo8L0I+IDxB IGhyZWY9Im1haWx0byA6cGtpeEBpZXRmLm9yZyI+cGtpeEBpZXRmLm9yZzwvQT4gPC9ESVY+DQog IDxESVYgDQogIHN0eWxlPSJGT05ULVdFSUdIVDogbm9ybWFsOyBGT05ULVNJWkU6IDlwdDsgTElO RS1IRUlHSFQ6IG5vcm1hbDsgRk9OVC1TVFlMRTogbm9ybWFsOyBGT05ULVZBUklBTlQ6IG5vcm1h bCI+PEI+RGF0ZSANCiAgOjwvQj4gMjAxMS0wNi0wNiwgMTY6MjM6NTM8L0RJVj4NCiAgPERJViAN CiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBub3JtYWw7IEZPTlQtU0laRTogOXB0OyBMSU5FLUhFSUdI VDogbm9ybWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtVkFSSUFOVDogbm9ybWFsIj48Qj5T dWpldCANCiAgOjwvQj4gUmU6IFtwa2l4XSBUcnVzdGVkIHJlc3BvbmRlcnMgaW4gT0NTUDwvRElW Pg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJ Vj4NCiAgPERJVj5JIGZpbmFsbHkgZ290IGFyb3VuZCB0byByZWFkaW5nIHRoZSBjdXJyZW50IDI1 NjAgYmlzIGRyYWZ0LjxCUj48QlI+SSANCiAgd291bGQgdm90ZSBhZ2FpbnN0IGl0IHNpbmNlIGl0 IHNhY3JpZmljZXMgc2VjdXJpdHkgZXhwbGljaXRseSBzdGF0ZWQgb3IgDQogIGltcGxpZWQgaW4g MjU2MC4gTXkgYXJndW1lbnRzIGFyZSB3ZWxsIHJlY29yZGVkIGluIFBLSVggZm9ydW0uIEkgd2ls bCBub3QgDQogIHJlcGVhdCB0aG9zZS4gSW4gYWRkaXRpb24sIGFuIE9DU1AgY2xpZW50IG1heSBo YXZlIGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMgDQogIHdpdGggYSBzZXJ2ZXIgY2xhaW1pbmcg Y29tcGxpYW5jZSB3aXRoIHRoaXMgZHJhZnQgDQogIHN0YW5kYXJkLjxCUj48QlI+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08QlI+RnJvbTogPEEgDQogIGhyZWY9Im1haWx0bzogcGtpeC1ib3Vu Y2VzQGlldGYub3JnIj5wa2l4LWJvdW5jZXNAaWV0Zi5vcmc8L0E+IFttYWlsdG86PEEgDQogIGhy ZWY9Im1haWx0bzogcGtpeC1ib3VuY2VzQGlldGYub3JnIj5wa2l4LWJvdW5jZXNAaWV0Zi5vcmc8 L0E+XSBPbiBCZWhhbGYgT2YgDQogIFN0ZWZhbiBTYW50ZXNzb248QlI+U2VudDogTW9uZGF5LCBN YXkgMzAsIDIwMTEgNTo0NyBBTTxCUj5UbzogVG9tYXMgDQogIEd1c3RhdnNzb247IDxBIGhyZWY9 Im1haWx0bzogcGtpeEBpZXRmLm9yZyI+cGtpeEBpZXRmLm9yZzwvQT48QlI+U3ViamVjdDogUmU6 IA0KICBbcGtpeF0gVHJ1c3RlZCByZXNwb25kZXJzIGluIE9DU1A8QlI+PEJSPlRoaXMgaXMgaG93 IEkgd291bGQgbGlrZSB0byBjaGFuZ2UgDQogIHRoaXMgc2VjdGlvbiBpbiBSRkMgMjU2MGJpczxC Uj48QlI+PEEgDQogIGhyZWY9Imh0dHA6Ly90aW55dXJsLmNvbS8yNTYwYmlzLXRyIj5odHRwOi8v dGlueXVybC5jb20vMjU2MGJpcy10cjwvQT48QlI+PEJSPjxCUj4vU3RlZmFuPEJSPjxCUj5PbiAN CiAgMTEtMDUtMzAgMTA6MTEgQU0sICJUb21hcyBHdXN0YXZzc29uIiAmbHQ7PEEgDQogIGhyZWY9 Im1haWx0bzogdG9tYXNAcHJpbWVrZXkuc2UiPnRvbWFzQHByaW1la2V5LnNlPC9BPiZndDsgDQog IHdyb3RlOjxCUj48QlI+Jmd0OzxCUj4mZ3Q7SSBhZ3JlZSB0aGF0LCBhbHNvIGFjY29yZGluZyB0 byBteSBleHBlcmllbmNlLCB0aGlzIA0KICBpcyBob3cgT0NTUDxCUj4mZ3Q7dmFsaWRhdGlvbiB3 b3JrcyBpbiBwcmFjdGljZSB0b2RheS4gV2ljaCBpcyBwcm9iYWJseSB3aHkgaXQgDQogIGdlbmVy YWxseTxCUj4mZ3Q7d29ya3MgcXVpdGUgDQogIHdlbGwuPEJSPiZndDs8QlI+Jmd0O0NoZWVycyw8 QlI+Jmd0O1RvbWFzPEJSPiZndDs8QlI+Jmd0O09uIDA1LzI4LzIwMTEgMDk6MjQgDQogIFBNLCBT dGVmYW4gU2FudGVzc29uIHdyb3RlOjxCUj4mZ3Q7Jmd0OyBJJ20gd29ycmllZCBhYm91dCB0aGUg bmV3IHdvcmRpbmcgaW4gDQogIHJmYzI1NjBiaXMgcmVnYXJkaW5nIHRydXN0ZWQ8QlI+Jmd0OyZn dDsgcmVzcG9uZGVycy48QlI+Jmd0OyZndDsgPEJSPiZndDsmZ3Q7IA0KICBJJ3ZlIHNwZW50IHNv bWUgdGltZSBub3cgZG9pbmcgYWN0dWFsIGltcGxlbWVudGF0aW9uIG9mIE9DU1AgDQogIGNoZWNr aW5nPEJSPiZndDsmZ3Q7IHVzaW5nIGV4aXN0aW5nIGxpYnJhcmllcyBhbmQgSSBmZWFyIHRoYXQg Y3VycmVudCBSRkMgDQogIDI1Nm9iaXMgd2lsbCBjYXVzZTxCUj4mZ3Q7Jmd0OyBtb3JlIGNvbmZ1 c2lvbiBhbmQgbGVzcyBpbnRlcm9wZXJhYmlsaXR5LCB0aGFuIA0KICBpZiB3ZSBrZWVwIDI1NjAg YXMgaXQgaXMuPEJSPiZndDsmZ3Q7IDxCUj4mZ3Q7Jmd0OyBUaGUgY3VycmVudCBiaXMgdGV4dCBt aWdodCANCiAgYmUgYWxsICJYLjUwOSIgcHVyaXNoIGJ1dCBpdCBpcyBub3QgdmVyeTxCUj4mZ3Q7 Jmd0OyBoZWxwZnVsIGluIGF0dGFpbmluZyANCiAgaW50ZXJvcGVyYWJpbGl0eS48QlI+Jmd0OyZn dDsgPEJSPiZndDsmZ3Q7IFJGQyAyNTYwIGRvZXMgbm90IGRlYWwgd2l0aCBrZXkgDQogIHJvbGxv dmVyLiBJdCBzZWFtcyB0byBhc3N1bWUgdGhhdCBDQXMgZG88QlI+Jmd0OyZndDsgd2hhdCB0aGV5 IGluIHByYWN0aWNlIA0KICBhbHdheXMgZG8sIGkuZS4gVGhleSBsZXQgdGhlIGxpZmV0aW1lIG9m IHRoZWlyPEJSPiZndDsmZ3Q7IGlzc3Vpbmcga2V5IGV4Y2VlZCANCiAgdGhlIGxpZmV0aW1lIG9m IGFueSBjZXJ0aWZpY2F0ZSB0aGV5IGlzc3VlLjxCUj4mZ3Q7Jmd0OyBUaGUgc2VsZiBkZXNpZ25h dGlvbiANCiAgZXhwcmVzcyB0aGF0IHRoZSByZXNwb25kZXIgY2VydGlmaWNhdGUgImlzIFRIRTxC Uj4mZ3Q7Jmd0OyBjZXJ0aWZpY2F0ZSBvZiB0aGUgDQogIENBIiB0aGF0IGlzc3VlZCB0aGUgY2Vy dCBiZWluZyBjaGVja2VkLiBJIGludGVycHJldDxCUj4mZ3Q7Jmd0OyB0aGlzIHRvIGJlIHRoZSAN CiAgQ0EgY2VydGlmaWNhdGUgZm91bmQgaW4gdGhlIGNlcnQgcGF0aCBvZiB0aGUgY2VydGlmaWNh dGU8QlI+Jmd0OyZndDsgYmVpbmcgDQogIHZhbGlkYXRlZC48QlI+Jmd0OyZndDsgPEJSPiZndDsm Z3Q7IE1vc3QgaW1wbGVtZW50ZXJzIHNlZW1zIHRvIGhhdmUgYWdyZWVkIGFuZCANCiAgdW5kZXJz dG9vZCB0aGlzIHRvIGJlIGFuIGVhc3k8QlI+Jmd0OyZndDsgY2hlY2suPEJSPiZndDsmZ3Q7IDxC Uj4mZ3Q7Jmd0OyBJZiANCiAgKHJlc3BvbnNlIHNpZ25hdHVyZSBjYW4gYmUgdmVyaWZpZWQgYnkg Q0EgY2VydCkge2NoZWNrIE9LfSBlbHNlIA0KICB7Y2VjazxCUj4mZ3Q7Jmd0OyBGQUlMfTxCUj4m Z3Q7Jmd0OyA8QlI+Jmd0OyZndDsgVGhlIHNhbWUgZ29lcyBmb3IgZGVzaWduYXRlZCANCiAgcmVz cG9uZGVyczo8QlI+Jmd0OyZndDsgPEJSPiZndDsmZ3Q7IElmIChkZXNpZ25hdGVkIHJlc3BvbmRl ciBjZXJ0IGNhbiBiZSANCiAgdmVyaWZpZWQgYnkgdGhlIENBIGNlcnQpIHtjaGVjayBPS308QlI+ Jmd0OyZndDsgZWxzZSB7Y2VjayBGQUlMfTxCUj4mZ3Q7Jmd0OyANCiAgPEJSPiZndDsmZ3Q7IDxC Uj4mZ3Q7Jmd0OyBTaW5jZSB0aGlzIGlzIHRoZSBjdXJyZW50IGNvbmZpZ3VyYXRpb24gYXJvdW5k IHdoaWNoIA0KICBpbnRlcm9wZXJhYmlsaXR5IGlzPEJSPiZndDsmZ3Q7IGFjaGlldmVkLCB0aGlz IGlzIHRoZSBjb25maWd1cmF0aW9uIHRoYXQgDQogIHNob3VsZCBiZSBwcm9tb3RlZCBpbjxCUj4m Z3Q7Jmd0OyByZmMyNTYwYmlzIGFzIE1VU1QgaW1wbGVtZW50IGZvciBPQ1NQIA0KICBjbGllbnRz LjxCUj4mZ3Q7Jmd0OyBBbnl0aGluZyBlbHNlIHNob3VsZCBiZSBPUFRJT05BTC48QlI+Jmd0OyZn dDsgDQogIDxCUj4mZ3Q7Jmd0OyBCZXlvbmQgdGhpcyB0aGVyZSBhcmUgYSBrYXppbGxpb24gb2Yg Y29uZmlndXJhdGlvbiBvcHRpb25zIGZvciANCiAgYWxsb3dpbmc8QlI+Jmd0OyZndDsga2V5IHJv bGxvdmVyLCBkZXNpZ25hdGVkIHJlc3BvbmRlcnMgYW5kIGV2ZW4gKHdoaWNoIEkgDQogIGhhdmUg c2VlbiBleGFtcGxlczxCUj4mZ3Q7Jmd0OyBvZikgZGVzaWduYXRlZCBDQXMgb25seSBpc3N1aW5n IHJlc3BvbmRlciANCiAgY2VydHMuIFRoZXNlIGFyZSBhbGwgZmluZSBpbjxCUj4mZ3Q7Jmd0OyBs b2NhbCBjb21tdW5pdGllcyB1bmRlciBsb2NhbCBwb2xpY3ksIA0KICBidXQgbm8gb25lIHNob3Vs ZCBleHBlY3QgYSBnZW5lcmFsPEJSPiZndDsmZ3Q7IE9DU1AgY2xpZW50IHRvIGhhbmRsZSANCiAg dGhlbS48QlI+Jmd0OyZndDsgPEJSPiZndDsmZ3Q7IC9TdGVmYW48QlI+Jmd0OyZndDsgPEJSPiZn dDsmZ3Q7IDxCUj4mZ3Q7Jmd0OyANCiAgPEJSPiZndDsmZ3Q7IDxCUj4mZ3Q7Jmd0OyANCiAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyZndDsg cGtpeCBtYWlsaW5nIA0KICBsaXN0PEJSPiZndDsmZ3Q7IDxBIGhyZWY9Im1haWx0bzogcGtpeEBp ZXRmLm9yZyI+cGtpeEBpZXRmLm9yZzwvQT48QlI+Jmd0OyZndDsgDQogIDxBIA0KICBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXgiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcGtpeDwvQT48QlI+Jmd0OzxCUj4mZ3Q7X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0O3BraXggDQogIG1h aWxpbmcgbGlzdDxCUj4mZ3Q7PEEgDQogIGhyZWY9Im1haWx0bzogcGtpeEBpZXRmLm9yZyI+cGtp eEBpZXRmLm9yZzwvQT48QlI+Jmd0OzxBIA0KICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3BraXgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcGtpeDwvQT48QlI+PEJSPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxCUj5wa2l4IA0KICBtYWlsaW5nIGxpc3Q8QlI+PEEgaHJlZj0ibWFpbHRv OiBwa2l4QGlldGYub3JnIj5wa2l4QGlldGYub3JnPC9BPjxCUj48QSANCiAgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wa2l4Ij5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3BraXg8L0E+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPEJSPnBraXggDQogIG1haWxpbmcgbGlzdDxCUj48QSBocmVm PSJtYWlsdG86IHBraXhAaWV0Zi5vcmciPnBraXhAaWV0Zi5vcmc8L0E+PEJSPjxBIA0KICBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXgiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGtpeDwvQT48QlI+PEJSPjwvRElWPjwvRElWPjwv QkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_11060815065276066417436_002-- From marsh@extendedsubset.com Wed Jun 8 09:58:34 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFA611E8124; Wed, 8 Jun 2011 09:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ap08nTqyKK-e; Wed, 8 Jun 2011 09:58:33 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id B205E11E8116; Wed, 8 Jun 2011 09:58:33 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QUM5M-000CiO-Tx; Wed, 08 Jun 2011 16:58:29 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id DC712606D; Wed, 8 Jun 2011 16:58:25 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/rzfy4xvQ9qWn+YkqaFIScB8s43rtL+Ns= Message-ID: <4DEFAA31.4040709@extendedsubset.com> Date: Wed, 08 Jun 2011 11:58:25 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Yoav Nir References: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> In-Reply-To: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" , "tls@ietf.org" Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 16:58:34 -0000 On 06/08/2011 03:37 AM, Yoav Nir wrote: > > What did Comodo fail to do? If this question is seriously being asked by one as knowledgeable as Yoav :-), it suggests to me that the problem is being way over-thinked. So forgive me, I'm just going to re-state this bluntly: The entire value proposition of PKI is based on the trusted root CAs refusing to issue fraudulent certs and in this case Comodo, a trusted root, failed to refuse to issue certain fraudulent certs. > The RA is handing contact with the customer, so it's their job to > make sure that the customer is in fact the owner of the domain name > in the certificate request. These legal agreements and auditing procedures only amount to one thing: after the victim has been (possibly irreparably) harmed by the issuance of a fraudulent certificate, then some legal entity is in a technical violation of contract with some other legal entity. In this case, I've heard of no serious repurcussions other than the loss of image to the CA and the RAs. Certainly significant for Comodo, but most of the press coverage doesn't even mention the names of the hacked RAs. Is the CA suing any hacked RA for breach of contract? Are they even terminating their agreements? Are browser vendors removing any root CAs or blacklisting any sub-CAs due to this? What are the costs paid for this debacle as perceived by others with the authority to cause the immediate issuance of certs? Most importantly, will these costs always be perceived higher than the immediate gain of a corrupt transaction? This is not to suggest any corruption in this case of course, but it is surely not going unnoticed for the future that the CA, the RAs, and the individuals involved all demonstrated effective deniability. This seems like a good test case to either support or refute the arguments of those who claim that policies, auditing, and legal agreements between CAs/RAs/subCAs are an effective way to produce strong security. - Marsh From internet-drafts@ietf.org Wed Jun 8 13:41:56 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE81011E814D; Wed, 8 Jun 2011 13:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 eMdOWwlC3T8x; Wed, 8 Jun 2011 13:41:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B57411E8076; Wed, 8 Jun 2011 13:41:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110608204156.21801.37044.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2011 13:41:56 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-caa-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 20:41:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : DNS Certification Authority Authorization (CAA) Resource= Record Author(s) : Phillip Hallam-Baker Rob Stradling Ben Laurie Filename : draft-ietf-pkix-caa-00.txt Pages : 23 Date : 2011-06-02 The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis- issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-caa-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-caa-00.txt From mrex@sap.com Wed Jun 8 19:44:25 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896C221F84EE; Wed, 8 Jun 2011 19:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.235 X-Spam-Level: X-Spam-Status: No, score=-9.235 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 KV8CRFiwzvA9; Wed, 8 Jun 2011 19:44:25 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C5BB121F84ED; Wed, 8 Jun 2011 19:44:24 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p592i87e028403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Jun 2011 04:44:08 +0200 (MEST) From: Martin Rex Message-Id: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 9 Jun 2011 04:44:07 +0200 (MEST) In-Reply-To: from "Peter Gutmann" at Jun 8, 11 06:56:23 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 02:44:25 -0000 Peter Gutmann wrote: > > Yoav Nir writes: > > > > CAA works if all root CAs and affiliates follow it. That's hundreds or > > thousands of entities. Any one of them that fails to comply might ignore > > the CAA record. > > That was my problem with it, any CA (and/or RA) that's already diligent > about cert issuance doesn't need CAA, and any one that isn't won't use > it anyway, so it doesn't address any existing problem. You're looking at CAA from the wrong angle. CAA is _not_ for the RP, i.e. not for _you_ (and me, and most others ...) It is only another means for a CA to detect attempts to subvert one of its RAs, so it's primary purpose is CYA for large commercial CAs. So a Server admin that has a CAA published is not really using it to _protect_ clients. It may reduce the likelyhood to get certs mis-issued, though, and is therefore well in the ballpark of what businesses are doing to protect against fraud (not protecting against it, just make it remain under a certain fraud loss threshold). -Martin From ynir@checkpoint.com Wed Jun 8 23:02:39 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D93B11E80A6; Wed, 8 Jun 2011 23:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.073 X-Spam-Level: X-Spam-Status: No, score=-10.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 SIqb6+dJ0n1O; Wed, 8 Jun 2011 23:02:38 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7640211E8074; Wed, 8 Jun 2011 23:02:37 -0700 (PDT) X-CheckPoint: {4DF06FFC-F-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p5962Prd000751; Thu, 9 Jun 2011 09:02:25 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 9 Jun 2011 09:02:25 +0300 From: Yoav Nir To: Marsh Ray Date: Thu, 9 Jun 2011 09:02:24 +0300 Thread-Topic: [TLS] [pkix] Proposing CAA as PKIX Working Group Item Thread-Index: Acwmas3vqVa1+wROSeCVYqt8EJtOAw== Message-ID: <5F3CE8C6-9D13-4BCB-A4C0-8D755D4BF027@checkpoint.com> References: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> <4DEFAA31.4040709@extendedsubset.com> In-Reply-To: <4DEFAA31.4040709@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" , "tls@ietf.org" Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 06:02:39 -0000 On Jun 8, 2011, at 7:58 PM, Marsh Ray wrote: > On 06/08/2011 03:37 AM, Yoav Nir wrote: >>=20 >> What did Comodo fail to do? >=20 > If this question is seriously being asked by one as knowledgeable as=20 > Yoav :-), it suggests to me that the problem is being way over-thinked.=20 > So forgive me, I'm just going to re-state this bluntly: >=20 > The entire value proposition of PKI is based on the trusted root CAs=20 > refusing to issue fraudulent certs and in this case Comodo, a trusted=20 > root, failed to refuse to issue certain fraudulent certs. Similarly, the value proposition of the DMV is to not issue a driver's lice= nse with the name "Marsh Ray" to people who are not Marsh Ray. These days y= ou don't even have to know how to drive. There is an established "best practice" for how the DMV ascertains who you = are: they examine birth certificates, they check street address, etc. Suppose I go to some RA or CA, and ask for a certificate for www.yoavnir.co= m, what are they going to do to check? Obviously, they can check the whois database. This has: > Registrant: > Yoav Nir >=20 > Registered through: GoDaddy.com, Inc. (http://www.godaddy.com) > Domain Name: YOAVNIR.COM >=20 > Domain servers in listed order: > NS1.GISIGHT.CO.IL > NS2.GISIGHT.CO.IL >=20 >=20 > For complete domain details go to: > http://who.godaddy.com/whoischeck.aspx?Domain=3DYOAVNIR.COM So far, so good. The registrant name is indeed "Yoav Nir". But we're probab= ly doing this through web or email, so how can they know that I'm actually = the same "Yoav Nir"? Or a "Yoav Nir" at all? We can check through the lin= k to godaddy (I've removed some of the information): > Registrant: > Yoav Nir > Amir 1 N/A N/A Kibbutz Amir N/A,12140 Fax. +4.46954329=20 >=20 > Registered through: GoDaddy.com, Inc. (http://www.godaddy.com) > Domain Name: YOAVNIR.COM > Created on: 14-Sep-08 > Expires on: 14-Sep-12 > Last Updated on: 25-Jun-10 >=20 > Administrative Contact: > Nir, Yoav yoavnir@amir.org.il > Amir 1 N/A N/A Kibbutz Amir N/A,12140 Fax. +4.46954329=20 > Tel. +972.46954329 >=20 > Technical Contact: > Ltd., Interspace domreg@interspace.net > 19 Yad Harutzim St. Netanya null,42505 Tel. +972.732224444=20 This gives some new information. We have an administrative contact: "yoavni= r@amir.org.il" and a technical contact: "domreg@interspace.net" I have never actually bought an SSL certificate, so I don't know, but I'll = have to assume that part of the automated process involves email to one of = these addresses. There are also phone numbers, but I can't imagine a DV cer= tificate that costs $10-$40 involving an international phone call by a huma= n. That's where I would fail. I don't control these email addresses, and the s= ite belongs to another Yoav Nir who's in a totally different line of busine= ss. This is the simple check that a diligent CA can do. But this is as long as = the CA is a single entity.=20 I don't know of any best practices document that says anything about the di= vision of responsibility between the CA and RA. Is it OK to have only the R= A perform the whois check? Sure, but then what is the added value of the C= A? The reason I like CAA is that it gives an extra layer of security for t= he CA to perform even assuming that the RA has been subverted. The way things stand now, I don't see what Comodo could have done different= ly technically. Sure, we can say that they should not have had a business r= elationship with an RA that was so easily hackable. Similarly, Verisign sho= uld now have allowed rapidssl to use such bad practices. But at the time of= the attack, I don't see what check Comodo could have done. Others (like Peter Gutmann and Bruce Schneier) have written about this befo= re. The model for HTTPS security is what's broken, not a particular CA. The= re are just too many single points of failure. CAA is an attempt to make th= e existing model somewhat better, by adding another layer of security - a s= ecurity check that the CA can do after the RA has already approved the tran= saction. DANE is a more revolutionary solution that aims to replace or supp= lement the existing model. I think both have value, with CAA having value m= uch sooner. Yoav From tgindin@us.ibm.com Thu Jun 9 05:11:09 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9852311E809A; Thu, 9 Jun 2011 05:11:09 -0700 (PDT) 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 nHJ7IDvoDkNe; Thu, 9 Jun 2011 05:11:07 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 637BA11E807C; Thu, 9 Jun 2011 05:11:05 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p59BeVEH006700; Thu, 9 Jun 2011 07:40:31 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p59CAuxu105006; Thu, 9 Jun 2011 08:10:56 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p598Aiph006468; Thu, 9 Jun 2011 05:10:44 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p598AicL006465; Thu, 9 Jun 2011 05:10:44 -0300 In-Reply-To: References: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> To: Phillip Hallam-Baker MIME-Version: 1.0 X-KeepSent: B299299E:1FCA02D8-852578A9:0052F9E2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Tom Gindin Message-ID: Date: Thu, 9 Jun 2011 08:10:54 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 06/09/2011 08:10:55, Serialize complete at 06/09/2011 08:10:55 Content-Type: text/plain; charset="US-ASCII" Cc: pkix , paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 12:11:09 -0000 This check seems to be primarily useful when the CA gives high (arguably too high) levels of trust to multiple RA's, and the CA is more carefully operated than some and perhaps all of its RA's. Is that situation unique to Comodo, or are they the extreme case of a common arrangement when there are independent RA's? This is a reasonable suggestion if there are other CA's half as vulnerable as Comodo. Tom Gindin P.S. - The opinions above are mine, and not necessarily those of my employer From: Phillip Hallam-Baker To: Peter Gutmann Cc: pkix@ietf.org, paul.hoffman@vpnc.org, tls@ietf.org Date: 06/08/2011 08:58 AM Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item Sent by: pkix-bounces@ietf.org sorry, that should have been, the previous year. CAA was developed in the fall of 2010. On Wed, Jun 8, 2011 at 8:56 AM, Phillip Hallam-Baker wrote: First off, I think that people need to stop using the -gate suffix. Just because a competitor decided that they would attempt to apply it does not mean it is justified. That is an old game and a rather silly one in our industry. The relevant cautionary text here being John 8:7. What differentiates companies in our industry is not whether they are breached, it is whether they give prompt, voluntary notice of breaches that occur or not. The market leaders in the CA industry have a track record of having done so. As for CAA being a response to the Iranian attack, Ben, Rob and I developed it a year earlier. The point of proposals like CAA is not whether they are 'necessary' or not, it is whether they mitigate risk. I have never seen a security control involving a human element that is guaranteed to be operated with 100% accuracy every time. So whenever there are humans involved I like to have strength in depth. There would be no problem here if browsers actually implemented revocation checking either. But we have had that in PKIX specs for 15 years and it still isn't deployed in hard fail mode. Which is rather sad when you consider that about 70% of the complexity of PKI comes from the need for revocation. -- Website: http://hallambaker.com/ _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From paul.hoffman@vpnc.org Thu Jun 9 09:11:02 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C7F11E813D for ; Thu, 9 Jun 2011 09:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 CghPIdt6ncvE for ; Thu, 9 Jun 2011 09:11:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF8A11E80EA for ; Thu, 9 Jun 2011 09:10:59 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p59GAkvi055178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jun 2011 09:10:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> Date: Thu, 9 Jun 2011 09:10:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: [pkix] CAA and relying parties X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 16:11:02 -0000 On Jun 8, 2011, at 7:44 PM, Martin Rex wrote: > CAA is _not_ for the RP, i.e. not for _you_ (and me, and most others = ...) > It is only another means for a CA to detect attempts to subvert one of > its RAs, so it's primary purpose is CYA for large commercial CAs. That's not what draft-ietf-pkix-caa-00.txt says. Section 2.3 explicitly = covers relying parties using CAA. I believe that section should be = removed, but it is in the current WG document. --Paul Hoffman= From koichi.sugimoto@globalsign.com Thu Jun 9 21:23:58 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764C011E8146 for ; Thu, 9 Jun 2011 21:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DEAR_SOMETHING=1.605, 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 c1xbIT6Lrylc for ; Thu, 9 Jun 2011 21:23:57 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id BC86011E80E7 for ; Thu, 9 Jun 2011 21:23:57 -0700 (PDT) Received: by pxi20 with SMTP id 20so1679986pxi.27 for ; Thu, 09 Jun 2011 21:23:55 -0700 (PDT) Received: by 10.68.56.100 with SMTP id z4mr759581pbp.5.1307679835051; Thu, 09 Jun 2011 21:23:55 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id w2sm1982347pbg.53.2011.06.09.21.23.54 (version=SSLv3 cipher=OTHER); Thu, 09 Jun 2011 21:23:54 -0700 (PDT) Received: by pzk5 with SMTP id 5so1156282pzk.31 for ; Thu, 09 Jun 2011 21:23:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.52.70 with SMTP id r6mr698326pbo.465.1307679833975; Thu, 09 Jun 2011 21:23:53 -0700 (PDT) Received: by 10.68.52.166 with HTTP; Thu, 9 Jun 2011 21:23:53 -0700 (PDT) In-Reply-To: <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> Date: Fri, 10 Jun 2011 13:23:53 +0900 Message-ID: From: koichi sugimoto To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: pkix@ietf.org Subject: Re: [pkix] CAA and relying parties X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 04:23:58 -0000 Dear Sirs, I think so, too. If CAA prevents only misissuing certificates, then, the section should be removed. Regards, Koichi Sugimoto. 2011/6/10 Paul Hoffman : > On Jun 8, 2011, at 7:44 PM, Martin Rex wrote: > >> CAA is _not_ for the RP, i.e. not for _you_ (and me, and most others ...) >> It is only another means for a CA to detect attempts to subvert one of >> its RAs, so it's primary purpose is CYA for large commercial CAs. > > That's not what draft-ietf-pkix-caa-00.txt says. Section 2.3 explicitly covers relying parties using CAA. I believe that section should be removed, but it is in the current WG document. > > --Paul Hoffman > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From hallam@gmail.com Fri Jun 10 09:46:02 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C86621F849F for ; Fri, 10 Jun 2011 09:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 0u9I65WgcN8T for ; Fri, 10 Jun 2011 09:46:01 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B35321F8490 for ; Fri, 10 Jun 2011 09:45:58 -0700 (PDT) Received: by gxk19 with SMTP id 19so2577080gxk.31 for ; Fri, 10 Jun 2011 09:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MbdXg3p9C/h2osJQ4tZ5oJu3DcM/RSb/b+XQZAlDrW0=; b=p9pGJpQaMJtzoTwWfzhpZ/Go4OT13BEcvvw+Pu9I+wQzA1rgfzpw/NnRBm6y4QOC2+ HfI8zBnIXUunQ4DVO9XrBuYeuzQnlzI+8tCvzfIalQGLkg3YFnkVN9guDV2qP0Kn7KBC d9lFVjarC32Jib8tvf86fv0W6z8MN+vdqYb2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wDv61Dttsr3zGkDIPar/JVKcntOA6H1K0FgPtjakk9uEKyHz8SiInFqIGcXXB1O2ye zwJCtozWu0uPKcAChcbR+c+z7UCBbE36yrlcsxFjI4n2q8SkwOyKIW36N7VYgzZfRZOx csxS1PcAX9I45K5HWevaYBZJbwH1FuP3JUL0Y= MIME-Version: 1.0 Received: by 10.100.56.29 with SMTP id e29mr2049409ana.129.1307724356409; Fri, 10 Jun 2011 09:45:56 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Fri, 10 Jun 2011 09:45:56 -0700 (PDT) In-Reply-To: <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> Date: Fri, 10 Jun 2011 12:45:56 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=001485f860e6ba5ad004a55e4d0f Cc: pkix@ietf.org Subject: Re: [pkix] CAA and relying parties X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 16:46:02 -0000 --001485f860e6ba5ad004a55e4d0f Content-Type: text/plain; charset=ISO-8859-1 CAA was not motivated by the particular circumstances of a single attack that took place after the proposal was submitted. I do have a Dalek but I do not yet have a Tardis. By definition an RA is only responsible for performing validation on behalf of a CA. The intention of CAA was that the check always be performed by the CA. Other parties MAY perform the check in addition. The issue with respect to RPs comes from the fact that the DNS data is public (as is required for CAA to work) and thus there is a risk that someone writes an RP that consumes CAA data even if the spec tells them not to. Since a certificate MAY be valid for several years it is quite possible that a certificate was validly issued by an issuer that is no longer authorized. Rather than try to tell people not to use a spec for a use case it is obviously capable of supporting, I think it better to specify direct support. The only reason for not doing this is political, not technical. In particular some members of the DANE working group think that DANE records should pre-empt PKIX certificate semantics. If people want to change the semantics of PKIX certificates they have to come to the PKIX working group. That is the place where PKIX semantics have been discussed for a decade. I do not accept the argument that the DANE charter gives it any right to redefine PKIX certificate semantics let alone an exclusive right. KEYASSURE was originally proposed as a means to distribute public keys using the DNS as a base. I still think that is a useful application and that is what I think DANE should be doing. On Thu, Jun 9, 2011 at 12:10 PM, Paul Hoffman wrote: > On Jun 8, 2011, at 7:44 PM, Martin Rex wrote: > > > CAA is _not_ for the RP, i.e. not for _you_ (and me, and most others ...) > > It is only another means for a CA to detect attempts to subvert one of > > its RAs, so it's primary purpose is CYA for large commercial CAs. > > That's not what draft-ietf-pkix-caa-00.txt says. Section 2.3 explicitly > covers relying parties using CAA. I believe that section should be removed, > but it is in the current WG document. > > --Paul Hoffman > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Website: http://hallambaker.com/ --001485f860e6ba5ad004a55e4d0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable CAA was not motivated by the particular circumstances of a single attack th= at took place after the proposal was submitted.

I do hav= e a Dalek but I do not yet have a Tardis.


By definition an RA is only responsible for performing validation on b= ehalf of a CA.

The intention of CAA was that the c= heck always be performed by the CA. Other parties MAY perform the check in = addition.

The issue with respect to RPs comes from the fact that = the DNS data is public (as is required for CAA to work) and thus there is a= risk that someone writes an RP that consumes CAA data even if the spec tel= ls them not to. Since a certificate MAY be valid for several years it is qu= ite possible that a certificate was validly issued by an issuer that is no = longer authorized.

Rather than try to tell people not to use a spec for a = use case it is obviously capable of supporting, I think it better to specif= y direct support.


The only reason f= or not doing this is political, not technical. In particular some members o= f the DANE working group think that DANE records should pre-empt PKIX certi= ficate semantics.

If people want to change the semantics of PKIX certific= ates they have to come to the PKIX working group. That is the place where P= KIX semantics have been discussed for a decade.

I do not accept the argument that the DANE charter gives it any right to re= define PKIX certificate semantics let alone an exclusive right.
<= br>

KEYASSURE was originally proposed as a means t= o distribute public keys using the DNS as a base. I still think that is a u= seful application and that is what I think DANE should be doing.



On Thu, Jun 9, 2011 at 12:10 PM, Paul Hoffman <paul.hoffman@vpnc.org> wr= ote:
On Jun 8, 2011, at 7:44 PM, Martin Rex wrot= e:

> CAA is _not_ for the RP, i.e. not for _you_ (and me, and most others .= ..)
> It is only another means for a CA to detect attempts to subvert one of=
> its RAs, so it's primary purpose is CYA for large commercial CAs.<= br>
That's not what draft-ietf-pkix-caa-00.txt says. Section 2.3 explicitly= covers relying parties using CAA. I believe that section should be removed= , but it is in the current WG document.

--Paul Hoffman
_______________________________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix



--
Website: http://hallambaker.com/

--001485f860e6ba5ad004a55e4d0f-- From wwwrun@rfc-editor.org Fri Jun 10 10:27:15 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190D511E80CC; Fri, 10 Jun 2011 10:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.117 X-Spam-Level: X-Spam-Status: No, score=-102.117 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzEB-1d4776G; Fri, 10 Jun 2011 10:27:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8990C11E8077; Fri, 10 Jun 2011 10:27:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7591598C512; Fri, 10 Jun 2011 10:27:13 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110610172713.7591598C512@rfc-editor.org> Date: Fri, 10 Jun 2011 10:27:13 -0700 (PDT) Cc: pkix@ietf.org, rfc-editor@rfc-editor.org Subject: [pkix] RFC 6277 on Online Certificate Status Protocol Algorithm Agility X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 17:27:15 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6277 Title: Online Certificate Status Protocol Algorithm Agility Author: S. Santesson, P. Hallam-Baker Status: Standards Track Stream: IETF Date: June 2011 Mailbox: sts@aaa-sec.com, hallam@gmail.com Pages: 11 Characters: 21682 Updates: RFC2560 I-D Tag: draft-ietf-pkix-ocspagility-10.txt URL: http://www.rfc-editor.org/rfc/rfc6277.txt The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used. This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use. This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. [STANDARDS-TRACK] This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From DPKemp@missi.ncsc.mil Fri Jun 10 11:12:49 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C57C9E8005 for ; Fri, 10 Jun 2011 11:12:49 -0700 (PDT) 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 wU59g2Pux5z3 for ; Fri, 10 Jun 2011 11:12:48 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7DC9E8004 for ; Fri, 10 Jun 2011 11:12:48 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p5AICltu015807 for ; Fri, 10 Jun 2011 14:12:47 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Jun 2011 14:12:42 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 10 Jun 2011 14:12:46 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] CAA and relying parties Thread-Index: AcwnkGzqzcMa6SHCTNSkAhdut9GT4QAAjxtA References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp><01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> From: "Kemp, David P." To: X-OriginalArrivalTime: 10 Jun 2011 18:12:42.0015 (UTC) FILETIME=[FD4E52F0:01CC2799] Subject: Re: [pkix] CAA and relying parties X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 18:12:49 -0000 -----Original Message----- From: Phillip Hallam-Baker > The issue with respect to RPs comes from the fact that > the DNS data is public (as is required for CAA to work) > and thus there is a risk that someone writes an RP that > consumes CAA data even if the spec tells them not to. > Since a certificate MAY be valid for several years it > is quite possible that a certificate was validly issued > by an issuer that is no longer authorized. >=20 > Rather than try to tell people not to use a spec for a > use case it is obviously capable of supporting, I think > it better to specify direct support. There is a difference between RPs using public data that is intended for CAs, and defining additional data explicitly for RP support. I agree with the former - you can't and shouldn't prohibit RPs from using a "trust but verify" approach to flag potential instances of CA non-conformance. However, defining Flag Bit 6 (Relying Party Application Use) goes beyond unintended but tolerated RP use of CA data. The existence of Bit 6 is in direct conflict with a statement that "CAA is _not_ for the RP" (which implied by the penultimate paragraph of section 2: "It is the intention of the authors to propose the CAA record defined in this document as the basis for CA validation requirements ..." and this from section 2.3: "... the Property Entries supported in this version of the specification are only designed to support the requirements of enforcing issuer restrictions." There appear to be 3 possibilities going forward: 1) say that RPs MUST NOT retrieve or act on CAA data, 2) say that RPs MAY act on CAA data at their own risk and discretion, but define no such data specifically for use by RPs, or 3) define RP-specific data (bit 6) and processing rules, with the expectation that future versions of CAA may define additional property entries intended to provide complete coverage of RP requirements. I'm with Paul and Martin, to the extent that they are advocating 2 and not 1. The last paragraph of section 2 (time-of-issue vs. time-of-verification) could be moved to Security Considerations to aid RPs in understanding CAA. Dave From paul.hoffman@vpnc.org Fri Jun 10 11:20:42 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626199E801E for ; Fri, 10 Jun 2011 11:20:42 -0700 (PDT) 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 jeTC-QsKvf+q for ; Fri, 10 Jun 2011 11:20:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5959E800D for ; Fri, 10 Jun 2011 11:20:40 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p5AIKWc3039363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Jun 2011 11:20:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 10 Jun 2011 11:20:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9C5ED9ED-A99A-4E2E-91C1-AB091FC64C14@vpnc.org> References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] CAA and relying parties X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 18:20:42 -0000 On Jun 10, 2011, at 9:45 AM, Phillip Hallam-Baker wrote: > The intention of CAA was that the check always be performed by the CA. Good. > Other parties MAY perform the check in addition. Other parties MAY do whatever they feel like at any time. This is the = Internet. The question is whether this WG wants to nudge-nudge-wink-wink = encourage them to do so by listing this MAY in the WG document. I = propose that the WG does not. > The issue with respect to RPs comes from the fact that the DNS data is = public (as is required for CAA to work) and thus there is a risk that = someone writes an RP that consumes CAA data even if the spec tells them = not to. There has not been, as far as I know, a proposal to tell them not to. = The proposal is to remove the obvious hint that they might want to. > Since a certificate MAY be valid for several years it is quite = possible that a certificate was validly issued by an issuer that is no = longer authorized. Quite true. That is a use case for the DANE WG. > Rather than try to tell people not to use a spec for a use case it is = obviously capable of supporting, I think it better to specify direct = support. Great: tell them that, if they want to communicate with RPs, use DANE. = Or, don't tell them anything and assume that they will use DANE. > The only reason for not doing this is political, not technical. Wrong. The reason not to do this is that you are creating two records = with similar semantics that, if they don't match, can reduce the = security of the host if they have different information in them. > In particular some members of the DANE working group think that DANE = records should pre-empt PKIX certificate semantics. Hogwash. You have said this many times, and when questioned about what = you meant, were not able to describe what "pre-empt PKIX certificate = semantics" means in a way that people could understand. Feel free to try = again, of course. For the record: I know of *no one* in the DANE WG who wants to pre-empt = PKIX certificate semantics. > If people want to change the semantics of PKIX certificates they have = to come to the PKIX working group. That is the place where PKIX = semantics have been discussed for a decade. True (other than the underestimation of time), but irrelevant. > I do not accept the argument that the DANE charter gives it any right = to redefine PKIX certificate semantics let alone an exclusive right. Good! We are all in agreement then. > KEYASSURE was originally proposed as a means to distribute public keys = using the DNS as a base. I still think that is a useful application and = that is what I think DANE should be doing. Great! Why do you think that the PKIX WG should undermine that in the = CAA protocol? Simply removing section 2.3 would make the CAA proposal = much cleaner. --Paul Hoffman P.S. It is difficult to have a conversation about a protocol when you = try to speak for others whom you clearly disagree with (and when those = others, including myself, try to speak for you). In the future, please = try harder to state what you believe while refraining from speaking for = those with whom you disagree. Thanks! From matt@mattmccutchen.net Fri Jun 10 14:37:50 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9C811E817C for ; Fri, 10 Jun 2011 14:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] 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 wAXWGtuql3aB for ; Fri, 10 Jun 2011 14:37:48 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id C533211E8159 for ; Fri, 10 Jun 2011 14:37:48 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id DC7FE70406A; Fri, 10 Jun 2011 14:37:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=nIC2vokmRfRWXZtgy0cVoEUaDUBe3TAnjNLm2T/ntWc Q4GrvLsHGzwZsTslvUScPuD4dX+r9BrJubU9KxrDvxhabrAB8ertE42WfuLDsXU/ kjnsmhvZvXR2FoinJcyg19wCo7bnVXbd3lzzbds652MS4k/wAcxlX8LhcHC2PsNg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=RAE2a7Q+0b6gw89sGRdbNdkaKEE=; b=GnMKYDOu2B a8qLMPXUuB0Ni5dRcey5FPIDIvFoG7oinFgeuIlzmCCjRrafMyuyBgLVuVnVJYtP WO0M303+cS6H8DLjoKS9jVaibst/mR5tACLk36lt9prNp7AJRL6GbdmLc2nnJOOZ uCF6fHy/68ophykFJjUGVkxqU921dEyn4= Received: from [192.168.1.40] (pool-74-96-43-55.washdc.east.verizon.net [74.96.43.55]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id 6A203704063; Fri, 10 Jun 2011 14:37:47 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 10 Jun 2011 17:37:45 -0400 Message-ID: <1307741865.2123.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] CAA and relying parties X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 21:37:50 -0000 On Fri, 2011-06-10 at 12:45 -0400, Phillip Hallam-Baker wrote: > The only reason for not doing this is political, not technical. In > particular some members of the DANE working group think that DANE > records should pre-empt PKIX certificate semantics. > > If people want to change the semantics of PKIX certificates they have > to come to the PKIX working group. That is the place where PKIX > semantics have been discussed for a decade. > > I do not accept the argument that the DANE charter gives it any right > to redefine PKIX certificate semantics let alone an exclusive right. Note carefully the difference between "preempt" and "redefine". DANE does not redefine PKIX semantics in any way. "Preempt" is a loaded word. Objectively, DANE and PKIX (by which I mean, PKIX validation against a trust anchor store + a server ID check) are alternative authentication schemes for TLS services bound to DNS names. Clients may feel that DANE has advantages over PKIX and thus choose to use it rather than PKIX. I do not accept your tacit assumption that the PKIX WG has the exclusive right to specify TLS server authentication schemes for use with the X.509 certificate type. DANE has significant security advantages over PKIX under a set of assumptions that are controversial. OTOH, I have not seen any substantive claim of an advantage of the CAA RP support over DANE. -- Matt From egerck@nma.com Fri Jun 10 15:58:14 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FEF9E801A for ; Fri, 10 Jun 2011 15:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 crysOD7qFdUI for ; Fri, 10 Jun 2011 15:58:13 -0700 (PDT) Received: from nm4-vm0.access.bullet.mail.mud.yahoo.com (nm4-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.138]) by ietfa.amsl.com (Postfix) with SMTP id D0A8A9E8007 for ; Fri, 10 Jun 2011 15:58:13 -0700 (PDT) Received: from [66.94.237.195] by nm4.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Jun 2011 22:58:13 -0000 Received: from [66.94.237.103] by tm6.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Jun 2011 22:58:13 -0000 Received: from [127.0.0.1] by omp1008.access.mail.mud.yahoo.com with NNFMP; 10 Jun 2011 22:58:13 -0000 X-Yahoo-Newman-Id: 391153.67977.bm@omp1008.access.mail.mud.yahoo.com Received: (qmail 95704 invoked from network); 10 Jun 2011 22:58:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307746692; bh=VhhgQEiYsUzdQFo/GEhhrZHFt19kideqZm2tTLgBa08=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lNGfKrP/MG+EUd+pnm5t/D+wPul80y1o5SjXVYR9CMzXNwBn9jv2X8NvS3fvnJMb9gq7M7aEkrEkQHiR0vHesY7O4kRUIJHlwiRViBYHekHoEjEISZccU8epl09WPGW48aR5v9vgcLNqeBfR6wbaQ7j1rViKEsd15rtk7EbiEn0= Received: from [172.16.1.88] (egerck@99.145.106.177 with plain) by smtp109.sbc.mail.bf1.yahoo.com with SMTP; 10 Jun 2011 15:58:12 -0700 PDT X-Yahoo-SMTP: MbPjQnGswBC7yA6NwEFbGJ4iXszffqyyVjqB X-YMail-OSG: xcnzaTkVM1nRp.i7Sk3436awiYRMxlHO.3LoqRI74dVASC2 RWGhINAqHGhP.0EBDxHOa7IJMXbF5ftKpD8OWVSVE0ro0J7APMIO21HlN2mu qcpyrOhuYjDnG0DrrH2zqUOfutwnOcHNFZa7H5LxbPDbA57ML3y6ZBGJnszO lhLsuyTI2nhNQu5_FcQH2xkdHvzLDF68WyLPoK04jtLtABWiTyJpjN97K3Xx vRvDNRMUD3N3e5d18qfhDz.yl9n8zVfBglaJm.GjLhaK867a4Fr_ioYzO75B zyOmB.xu2PjTcuDDBc62aQ34BC8Fe2cy3x3CcU4LC_RLhR7Kj9lGmsYz4G0G k X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DF2A183.8040809@nma.com> Date: Fri, 10 Jun 2011 15:58:11 -0700 From: "Ed Gerck, Ph.D." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: pkix@ietf.org References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> <1307741865.2123.14.camel@localhost> In-Reply-To: <1307741865.2123.14.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] CAA and relying parties X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 22:58:14 -0000 On 6/10/2011 2:37 PM, Matt McCutchen wrote: > DANE > does not redefine PKIX semantics in any way. Hello Matt and all, Not that this is by itself bad (more why it is not desirable, below) but, Yes, DANE redefines the PKIX semantics Why? DANE defines a different way (ie, different meaning, different semantics) to authenticate the association of the server's certificate with the intended domain name, and is done without trusting an external CA. [1] > DANE has significant security advantages over PKIX under a set of > assumptions that are controversial. Intuitively, as more witnesses are considered, it becomes less likely that all witnesses can be compromised at the same time. More Witnesses = Better Evidence. [2] DANE reduces the number of witnesses over what is needed with PKIX, hence it can be more easily compromised. Hence, it is not desirable. In other words, exactly because the same DNS administrator for a domain name is authorized under DANE to *both* give identifying information about the zone and make an authoritative binding between the domain name and a certificate, it should be less trustworthy. Trust cannot be earned by self-assertions [2]. > OTOH, I have not seen any > substantive claim of an advantage of the CAA RP support over DANE. As above. Cheers, Ed Gerck [1] draft-ietf-dane-protocol-07. [2] The idea that multiple correction channels can be used to offset errors caused by fraud was already known some 500 years ago in the context of combating corruption in India, in the Mogul period. The same idea can be proved formally using Shannon's Information Theory. Google: Gerck Mogul From matt@mattmccutchen.net Fri Jun 10 17:19:22 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DFC11E807A; Fri, 10 Jun 2011 17:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599] 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 vpB3rM3DT5t3; Fri, 10 Jun 2011 17:19:22 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 00E299E8007; Fri, 10 Jun 2011 17:19:21 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 78B88704063; Fri, 10 Jun 2011 17:19:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Mdtgxh8WgcVW8s8RGhaEQpXKduoX5jQAV7ON9JVyNRe VsVNgDS3cQuQ/P0nF2hwbVO97g8yn1j4TFpvPpVl7dPOsoaGtwEYtW4gYYGTqHK/ Gt5OD1geo6SVKE6TxLUIu6cowrPPGMFMg9K/mMeFl8ieiSuuIE2C1B4cDoI2K31M = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=/krSHyP6rvUCq9pQaKxGRJd3iNw=; b=X2r1aPXi40 4hHCwOpyGstoThGjHAaG3Lq3Am6UicdhwUru66sGUhNi1hrigeZL0Y3MUyywgB45 ivHd7VL7cLDDGN0SmrmiAhImEMsDmgYNrzLoun3Gvzdxo89k8vVAe5GxWofEHmw/ ihghpDkT0loAEBgTpIgu25PKeggIOroxU= Received: from [192.168.1.40] (pool-74-96-43-55.washdc.east.verizon.net [74.96.43.55]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id E9195704014; Fri, 10 Jun 2011 17:19:20 -0700 (PDT) From: Matt McCutchen To: "Ed Gerck, Ph.D." In-Reply-To: <4DF2A183.8040809@nma.com> References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> <1307741865.2123.14.camel@localhost> <4DF2A183.8040809@nma.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 10 Jun 2011 20:19:19 -0400 Message-ID: <1307751559.2095.21.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org, dane Subject: [pkix] TLS server authentication schemes... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 00:19:22 -0000 On Fri, 2011-06-10 at 15:58 -0700, Ed Gerck, Ph.D. wrote: > On 6/10/2011 2:37 PM, Matt McCutchen wrote: > > DANE > > does not redefine PKIX semantics in any way. > > Yes, > DANE redefines the PKIX semantics > > Why? > > DANE defines a different way (ie, different meaning, different semantics) > to authenticate the association of the server's certificate with the intended > domain name, and is done without trusting an external CA. [1] The first statement does not follow from the second. PKIX is still what it is; DANE is merely an alternative. The claim that DANE "redefines" PKIX seems to be a deduction from the faulty premise that PKIX is the only possible method of TLS server authentication, and thus the only way to do differently is to change PKIX. > > DANE has significant security advantages over PKIX under a set of > > assumptions that are controversial. > > Intuitively, as more witnesses are considered, it becomes less likely that all > witnesses > can be compromised at the same time. More Witnesses = Better Evidence. [2] > > DANE reduces the number of witnesses over what is needed with PKIX, hence it > can be more easily compromised. Hence, it is not desirable. > > In other words, exactly because the same DNS administrator for a domain name is > authorized under DANE to *both* give identifying information about the zone and > make an authoritative binding between the domain name and a certificate, it should > be less trustworthy. Trust cannot be earned by self-assertions [2]. This debate has gone around and around on the DANE list, and it is not productive because the two sides argue from different assumptions that they are unwilling or unable (for lack of data) to reconcile. Suffice it to say that a number of people wish to use DANE, so we are proceeding with the standardization. > > OTOH, I have not seen any > > substantive claim of an advantage of the CAA RP support over DANE. > > As above. I do not understand what you mean. Please spell it out. -- Matt From egerck@nma.com Fri Jun 10 18:30:55 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5372A11E80D5 for ; Fri, 10 Jun 2011 18:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] 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 ExoIegOkeNKB for ; Fri, 10 Jun 2011 18:30:54 -0700 (PDT) Received: from nm29.access.bullet.mail.mud.yahoo.com (nm29.access.bullet.mail.mud.yahoo.com [66.94.237.94]) by ietfa.amsl.com (Postfix) with SMTP id 9824C11E80BE for ; Fri, 10 Jun 2011 18:30:54 -0700 (PDT) Received: from [66.94.237.193] by nm29.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2011 01:30:54 -0000 Received: from [66.94.237.104] by tm4.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2011 01:30:54 -0000 Received: from [127.0.0.1] by omp1009.access.mail.mud.yahoo.com with NNFMP; 11 Jun 2011 01:30:54 -0000 X-Yahoo-Newman-Id: 280581.27536.bm@omp1009.access.mail.mud.yahoo.com Received: (qmail 54198 invoked from network); 11 Jun 2011 01:30:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307755854; bh=Vw7lCboD2NRaogwCwSObHleifCXuxTdNZma1QtYqrm0=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=NGPlhA857zPP3sCcKO6W9cXK1w65JJx0GU12jAhvqRPZ1PhmQLKt4ap9W4GdCkLh+Rmb/SWXbjiO+5J56WkAqVdt+DdMknJdmZ+mh7aE9sO8YT+o4L9h3bG5HLYu0cpQXrmJ/TbPpnOaV6fimEebq4FpiLdR+HO2m4USoI3vggo= Received: from [172.16.1.88] (egerck@99.145.106.177 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 10 Jun 2011 18:30:53 -0700 PDT X-Yahoo-SMTP: MbPjQnGswBC7yA6NwEFbGJ4iXszffqyyVjqB X-YMail-OSG: bg4r_QUVM1nnV1S9b4SiHA.xglE2gnPFgal9FUHnGhW7LWd 8t48L8INtDdaS7bJqHRjSOvzzJ_vrKFmx4upwLxPENkQPIwr5DyfJpUBPA5d 0LC9YqGIHe_oqYhFYMPIMg9FvLd3exo_kqPWFGEa3My4c4XRFfZUK3gQTBk5 8K.2W4VogkJFUL.yly.cfmIxmsDuYX6W4ddWn6Ey9DQ70TyljlrJwW0Qm2zI UX_usWInhLYtLXjW_56DUlCggVOv7IRG7Uw8uwMRk7a3k6DGHBlAr5gDgvQY hrFvCCYWL95r_PVPgGzan_2GF9rkfbMWU2rpKdoVeAEWEEhl2 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DF2C54C.4060706@nma.com> Date: Fri, 10 Jun 2011 18:30:52 -0700 From: "Ed Gerck, Ph.D." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Matt McCutchen References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> <1307741865.2123.14.camel@localhost> <4DF2A183.8040809@nma.com> <1307751559.2095.21.camel@localhost> In-Reply-To: <1307751559.2095.21.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org, dane Subject: Re: [pkix] TLS server authentication schemes... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 01:30:55 -0000 On 6/10/2011 5:19 PM, Matt McCutchen wrote: > On Fri, 2011-06-10 at 15:58 -0700, Ed Gerck, Ph.D. wrote: >> Yes, DANE redefines the PKIX semantics >> Why? >> >> DANE defines a different way (ie, different meaning, different semantics) >> to authenticate the association of the server's certificate with the intended >> domain name, and is done without trusting an external CA. [1] > The first statement does not follow from the second. PKIX is still what > it is; DANE is merely an alternative. The claim that DANE "redefines" > PKIX seems to be a deduction from the faulty premise that PKIX is the > only possible method of TLS server authentication, and thus the only way > to do differently is to change PKIX. The first statement makes no claim on an authoritative source. The fact that folks can *redefine* the semantics of English so that "cool" means "hot" does not mean that English is authoritatively changed. In this case, because DANE changes what it means to "authenticate the server certificate" (which has so far been defined by PKIX semantics), DANE is indeed *redefining* the meaning (semantics) that people assign to that sentence. We now have two angles to understand the sentence "authenticate the server certificate" . The DANE and the PKIX angles. Now, while this may add some degree of confusion (which angle is the browser using?), I do not say that this is bad or "impossible". What I say is not that this is by itself bad but that it is not desirable, and I explained why below. >>> DANE has significant security advantages over PKIX under a set of >>> assumptions that are controversial. >> Intuitively, as more witnesses are considered, it becomes less likely that all >> witnesses >> can be compromised at the same time. More Witnesses = Better Evidence. [2] >> >> DANE reduces the number of witnesses over what is needed with PKIX, hence it >> can be more easily compromised. Hence, it is not desirable. >> >> In other words, exactly because the same DNS administrator for a domain name is >> authorized under DANE to *both* give identifying information about the zone and >> make an authoritative binding between the domain name and a certificate, it should >> be less trustworthy. Trust cannot be earned by self-assertions [2]. > This debate has gone around and around on the DANE list, and it is not > productive because the two sides argue from different assumptions that > they are unwilling or unable (for lack of data) to reconcile. Suffice > it to say that a number of people wish to use DANE, so we are proceeding > with the standardization. My argument did not hinge on popularity. A number of people may wish to use what is more likely to fail for a number of reasons, including cost. My argument was that security-wise DANE is less trustworthy and I explained why using intuitive, historical, and formal arguments. It's not just a theory or an anecdote. >>> OTOH, I have not seen any >>> substantive claim of an advantage of the CAA RP support over DANE. >> As above. > I do not understand what you mean. Please spell it out. > Security-wise, DANE is less trustworthy. Thank you for your comments. Cheers, Ed Gerck From mrex@sap.com Fri Jun 10 19:12:09 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952AE11E8095 for ; Fri, 10 Jun 2011 19:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.451 X-Spam-Level: X-Spam-Status: No, score=-9.451 tagged_above=-999 required=5 tests=[AWL=0.798, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 6XnVx1kFjfky for ; Fri, 10 Jun 2011 19:12:09 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id AA6E011E8091 for ; Fri, 10 Jun 2011 19:12:08 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p5B2C6kN026850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Jun 2011 04:12:06 +0200 (MEST) From: Martin Rex Message-Id: <201106110212.p5B2C5Fs011627@fs4113.wdf.sap.corp> To: DPKemp@missi.ncsc.mil (Kemp David P.) Date: Sat, 11 Jun 2011 04:12:05 +0200 (MEST) In-Reply-To: from "Kemp, David P." at Jun 10, 11 02:12:46 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] CAA and relying parties X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 02:12:09 -0000 Kemp, David P. wrote: > > There appear to be 3 possibilities going forward: > > 1) say that RPs MUST NOT retrieve or act on CAA data, > 2) say that RPs MAY act on CAA data at their own risk and discretion, > but define no such data specifically for use by RPs, or > 3) define RP-specific data (bit 6) and processing rules, with the > expectation that future versions of CAA may define additional property > entries intended to provide complete coverage of RP requirements. > > I'm with Paul and Martin, to the extent that they are advocating 2 and > not 1. The last paragraph of section 2 (time-of-issue vs. > time-of-verification) could be moved to Security Considerations to aid > RPs in understanding CAA. I'm actually in favour of (1). There should be as few "mays" as possible in security specs that can result in interop/communication failures, because sorting out why product a works and product b fails is extremely painful for everyone that is affected, or involved in attempts of finding and fixing the problem. CAA ought to be for CAs _only_, and RP should look only at DANE. And personally, I believe that DANE is only useful when DNSSEC protected. -Martin From hallam@gmail.com Fri Jun 10 19:29:29 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A672311E80AA for ; Fri, 10 Jun 2011 19:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 waT-OxxFUpmI for ; Fri, 10 Jun 2011 19:29:28 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 951CF11E8074 for ; Fri, 10 Jun 2011 19:29:28 -0700 (PDT) Received: by yxs7 with SMTP id 7so525649yxs.31 for ; Fri, 10 Jun 2011 19:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hJ6mYkQzfoeLee6v4rD20xlP1T9c1bpnOqYxkFhtNRM=; b=e++mSd1Cs/hy82HQk5e1VK4323wU5/aO+ZA0C6vzF3dZCHs2HKrFd2+swz1uvX5ELG STHjARtC6VErpW0hxAboJTSVYmr72nY/74d9QNstvTlt2S1Zjecjp9v4dsedCihouwyp TeTuzwYAiZ0BbHOt+/rZKmzT1ers0pKrsB1QY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NhVXYy/OEQWYFc0NUJCV8chqw8zcrh24gHbxVxy/WI70nT5FaVVpy3b2Plsu8BBPVZ LbqfHJjAqXbogDYy90Kyjpwcs3uJ2jzmLpvLnyr2hGOTm1KvAanP6lBOrgOFW9RnPlr0 0SSNZ8cL22Uzoy4viywIW4WPlKbGJcRDu7F9c= MIME-Version: 1.0 Received: by 10.101.200.1 with SMTP id c1mr2605095anq.63.1307759367052; Fri, 10 Jun 2011 19:29:27 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Fri, 10 Jun 2011 19:29:27 -0700 (PDT) In-Reply-To: References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> Date: Fri, 10 Jun 2011 22:29:27 -0400 Message-ID: From: Phillip Hallam-Baker To: "Kemp, David P." Content-Type: multipart/alternative; boundary=0016e68deca8865ead04a566743f Cc: pkix@ietf.org Subject: Re: [pkix] CAA and relying parties X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 02:29:29 -0000 --0016e68deca8865ead04a566743f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 10, 2011 at 2:12 PM, Kemp, David P. wrote: > > However, defining Flag Bit 6 (Relying Party Application Use) goes beyond > unintended but tolerated RP use of CA data. The existence of Bit 6 is > in direct conflict with a statement that "CAA is _not_ for the RP" > (which implied by the penultimate paragraph of section 2: > > "It is the intention of the authors to propose the > CAA record defined in this document as the basis for > CA validation requirements ..." > No it is not. My intention to build a dalek for my office in no way excludes the possibility of an Enterprise TOS Command Chair. The statement above is not exclusive. > and this from section 2.3: > > "... the Property Entries supported in this version > of the specification are only designed to support the > requirements of enforcing issuer restrictions." > RP restrictions is a much harder problem because the client has much less information available and the consequences of a false positive are much worse. In the issuer case the cost of a false positive is that the request ends up in exceptions processing. There is going to be a human looking at the issue and talking to the requester. If they are legit then the DNS record can be fixed. I am very skeptical of the likelihood that the browser providers are going to hard fail on CAA information or DANE information when they still refuse to hardfail on lack of revocation status. > There appear to be 3 possibilities going forward: > > 1) say that RPs MUST NOT retrieve or act on CAA data, > 2) say that RPs MAY act on CAA data at their own risk and discretion, > but define no such data specifically for use by RPs, or > 3) define RP-specific data (bit 6) and processing rules, with the > expectation that future versions of CAA may define additional property > entries intended to provide complete coverage of RP requirements. > > I'm with Paul and Martin, to the extent that they are advocating 2 and > not 1. The last paragraph of section 2 (time-of-issue vs. > time-of-verification) could be moved to Security Considerations to aid > RPs in understanding CAA. > Possibility 4 is keep the draft as it is with maybe a more explicit health warning. The information in bit 6 is still necessary to enable CAs to be able to check up on the state of CAA compliance at other CAs. Whatever people think about the ability of CAs to do their jobs properly I am sure that our marketing departments will do an exceptional job of pointing out when competitors fail to do so. Ergo my expectation is that the observed non-compliance of CAA records will be low and there should hopefully be little leverage in RP checking in any case. -- Website: http://hallambaker.com/ --0016e68deca8865ead04a566743f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 10, 2011 at 2:12 PM, Kemp, David P. <DPKemp@missi.ncsc.mil> wr= ote:

However, defining Flag Bit 6 (Relying Party Application Use) goes beyond unintended but tolerated RP use of CA data. =A0The existence of Bit 6 is in direct conflict with a statement that "CAA is _not_ for the RP"= ;
(which implied by the penultimate paragraph of section 2:

=A0 =A0"It is the intention of the authors to propose the
=A0 =A0 CAA record defined in this document as the basis for
=A0 =A0 CA validation requirements ..."

No it is not.

My intention to build a dalek= for my office in no way excludes the possibility of an Enterprise TOS Comm= and Chair.

The statement above is not exclusive.=A0

=

=A0
and this from section 2.3:

=A0 "... the Property Entries supported in this version
=A0 =A0of the specification are only designed to support the
=A0 =A0requirements of enforcing issuer restrictions."

RP restrictions is a much harder problem because the = client has much less information available and the consequences of a false = positive are much worse.

In the issuer case the cost of a false positive is that= the request ends up in exceptions processing. There is going to be a human= looking at the issue and talking to the requester. If they are legit then = the DNS record can be fixed.

I am very skeptical of the likelihood that the browser = providers are going to hard fail on CAA information or DANE information whe= n they still refuse to hardfail on lack of revocation status.

=A0
There appear to be 3 possibilities going forward:

1) say that RPs MUST NOT retrieve or act on CAA data,
2) say that RPs MAY act on CAA data at their own risk and discretion,
but define no such data specifically for use by RPs, or
3) define RP-specific data (bit 6) and processing rules, with the
expectation that future versions of CAA may define additional property
entries intended to provide complete coverage of RP requirements.

I'm with Paul and Martin, to the extent that they are advocating 2 and<= br> not 1. =A0The last paragraph of section 2 (time-of-issue vs.
time-of-verification) could be moved to Security Considerations to aid
RPs in understanding CAA.

Possibility 4= is keep the draft as it is with maybe a more explicit health warning.

The information in bit 6 is still necessary to enable = CAs to be able to check up on the state of CAA compliance at other CAs.

Whatever people think about the ability of CAs to do th= eir jobs properly I am sure that our marketing departments will do an excep= tional job of pointing out when competitors fail to do so.

Ergo my expectation is that the observed non-compliance of CAA r= ecords will be low and there should hopefully be little leverage in RP chec= king in any case.



--
Website: http://hallambaker.com/=

--0016e68deca8865ead04a566743f-- From mrex@sap.com Fri Jun 10 21:29:59 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FF111E8073 for ; Fri, 10 Jun 2011 21:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.539 X-Spam-Level: X-Spam-Status: No, score=-9.539 tagged_above=-999 required=5 tests=[AWL=0.710, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 FQ7IvFiYOt1l for ; Fri, 10 Jun 2011 21:29:59 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 903929E8011 for ; Fri, 10 Jun 2011 21:29:58 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p5B4Tv3u010540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 11 Jun 2011 06:29:57 +0200 (MEST) From: Martin Rex Message-Id: <201106110429.p5B4TuoF019430@fs4113.wdf.sap.corp> Orig-To: egerck@nma.com (Ed Gerck Ph.D.) To: pkix@ietf.org Cc: pkix@ietf.org Date: Sat, 11 Jun 2011 04:53:05 +0200 (MEST) In-Reply-To: <4DF2C54C.4060706@nma.com> from "Ed Gerck, Ph.D." at Jun 10, 11 06:30:52 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: mrex@sap.com X-SAP: out Subject: Re: [pkix] TLS server authentication schemes... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 04:29:59 -0000 Ed Gerck wrote: > > In this case, because DANE changes what it means to > "authenticate the server certificate" (which has so far been defined > by PKIX semantics), DANE is indeed *redefining* the meaning (semantics) > that people assign to that sentence. We now have two angles to > understand the sentence "authenticate the server certificate" . > The DANE and the PKIX angles. I'm sorry, but that information is significantly inaccurate. PKIX defines pretty close to nothing what it means to authenticate the server certificate, besides indicating that a TLS server cert MAY contain a specific ExtendedKeyUsage, and certificate path validation in general (in case there is a path at all) and entirely independent from the semantic meaning of the certificates attributes. What it means to authenticate a TLS Server certificate was loosely defined by rfc2818 (HTTP over TLS, Informational) describing the most common behaviour of the installed base, and its inofficial successor (rfc6125, [tltt], Proposed). Concerning the trustworthiness, DANE can be anyhing you like. It can provide a level of trust that are significantly higher than TLS X.509 PKI alone, by locking down (not completely overriding) PKIX trust anchors. You may not like it, but X.509 certs suffer from the birth defect that they can bear only a single signature, so in PKIX there is always just one single party asserting an identity. Effectively PKIX is hardwired to self-assertion. While doing a certificate path validation, the PKI software may be processing a transitional chain of claims of the kind "oh yes, I assert this party is authorized to make such an assertion", but there NEVER is any independent confirmation that this assertion is correct. In particular, the entity named by an assertion made by any CA is unable to independently confirm or deny that this assertion is valid if you're limited to PKIX. And this is where DANE comes in for rescue. Google, Yahoo and whoever else was a victim of Commodo-gate has been (or would have been) completely unable to deny the claim made by Commodo. Only Commodo was able to do something to make that claim less dangerous (revoke the cert), but ultimately all of the browser vendors had to issue software patches to ensure that the incorrect Commodo assertions of identity were really made invalid. CAA is Commodos approach to make it less likely that something like this happens again. DANE is hopefully going to be the IETF tool to empower the server and/or domain admin to ensure that any such false claims independent of how they emerged (fraudulent,accidental or by governmental coercion), never ever considered trustworthy in the first place. Revocation and software patches are slow and will affect only a fraction of the internet users, and that problem will _NEVER_ get better. With DANE, while it has the prerequisite of intial deployment to reach anyone at all, once that is done, the distribution will always and constantly get better. -Martin From egerck@nma.com Sat Jun 11 01:01:18 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F53721F8469 for ; Sat, 11 Jun 2011 01:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_20=-0.74] 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 SVKiYWTbKxBp for ; Sat, 11 Jun 2011 01:01:17 -0700 (PDT) Received: from nm5.access.bullet.mail.mud.yahoo.com (nm5.access.bullet.mail.mud.yahoo.com [66.94.237.206]) by ietfa.amsl.com (Postfix) with SMTP id 8CD3F21F8467 for ; Sat, 11 Jun 2011 01:01:17 -0700 (PDT) Received: from [66.94.237.127] by nm5.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2011 08:01:17 -0000 Received: from [66.94.237.98] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2011 08:01:17 -0000 Received: from [127.0.0.1] by omp1003.access.mail.mud.yahoo.com with NNFMP; 11 Jun 2011 08:01:17 -0000 X-Yahoo-Newman-Id: 219866.34036.bm@omp1003.access.mail.mud.yahoo.com Received: (qmail 53879 invoked from network); 11 Jun 2011 08:01:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307779276; bh=ieJRHQhDdTWPkbQRiFVw+cSLZ/j48Ahxp0W7aykeVQs=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=S3fK7Ho6ai2GlZpEtryt4AKd2tBELBUdqF9KuW9RNISSKNxJv1CmDHk95xrGE6HnnWz4HdXlF41eKAL7c1mc/GI93elpdKLioMWW48gcHYN0KOhG+pf4KbiNjO7MVcILW92LEVFANupYUFTsUl3lnz8uRiKlqWbacyc4Go6uLhs= Received: from [172.16.1.88] (egerck@99.145.106.177 with plain) by smtp104.sbc.mail.bf1.yahoo.com with SMTP; 11 Jun 2011 01:01:16 -0700 PDT X-Yahoo-SMTP: MbPjQnGswBC7yA6NwEFbGJ4iXszffqyyVjqB X-YMail-OSG: Mm6fwCQVM1lcKnNJjJLajQIxq6IJOfdPUg0J3ALnKE.iYZO bEpFDe2DGDK9p4CiC61.6s5Uzr22HzrL0ErxgT0.GQ8E7la9yrZcMpEVYkTc F._LowGM6zxnmt9o3I8ziIrFHpSxBvHOrjIB5RscSVVKZTiHJ2SOSxbaK8h. HsgnGiZ895oj8BxQ8CgaoY0NTquguKsXmhVgGfzxYu2sCsFG1HkXb_yh7RfO 2kfvc5RJBgfbhE_VjShwRxkPg4KKnylviQ0rftPi4z3La3I.trlkzhJDBgOW nAoyFruH.c8Q1vmkFompMRJTpOa6F7HpPucgC1wKYvXV9Tel_6dUSvgUXHzC fUJoqF4pTNDFgH98ruiZJaIAu1s.7IKlWlpPH X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DF320CA.5070501@nma.com> Date: Sat, 11 Jun 2011 01:01:14 -0700 From: "Ed Gerck, Ph.D." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: pkix@ietf.org References: <201106110429.p5B4TuoF019430@fs4113.wdf.sap.corp> In-Reply-To: <201106110429.p5B4TuoF019430@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] TLS server authentication schemes... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 08:01:18 -0000 Hello Martin and Matt, In your reading, is any sentence below NOT to be understood from draft-ietf-dane-protocol-07? 1. DANE is about a new meaning to the sentence "authenticate the server certificate". 2. This new meaning differs from the semantics of PKIX. 3. The DANE proposal is to overload issuance (giving identifying information about the zone) with validation (making an authoritative binding between the domain name and a certificate), and do so through the same party (the DNS administrator for a domain name). Cheers, Ed Gerck From ynir@checkpoint.com Sat Jun 11 05:53:35 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D72811E80AA for ; Sat, 11 Jun 2011 05:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.178 X-Spam-Level: X-Spam-Status: No, score=-10.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 trNlwv0PzYts for ; Sat, 11 Jun 2011 05:53:34 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E464C11E80A7 for ; Sat, 11 Jun 2011 05:53:33 -0700 (PDT) X-CheckPoint: {4DF37348-2-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p5BCrSvs032255; Sat, 11 Jun 2011 15:53:28 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 11 Jun 2011 15:53:28 +0300 From: Yoav Nir To: Phillip Hallam-Baker Date: Sat, 11 Jun 2011 15:53:28 +0300 Thread-Topic: [pkix] CAA and relying parties Thread-Index: AcwoNo8CJbY3yIX7QByPrs/96kM/8A== Message-ID: <1A03F7F8-1225-4E88-80D8-CCEE0CC31F08@checkpoint.com> References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , Paul Hoffman Subject: Re: [pkix] CAA and relying parties X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 12:53:35 -0000 On Jun 10, 2011, at 7:45 PM, Phillip Hallam-Baker wrote: > CAA was not motivated by the particular circumstances of a single attack = that took place after the proposal was submitted. >=20 > I do have a Dalek but I do not yet have a Tardis. >=20 >=20 > By definition an RA is only responsible for performing validation on beha= lf of a CA. >=20 > The intention of CAA was that the check always be performed by the CA. Ot= her parties MAY perform the check in addition. >=20 > The issue with respect to RPs comes from the fact that the DNS data is pu= blic (as is required for CAA to work) and thus there is a risk that someone= writes an RP that consumes CAA data even if the spec tells them not to. Si= nce a certificate MAY be valid for several years it is quite possible that = a certificate was validly issued by an issuer that is no longer authorized. >=20 > Rather than try to tell people not to use a spec for a use case it is obv= iously capable of supporting, I think it better to specify direct support. >=20 >=20 > The only reason for not doing this is political, not technical. In partic= ular some members of the DANE working group think that DANE records should = pre-empt PKIX certificate semantics. I can think of a technical reason. Some people have mentioned in previous t= hreads that there should be a "zero record" that says that no CA should iss= ue a certificate. If I get a new certificate once a year, a possible practi= ce would be to have the zero record for my domain all year, and replace it = with one for a single CA just before the time to renew a certificate.=20 There is no way for an RP to know if my policy is to keep a CAA record for = my favorite CA all the time, or to change it frequently. This is different = from a DANE record that is intended for the RPs. More generally, a CAA record is related to my next certificate, whereas a D= ANE record is about my current certificate. So unless we actually want the= CAA record to be used by RPs, we should not specify it. Even better, the s= pec should warn RPs against using it. Yoav From hallam@gmail.com Sat Jun 11 06:55:43 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138B111E80AE for ; Sat, 11 Jun 2011 06:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uFfv5rHFhnXZ for ; Sat, 11 Jun 2011 06:55:41 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 73D4911E80AC for ; Sat, 11 Jun 2011 06:55:41 -0700 (PDT) Received: by yie30 with SMTP id 30so250765yie.31 for ; Sat, 11 Jun 2011 06:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a744lBYX/OrC/PqyOMR2vvDtYw3HXgsDQqo5RkMvH10=; b=AOk4znvbxqB2sKHGW1gmZyEBS7RLoBIoIu1h4J2Ac+TeuE1CYpluUiqoh4tBXS/ERv q8Yn+/GI0ZCD48Vbkh9kCyiGJIW5u8Z7ZiT9qY5mE+Rq/NbJXFHWaAqrg05h+9BODhGb WhWDITyNKCNTyMWWmgUMf2bbKUr+fQmZEOAY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=a2l1V48VpS0utlFJy3S8/gaSqS2dlDx+/3I4WKyQwEoqZ3WHSf6YW2B2Ljtsfw5+IM YTZ7AhpEmba4FqGwV0WAMC3ihCse0/YXGY63uMUxOKFbJ5m+PysWnC23tpXEV1x2zTfy YJBPB1qdFEg4/ktRKNwh/TzlAj33oVjMKJ07Q= MIME-Version: 1.0 Received: by 10.101.12.10 with SMTP id p10mr547667ani.107.1307800540796; Sat, 11 Jun 2011 06:55:40 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Sat, 11 Jun 2011 06:55:40 -0700 (PDT) In-Reply-To: <201106110429.p5B4TuoF019430@fs4113.wdf.sap.corp> References: <4DF2C54C.4060706@nma.com> <201106110429.p5B4TuoF019430@fs4113.wdf.sap.corp> Date: Sat, 11 Jun 2011 09:55:40 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0050450176c7abd89404a5700a60 Cc: pkix@ietf.org Subject: Re: [pkix] TLS server authentication schemes... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 13:55:43 -0000 --0050450176c7abd89404a5700a60 Content-Type: text/plain; charset=ISO-8859-1 Again you are engaging in invective and insult. Using the -gate suffix is a tabloid journalism tactic. Would you like me to write up a blog article on SAPGate the next time your employer has a security issue? Pejorative personal attacks and attacks against our employers are not permitted. Again, I do not have a time machine. CAA is not a response to an incident that occurred after the spec was written. The window of vulnerability for any browser that actually implemented the existing PKIX specs correctly was less than half an hour. If you understand the reason why browsers do not implement hardfail on OCSP you will understand why there is little chance of restriction semantics being implemented hardfail. The argument you and Paul seem to be advancing is: 1) PKIX must not intrude on what you define as DANE 'turf' 2) DANE can do any sweet thing it likes on PKIX turf including rewrite the certificate path validation mechanism. 3) The IETF must not allow anyone to propose an alternative mechanism to solve the issues you have identified. 4) The market should be allowed to decide whether your proposal is accepted. I see some inconsistencies there. I also see numerous inconsistencies in Pauls complains about who is speaking for whom. But I have long since ignored those The DANE charter specifies the following: "The solutions specified by this working group rely upon the security of the DNS to provide source authentication for public keys." The charter allows DANE to PROVIDE source authentication of keys. Nowhere does the charter state that DANE is going to make statements about certificates. Now it is possible to read the charter scope more broadly to include statements about certs and that is quite usual. But if you or Paul had wanted DANE to have exclusive rights in that respect then you should have come clean when the group was chartered and actually told the rest of the IETF that that is what you wanted. https://datatracker.ietf.org/wg/dane/charter/ Reading the charter gives me no idea that the WG is going to do anything other than specify a new key distribution mechanism that has no effect on any other part of the infrastructure. Yes, I know that I knew thats what you were up to, but you didn't want to tell anyone else. If the WG wants to have exclusive rights in this respect it is going to have to recharter in my view. I don't think that is likely to happen. I think it more likely that an applicability statement would prohibit DANE from redefining PKIX semantics or defining additional path validation criteria. If you want to have the prestige and influence of the IETF behind your proposal you have to play by their rules. On Fri, Jun 10, 2011 at 10:53 PM, Martin Rex wrote: > Ed Gerck wrote: > > > > In this case, because DANE changes what it means to > > "authenticate the server certificate" (which has so far been defined > > by PKIX semantics), DANE is indeed *redefining* the meaning (semantics) > > that people assign to that sentence. We now have two angles to > > understand the sentence "authenticate the server certificate" . > > The DANE and the PKIX angles. > > I'm sorry, but that information is significantly inaccurate. > > PKIX defines pretty close to nothing what it means to authenticate > the server certificate, besides indicating that a TLS server cert > MAY contain a specific ExtendedKeyUsage, and certificate path > validation in general (in case there is a path at all) and > entirely independent from the semantic meaning of the certificates > attributes. > > What it means to authenticate a TLS Server certificate was loosely > defined by rfc2818 (HTTP over TLS, Informational) describing the > most common behaviour of the installed base, and its inofficial > successor (rfc6125, [tltt], Proposed). > > > Concerning the trustworthiness, DANE can be anyhing you like. > It can provide a level of trust that are significantly higher > than TLS X.509 PKI alone, by locking down (not completely overriding) > PKIX trust anchors. > > You may not like it, but X.509 certs suffer from the birth defect > that they can bear only a single signature, so in PKIX there is > always just one single party asserting an identity. Effectively > PKIX is hardwired to self-assertion. > > While doing a certificate path validation, the PKI software may > be processing a transitional chain of claims of the kind > "oh yes, I assert this party is authorized to make such an assertion", > but there NEVER is any independent confirmation that this assertion > is correct. In particular, the entity named by an assertion made > by any CA is unable to independently confirm or deny that this > assertion is valid if you're limited to PKIX. And this is where > DANE comes in for rescue. > > Google, Yahoo and whoever else was a victim of Commodo-gate > has been (or would have been) completely unable to deny the > claim made by Commodo. Only Commodo was able to do something > to make that claim less dangerous (revoke the cert), but ultimately > all of the browser vendors had to issue software patches to ensure > that the incorrect Commodo assertions of identity were really > made invalid. > > > CAA is Commodos approach to make it less likely that something > like this happens again. > > DANE is hopefully going to be the IETF tool to empower the > server and/or domain admin to ensure that any such false claims > independent of how they emerged (fraudulent,accidental > or by governmental coercion), never ever considered trustworthy > in the first place. Revocation and software patches are slow > and will affect only a fraction of the internet users, and that > problem will _NEVER_ get better. > > With DANE, while it has the prerequisite of intial deployment > to reach anyone at all, once that is done, the distribution > will always and constantly get better. > > > > -Martin > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Website: http://hallambaker.com/ --0050450176c7abd89404a5700a60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Again you are engaging in invective and insult. Using the -gate suffix is a= tabloid journalism tactic.

Would you like me to write u= p a blog article on SAPGate the next time your employer has a security issu= e?

Pejorative personal attacks and attacks against our emp= loyers are not permitted.


Again, I = do not have a time machine. CAA is not a response to an incident that occur= red after the spec was written.

The window of vulnerability for any browser that actual= ly implemented the existing PKIX specs correctly was less than half an hour= .

If you understand the reason why browsers do not= implement hardfail on OCSP you will understand why there is little chance = of restriction semantics being implemented hardfail.


The argument you and Paul seem to be adv= ancing is:=A0

1) PKIX must not intrude on what you= define as DANE 'turf'

2) DANE can do any = sweet thing it likes on PKIX turf including rewrite the certificate path va= lidation mechanism.

3) The IETF must not allow anyone to propose an alterna= tive mechanism to solve the issues you have identified.

4) The market should be allowed to decide whether your proposal is ac= cepted.

I see some inconsistencies there. I also see numerous i= nconsistencies in Pauls complains about who is speaking for whom. But I hav= e long since ignored those


The DANE= charter specifies the following:

"The solutions specified by this working group rely upon the securi= ty of=A0th= e DNS to provide source authentication for public keys."


The charter allows DANE to PROVIDE source= authentication of keys. Nowhere does the charter state that DANE is going = to make statements about certificates.

Now it is p= ossible to read the charter scope more broadly to include statements about = certs and that is quite usual. But if you or Paul had wanted DANE to have e= xclusive rights in that respect then you should have come clean when the gr= oup was chartered and actually told the rest of the IETF that that is what = you wanted.


Reading the charter gives me no idea that the WG is going to do anything= other than specify a new key distribution mechanism that has no effect on = any other part of the infrastructure. Yes, I know that I knew thats what yo= u were up to, but you didn't want to tell anyone else.


If the WG wants to have exclusive rights= in this respect it is going to have to recharter in my view. I don't t= hink that is likely to happen. I think it more likely that an applicability= statement would prohibit DANE from redefining PKIX semantics or defining a= dditional path validation criteria.

If you want to have the prestige and influence of the I= ETF behind your proposal you have to play by their rules.


On Fri, Jun 10, 2011 at 10:53 PM, Ma= rtin Rex <mrex@sap.com= > wrote:
Ed Gerck wrote:
>
> In this case, because DANE changes what it means to
> "authenticate the server certificate" (which has so far been= defined
> by PKIX semantics), DANE is indeed *redefining* the meaning (semantics= )
> that people assign to that sentence. =A0We now have two angles to
> understand the sentence "authenticate the server certificate"= ; .
> The DANE and the PKIX angles.

I'm sorry, but that information is significantly inaccurate.

PKIX defines pretty close to nothing what it means to authenticate
the server certificate, besides indicating that a TLS server cert
MAY contain a specific ExtendedKeyUsage, and certificate path
validation in general (in case there is a path at all) and
entirely independent from the semantic meaning of the certificates
attributes.

What it means to authenticate a TLS Server certificate was loosely
defined by rfc2818 (HTTP over TLS, Informational) describing the
most common behaviour of the installed base, and its inofficial
successor (rfc6125, [tltt], Proposed).


Concerning the trustworthiness, DANE can be anyhing you like.
It can provide a level of trust that are significantly higher
than TLS X.509 PKI alone, by locking down (not completely overriding)
PKIX trust anchors.

You may not like it, but X.509 certs suffer from the birth defect
that they can bear only a single signature, so in PKIX there is
always just one single party asserting an identity. =A0Effectively
PKIX is hardwired to self-assertion.

While doing a certificate path validation, the PKI software may
be processing a transitional chain of claims of the kind
"oh yes, I assert this party is authorized to make such an assertion&q= uot;,
but there NEVER is any independent confirmation that this assertion
is correct. =A0In particular, the entity named by an assertion made
by any CA is unable to independently confirm or deny that this
assertion is valid if you're limited to PKIX. =A0And this is where
DANE comes in for rescue.

Google, Yahoo and whoever else was a victim of Commodo-gate
has been (or would have been) completely unable to deny the
claim made by Commodo. =A0Only Commodo was able to do something
to make that claim less dangerous (revoke the cert), but ultimately
all of the browser vendors had to issue software patches to ensure
that the incorrect Commodo assertions of identity were really
made invalid.


CAA is Commodos approach to make it less likely that something
like this happens again.

DANE is hopefully going to be the IETF tool to empower the
server and/or domain admin to ensure that any such false claims
independent of how they emerged (fraudulent,accidental
or by governmental coercion), never ever considered trustworthy
in the first place. =A0Revocation and software patches are slow
and will affect only a fraction of the internet users, and that
problem will _NEVER_ get better.

With DANE, while it has the prerequisite of intial deployment
to reach anyone at all, once that is done, the distribution
will always and constantly get better.



-Martin

_______________________________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix



--
Website: http://hallambaker.com/

--0050450176c7abd89404a5700a60-- From paul.hoffman@vpnc.org Sat Jun 11 08:08:08 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB0E11E80AE for ; Sat, 11 Jun 2011 08:08:08 -0700 (PDT) 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 jRtge0VClsTU for ; Sat, 11 Jun 2011 08:08:08 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B29AB11E80A1 for ; Sat, 11 Jun 2011 08:08:07 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p5BF81Em017957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Jun 2011 08:08:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sat, 11 Jun 2011 08:08:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D182B4C-ED40-4F59-BC39-F5E86684A6E6@vpnc.org> References: <4DF2C54C.4060706@nma.com> <201106110429.p5B4TuoF019430@fs4113.wdf.sap.corp> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: [pkix] OT: what is permitted X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 15:08:08 -0000 On Jun 11, 2011, at 6:55 AM, Phillip Hallam-Baker wrote: > Again you are engaging in invective and insult. Using the -gate suffix = is a tabloid journalism tactic. >=20 > Would you like me to write up a blog article on SAPGate the next time = your employer has a security issue? >=20 > Pejorative personal attacks and attacks against our employers are not = permitted. Sure they are: you just did it in the paragraph above. --Paul Hoffman From paul.hoffman@vpnc.org Sat Jun 11 08:10:30 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1A911E80BB for ; Sat, 11 Jun 2011 08:10:29 -0700 (PDT) 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 x6zlpF5AXUqI for ; Sat, 11 Jun 2011 08:10:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C3B2811E80BA for ; Sat, 11 Jun 2011 08:10:26 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p5BFAMIc018070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Jun 2011 08:10:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sat, 11 Jun 2011 08:10:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DF2C54C.4060706@nma.com> <201106110429.p5B4TuoF019430@fs4113.wdf.sap.corp> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] TLS server authentication schemes... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 15:10:30 -0000 On Jun 11, 2011, at 6:55 AM, Phillip Hallam-Baker wrote: > The argument you and Paul seem to be advancing is:=20 False. I am advancing the arguments that I give in my messages, not the = ones you attribute to me. Again: please state what you believe, but = maybe consider not stating what others believe. --Paul Hoffman From hallam@gmail.com Sat Jun 11 10:09:15 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF68B11E81DA for ; Sat, 11 Jun 2011 10:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uq6QXLXg5sFg for ; Sat, 11 Jun 2011 10:09:15 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF4F111E81D5 for ; Sat, 11 Jun 2011 10:09:14 -0700 (PDT) Received: by ywp31 with SMTP id 31so1961579ywp.31 for ; Sat, 11 Jun 2011 10:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xSFbncP+WeVM7JcMh2jLQfSpRTH/YWSCMC0yKWQlpiE=; b=ttxYoubTpdVEihlIT92eaQd0cdmmu1SwDWnFuGrbebIa8Tck7IaakKSV1cXhYhlAQJ RRSzNHCMJpoqlvbKufKK1ps6E9N5boI+dC2TInH7pQ7gpz/TmFTQpwjN46FJYiJjMtDC Mj2envlAQKR/t316HdEOLVtvhZUvv7cDQfgRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Sm+/VdkRoBUl3ygt3h2EeaZVYLAcz5AK+I4s921xhDPoG1qJ3WKNyKzKoXNsocWdSz eEw+ukZBcZj15MLWJwndIIJY41aZ3fHYWcRBq4dEFz5D9Z0BYftfQfWOPmohhAh/jHUG 0q6s70ogrSI5mnmNYse2vr6n820XreaXF45eg= MIME-Version: 1.0 Received: by 10.100.255.2 with SMTP id c2mr3239637ani.41.1307812154402; Sat, 11 Jun 2011 10:09:14 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Sat, 11 Jun 2011 10:09:13 -0700 (PDT) In-Reply-To: References: <4DF2C54C.4060706@nma.com> <201106110429.p5B4TuoF019430@fs4113.wdf.sap.corp> Date: Sat, 11 Jun 2011 13:09:13 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=00163662e661e5664104a572beb3 Cc: pkix@ietf.org Subject: Re: [pkix] TLS server authentication schemes... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 17:09:16 -0000 --00163662e661e5664104a572beb3 Content-Type: text/plain; charset=ISO-8859-1 No, that really is the case you are making. It may be rather inconvenient for you to see your points laid out in that fashion but that is exactly what you have been arguing. There are three issues here 1) Are the parts of CAA that you are objecting to useful? I don't think anyone is objecting to the fact that they are. 2) Are they within PKIX charter scope? They are very clearly within the IETF PKIX charter. They are very clearly similar to schemes such as OCSP and SCVP that the group has considered previously. 3) Are they in DANE charter scope? That is rather less clear because the DANE charter does not actually explicitly state that it is going to propose the restriction semantics you describe in your draft. I find this argument over process to be rather tiresome and irrelevant. I suggest that if someone has a problem with doing CAA in PKIX that they propose an applicability statement to the IESG and let them handle it. I also think that you would be much better advised to remove the restriction semantics from your own draft until such time as you have demonstrated that you have an effective and reliable mechanism for key distribution first. On Sat, Jun 11, 2011 at 11:10 AM, Paul Hoffman wrote: > On Jun 11, 2011, at 6:55 AM, Phillip Hallam-Baker wrote: > > > The argument you and Paul seem to be advancing is: > > False. I am advancing the arguments that I give in my messages, not the > ones you attribute to me. Again: please state what you believe, but maybe > consider not stating what others believe. > > --Paul Hoffman > > -- Website: http://hallambaker.com/ --00163662e661e5664104a572beb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No, that really is the case you are making.

It may be ra= ther inconvenient for you to see your points laid out in that fashion but t= hat is exactly what you have been arguing.


There are three issues here

1) Are the = parts of CAA that you are objecting to useful?

I d= on't think anyone is objecting to the fact that they are.


2) Are they within PKIX charter scope?
<= div>
They are very clearly within the IETF PKIX charter. They= are very clearly similar to schemes such as OCSP and SCVP that the group h= as considered previously.


3) Are they in DANE charter scope?
=

That is rather less clear because the DANE charter does= not actually explicitly state that it is going to propose the restriction = semantics you describe in your draft.


I find this argument over process to be = rather tiresome and irrelevant. I suggest that if someone has a problem wit= h doing CAA in PKIX that they propose an applicability statement to the IES= G and let them handle it.

I also think that you would be much better advised to r= emove the restriction semantics from your own draft until such time as you = have demonstrated that you have an effective and reliable mechanism for key= distribution first.



On Sat, Jun 11, 2011= at 11:10 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Jun 11, 2011, at 6:55 AM, Phillip Hallam-Baker wrote:<= br>
> The argument you and Paul seem to be advancing is:

False. I am advancing the arguments that I give in my messages, not t= he ones you attribute to me. Again: please state what you believe, but mayb= e consider not stating what others believe.

--Paul Hoffman




--
Website: http://hallambaker.com/

--00163662e661e5664104a572beb3-- From geoffk@geoffk.org Sun Jun 5 01:45:01 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4E021F8491; Sun, 5 Jun 2011 01:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 acJVPe3Mjbum; Sun, 5 Jun 2011 01:45:00 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id D47D121F8490; Sun, 5 Jun 2011 01:45:00 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id C0CB333D18D; Sun, 5 Jun 2011 08:44:58 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Yoav Nir References: <81856AC0-F6FB-4321-93FE-559D5C5E2743@checkpoint.com> From: Geoffrey Keating Date: 05 Jun 2011 01:44:58 -0700 In-Reply-To: <81856AC0-F6FB-4321-93FE-559D5C5E2743@checkpoint.com> Message-ID: Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sat, 11 Jun 2011 11:13:30 -0700 Cc: "pkix@ietf.org" , "tls@ietf.org" Subject: Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 08:45:01 -0000 Yoav Nir writes: > Yoav Nir writes: > >> In late 2008, when some researchers got RapidSSL to sign a certificate >> request that collided with their rogue sub-CA certificate, several things >> came to light: >> - They were a ridiculously small company, with the only full-time employee. >> An accountant ... > I'm not sure where I've read it. Probably some blog entry about the incident. Not Bruce Schneier's because his entries are still online. > > Anyway, checking the data for now, Business Week has this: > http://investing.businessweek.com/research/stocks/private/people.asp?privcapId=20888814 > > It lists two "key executives", VP Marketing and VP Sales and no CEO/President. Click their links, and both have other jobs at Globalsign and other companies. > > The key issue is the total lack of in-house expertise. Late in 2008, it wasn't RapidSSL that switched to MD5. Verisign did it for them: > http://www.thetechherald.com/article.php/200852/2708/VeriSign-replaces-RapidSSL-certificates RapidSSL is owned by GeoTrust which at the time was owned by VeriSign (thus the press release), and now by Symantec. It wouldn't surprise me if RapidSSL itself has no employees at all. I don't think Business Week's data is reliable in this case. From hallam@gmail.com Sat Jun 11 11:31:25 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8693811E81F1 for ; Sat, 11 Jun 2011 11:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 T7np1wu21jKM for ; Sat, 11 Jun 2011 11:31:24 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 90E0911E8206 for ; Sat, 11 Jun 2011 11:31:24 -0700 (PDT) Received: by gxk19 with SMTP id 19so3171548gxk.31 for ; Sat, 11 Jun 2011 11:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cu6A2HMzWsqEFanUYLPSBZ62l8I1EM6Kmqto6VSL9WM=; b=n1DalIgcSUksSdipBIvPBfXCWCZ6vupKmetVuHkHpHU+GOKq9eO55aRgCLZ9Dp/76w /2Z8dM5RLhh1PwXeu9OJudwJ7uO3KBUL9o2Ur2o603J01K1DTibzjVh+ub8qCHbBWsDc 9Dmy2BACIX8wXqQtwkjA3WjvnWR0u7MOb0FX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=R3qykYVSWbKMOGL5mSWLB2hBFNpMcUK/CCsTWKyENwC0eDzBdLiTrpWW16SmjlZ2Ey Lb5dhH8qxLz4l3PFRpUoeuSSTRotJJ87NBftwqJyWL1OJ4aBfnuWY1grHlFN4r0xSxT+ fkLnLl+7KLZ3oKky9yWM1zRoIK+4+nNTjwuBM= MIME-Version: 1.0 Received: by 10.101.12.10 with SMTP id p10mr761778ani.107.1307817083144; Sat, 11 Jun 2011 11:31:23 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Sat, 11 Jun 2011 11:31:23 -0700 (PDT) In-Reply-To: <1A03F7F8-1225-4E88-80D8-CCEE0CC31F08@checkpoint.com> References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> <1A03F7F8-1225-4E88-80D8-CCEE0CC31F08@checkpoint.com> Date: Sat, 11 Jun 2011 14:31:23 -0400 Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: multipart/alternative; boundary=0050450176c7ac085804a573e422 Cc: "pkix@ietf.org" , Paul Hoffman Subject: Re: [pkix] CAA and relying parties X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 18:31:25 -0000 --0050450176c7ac085804a573e422 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 11, 2011 at 8:53 AM, Yoav Nir wrote: > More generally, a CAA record is related to my next certificate, whereas a > DANE record is about my current certificate. So unless we actually want the > CAA record to be used by RPs, we should not specify it. Even better, the > spec should warn RPs against using it. The CAA spec is written to permit but not encourage RP checks. The reason for this is that any protocol change that is deployed in a client becomes very difficult to undo. If people decide that they want to use CAA to do that they are going to do so regardless of any cautionary language in the spec. Therefore CAA allows the DNS domain owner to tell potential RP checkers that their particular records MAY or MUST NOT be used for that particular purpose. That is all that bit 6 does. We can beef up the cautionary language against that type of checking. I probably have all the text written already in the use case document. The people who were originally interested in doing this particular checking have a client that is almost invariably automatically updated. So they have a rather interesting situation in that they don't have to consider legacy issues to the same extent that Microsoft, Apple and others do. On the other issues, I see two choices 1) We decide that RP checks are a bad idea for technical reasons and neither DANE nor PKIX specify a mechanism. 2) We decide that RP checks of PKIX certs are an acceptable idea and PKIX specify them. I don't see a case for PKIX deciding that RP checks are a good idea but that they should only be considered by a group of people who frequently express views that could be seen as hostile to the PKIX architecture and implementation, do not want to use ASN.1 syntax, do not want to use PKIX algorithm identifiers and are openly contemptuous of what the PKIX community has achieved over the past 20 years. -- Website: http://hallambaker.com/ --0050450176c7ac085804a573e422 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jun 11, 2011 at 8:53 AM, Yoav Nir <ynir@checkpoint.com> wrote:
More generally, a CAA record is related to my next certificate, whereas a D= ANE record is about my current certificate. =A0So unless we actually want t= he CAA record to be used by RPs, we should not specify it. Even better, the= spec should warn RPs against using it.

The CAA spec is written to= permit but not encourage RP checks. The reason for this is that any protoc= ol change that is deployed in a client becomes very difficult to undo.=A0

If people decide that they want to use CAA to do that t= hey are going to do so regardless of any cautionary language in the spec.

Therefore CAA allows the DNS domain owner to tell p= otential RP checkers that their particular records MAY or MUST NOT be used = for that particular purpose. That is all that bit 6 does.

We can beef up the cautionary language against th= at type of checking. I probably have all the text written already in the us= e case document.

The people who were originally in= terested in doing this particular checking have a client that is almost inv= ariably automatically updated. So they have a rather interesting situation = in that they don't have to consider legacy issues to the same extent th= at Microsoft, Apple and others do.=A0



On the other issues, I se= e two choices

1) We decide that RP checks are a ba= d idea for technical reasons and neither DANE nor PKIX specify a mechanism.=

2) We decide that RP checks of PKIX certs are an accept= able idea and PKIX specify them.

I don't see a case= for PKIX deciding that RP checks are a good idea but that they should only= be considered by a group of people who frequently express views that could= be seen as hostile to the PKIX architecture and implementation, do not wan= t to use ASN.1 syntax, do not want to use PKIX algorithm identifiers and ar= e openly contemptuous of what the PKIX community has achieved over the past= 20 years.
--0050450176c7ac085804a573e422-- From i.grok@comcast.net Sat Jun 11 12:08:19 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F185411E8131 for ; Sat, 11 Jun 2011 12:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.159 X-Spam-Level: X-Spam-Status: No, score=-102.159 tagged_above=-999 required=5 tests=[AWL=0.441, 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 msUsd3nMzuZI for ; Sat, 11 Jun 2011 12:08:18 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE8911E8130 for ; Sat, 11 Jun 2011 12:08:18 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta09.westchester.pa.mail.comcast.net with comcast id uj3r1g0011HzFnQ59j8JeS; Sat, 11 Jun 2011 19:08:18 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta14.westchester.pa.mail.comcast.net with comcast id uj8H1g00h00PQ6U3aj8J77; Sat, 11 Jun 2011 19:08:18 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p5BJ8EmI003315 for ; Sat, 11 Jun 2011 15:08:14 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p5BJ8Ddx003313 for pkix@ietf.org; Sat, 11 Jun 2011 15:08:13 -0400 Date: Sat, 11 Jun 2011 15:08:13 -0400 From: Scott Schmit To: pkix@ietf.org Message-ID: <20110611190813.GA3066@odin.ulthar.us> Mail-Followup-To: pkix@ietf.org References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> <1307741865.2123.14.camel@localhost> <4DF2A183.8040809@nma.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DF2A183.8040809@nma.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [pkix] CAA and relying parties X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 19:08:19 -0000 On Fri, Jun 10, 2011 at 03:58:11PM -0700, Ed Gerck, Ph.D. wrote: > DANE defines a different way (ie, different meaning, different > semantics) to authenticate the association of the server's > certificate with the intended domain name, and is done without > trusting an external CA. [1] > > Intuitively, as more witnesses are considered, it becomes less likely > that all witnesses can be compromised at the same time. More Witnesses > = Better Evidence. [2] > > DANE reduces the number of witnesses over what is needed with PKIX, > hence it can be more easily compromised. Hence, it is not desirable. > > In other words, exactly because the same DNS administrator for a > domain name is authorized under DANE to *both* give identifying > information about the zone and make an authoritative binding between > the domain name and a certificate, it should be less trustworthy. > Trust cannot be earned by self-assertions [2]. You've lost me. In the current Internet HTTPS PKI model, I generate a key for my HTTPS server. I then go to some CA to get a certificate for my key. If I opt for a DV certificate, the CA will require that I prove that I possess the key (via a CSR) and that I have control over the domain I want it associated with. I'm not sure what all the methods are for proving this are, but I've heard of using WHOIS-listed email or a TXT record cookie published by my domain. Assuming that the email listed in my WHOIS data is hosted by the domain in question, both of those amount to the CA trusting the person that controls the DNS records published for the domain. What's independent about that? I suppose it's possible that the TXT cookie approach is no longer considered a good way to prove domain possession, and that WHOIS is the independent source of information. But that amounts to the domain registry vouching for the owner of the domain, which they also do when they publish the DNS NS/DS records. The only case I've heard where DV certs have an additional benefit over what DANE provides is in the case of large well-known domains/businesses, they'll refuse to issue certificates for typosquatters. But that requires good behavior on the part of every CA. I don't disagree with you that having multiple sources vouching for the validity of a certificate is a good thing, but that's not a system we have now, so it can't be used as an argument against DANE. At least with DNSSEC/DANE, I can imagine how DLV-like records can be used to allow for discoverable certification of key-domain associations from multiple CAs. -- Scott Schmit From egerck@nma.com Sat Jun 11 13:45:35 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45841F0C43 for ; Sat, 11 Jun 2011 13:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_40=-0.185] 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 oA8OSIDSQ-nk for ; Sat, 11 Jun 2011 13:45:35 -0700 (PDT) Received: from nm28-vm0.access.bullet.mail.mud.yahoo.com (nm28-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.229]) by ietfa.amsl.com (Postfix) with SMTP id 3AB1C1F0C36 for ; Sat, 11 Jun 2011 13:45:35 -0700 (PDT) Received: from [66.94.237.127] by nm28.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2011 20:45:32 -0000 Received: from [66.94.237.96] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2011 20:45:32 -0000 Received: from [127.0.0.1] by omp1001.access.mail.mud.yahoo.com with NNFMP; 11 Jun 2011 20:45:32 -0000 X-Yahoo-Newman-Id: 211508.73979.bm@omp1001.access.mail.mud.yahoo.com Received: (qmail 2805 invoked from network); 11 Jun 2011 20:45:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307825132; bh=ss6Gy0Z4X7jxH2UHJqmveinfGBYHnodE8mBqYmUGxH0=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=OLV6oyfOD9S3vNbszSCeefG9KHzlOVIlv4PCglTGr8cmr/1kICqFGVjzqneUeoiJiBSCiQOC+57RLLwB+qxNOaJ0TNZ69M6vXgp3SfU6QUX3L6paxVClE0phG/zE7WDIZVfCoHx28LFdKH7SbVVXibSFQeZ/+VIbHQRaN2EHWHI= Received: from [172.16.1.88] (egerck@99.145.106.177 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 11 Jun 2011 13:45:31 -0700 PDT X-Yahoo-SMTP: MbPjQnGswBC7yA6NwEFbGJ4iXszffqyyVjqB X-YMail-OSG: xWSlrRcVM1kpEUq0lOs44z0ONe5c4_QODiCTwPSZDvPPzfg 7uEKZkXo7MxSL3KbwuToKv0VorvAqkFb4bOQC425nDJk00VKXmNWhQhwhQk0 kAgpbZ.WSfUNp5nAf8s1F4aT.GVp3cbbcXRznINRrtdDf5hwyJpG16gsjMZg RmPpK6HSg1Si3_BFIovSRuJtBTyKmzhcxF_6KQciSUoJnMYQuJ5y1qfE8Gqh HK.hANYts9K2hOTuMuNwM4dhek5QVIaIUYBxlX3uAK.inH2v7MYF98ZWwnSp PoV7Y9VzBtHr2f61dMFucI3H.8ge9yyeOGcX8fHLLAIdZuPyVre_lkatQX.1 RQqZcR1Tt6mFMYkUcj96eHOgIcQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DF3D39F.4000705@nma.com> Date: Sat, 11 Jun 2011 13:44:15 -0700 From: "Ed Gerck, Ph.D." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: pkix@ietf.org References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> <1307741865.2123.14.camel@localhost> <4DF2A183.8040809@nma.com> <20110611190813.GA3066@odin.ulthar.us> In-Reply-To: <20110611190813.GA3066@odin.ulthar.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] CAA and relying parties X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 20:45:35 -0000 On 6/11/2011 12:08 PM, Scott Schmit wrote: > On Fri, Jun 10, 2011 at 03:58:11PM -0700, Ed Gerck, Ph.D. wrote: >> >> In other words, exactly because the same DNS administrator for a >> domain name is authorized under DANE to *both* give identifying >> information about the zone and make an authoritative binding between >> the domain name and a certificate, it should be less trustworthy. >> Trust cannot be earned by self-assertions [2]. >> > You've lost me. In the current Internet HTTPS PKI model, I generate a > key for my HTTPS server. I then go to some CA to get a certificate for > my key. If I opt for a DV certificate, the CA will require that I prove > that I possess the key (via a CSR) and that I have control over the > domain I want it associated with. I'm not sure what all the methods are > for proving this are, but I've heard of using WHOIS-listed email or a > TXT record cookie published by my domain. > > Assuming that the email listed in my WHOIS data is hosted by the domain > in question, both of those amount to the CA trusting the person that > controls the DNS records published for the domain. > > What's independent about that? You are assuming too little. A PKIX cert can depend on several information channels independently existing and being independently verified, for example in identification, issuance, distribution, validation, and revocation. For example, PKIX includes more than one way to verify cert revocation. Some of the redundancy and independence is regulated in the CPS, which can vary in PKIX. For example, a CA may require two forms of identification with photo and physical presence to a notary before your cert is issued. You can also have mutually-trusted validation authorities verify if certs are revoked, not just each issuing CA. PKIX, unfortunately, also allows ways where there is less separation of powers, where for example one entity just rubber-stamps what another entity does (/sans recourse endorsement/). But DANE seems to make that the one and only way (see my quote above). Cheers, Ed Gerck From stephen.farrell@cs.tcd.ie Sun Jun 12 13:00:57 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D5111E80E9 for ; Sun, 12 Jun 2011 13:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.25 X-Spam-Level: X-Spam-Status: No, score=-106.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 e8Aoa28CwZZc for ; Sun, 12 Jun 2011 13:00:57 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id ED5FF228010 for ; Sun, 12 Jun 2011 13:00:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 46BEA153856; Sun, 12 Jun 2011 21:00:48 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1307908843; bh=yNNYnmArI9vApE 3P0krEMzQ05hqClAWxCDSZCYDSPIw=; b=HhtB5XEPU5V+2HTkLKmkEYQ8cR05UL krd59x2Fb6oHIjvOe0hwxLKbfBwCmJtxKILIjrgmbPVq1IcvH0uR0KYoLRhm9C4p DA7ZpRGATKeTi71rM7PeQgimGKOSzjN2PryMMg00mcaS2TUvh6YmZ3BDmgbbu0lZ dzfpCFUxfFiZwW5Q/VmghtAYFvaHtiiXl12+DupDWCOdHZAokGZpqAlyFXVK9HHX vdgOVExR+FQKBdcWcCrB2EuYi7W5fCtC0ZBP75o4hr85HMOxBZjLkN0dtRTIgSy4 u5S7A/rUWyBVU/ZpYKcfMoNzC+OY4PDADCJfWEMgcAsp9oye+gwZkYKA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id zvy-he4Z4bSS; Sun, 12 Jun 2011 21:00:43 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.19.164]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6562E1537F8; Sun, 12 Jun 2011 21:00:41 +0100 (IST) Message-ID: <4DF51ADF.6080300@cs.tcd.ie> Date: Sun, 12 Jun 2011 21:00:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Hoffman References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> In-Reply-To: <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] CAA and relying parties X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 20:00:57 -0000 On 09/06/11 17:10, Paul Hoffman wrote: > On Jun 8, 2011, at 7:44 PM, Martin Rex wrote: > >> CAA is _not_ for the RP, i.e. not for _you_ (and me, and most others ...) >> It is only another means for a CA to detect attempts to subvert one of >> its RAs, so it's primary purpose is CYA for large commercial CAs. > > That's not what draft-ietf-pkix-caa-00.txt says. Section 2.3 explicitly covers relying parties using CAA. I believe that section should be removed, but it is in the current WG document. As an individual (But of course "we're all individuals!":-) [1] I just had a read of this. Seems overly complicated to me by quite a bit. I think this should just define a way to nominate one or more CAs as the chosen CAs for a domain and that's all. What'd be wrong with looking up a domain and getting back an RR with comma-sep list of strings representing the CAs that the domain owner wants to use? The rest (and lots of the language) just seems like useless complexity. I don't even think we need to standardise on the name form used - the CABforum people could agree on trademarks or a FCFS list or whatever - its the issuing CA's responsibility to know its own name(s) when it sees it(them), everything else is unnecessary. (Including specifying the action when the name(s) are not present.) I think many of the MUST statements seem unnecessary, or perhaps something that someone else (e.g. CABforum) could define. I agree with those who argue that the RP stuff doesn't belong here, for technical, not turf-war, reasons. The main reason is that if the RP is involved then we start to need all the complex stuff since then it has to be well-defined. Without the RP stuff, all we need is for CAs to recognise themselves (or their absence) and all the rest can be arranged out of band. S. [1] http://www.imdb.com/title/tt0079470/quotes From mrex@sap.com Sun Jun 12 15:23:47 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5137611E8121 for ; Sun, 12 Jun 2011 15:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.577 X-Spam-Level: X-Spam-Status: No, score=-9.577 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 lUcvqreJN1Vx for ; Sun, 12 Jun 2011 15:23:46 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7DB11E8118 for ; Sun, 12 Jun 2011 15:23:46 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p5CMNgFj019224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2011 00:23:42 +0200 (MEST) From: Martin Rex Message-Id: <201106122223.p5CMNg5H009465@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Mon, 13 Jun 2011 00:23:42 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Jun 11, 11 09:55:40 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] TLS server authentication schemes... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 22:23:47 -0000 Phillip Hallam-Baker wrote: > > Again you are engaging in invective and insult. Using the -gate suffix is a > tabloid journalism tactic. I'm sorry if this term is offending to you, I really did not mean to use it as an insult. It characterizes a specific event that is used to demonstrate a much more general problem with the trust model that is used by TLS. The Term Watergate wasn't used as an insult against the watergate office complex, but instead as a reference to where it happened. This particular event of misissued certificates could have happened with any CA, not just Commodo. But it happened at Commodo, just like that other event happened at Watergate. > > Pejorative personal attacks and attacks against our employers are not > permitted. I refered to a particular event with a term that is quite commonly understood to refer to that particular event, and described the characteristics of the problems that this event showed up to have always existed with the (lack of) trust anchor management in browsers. I really did not intend to insult your employer, and I want to apologize if you feel insulted. What term would you prefer to refer to that particular event so that everyone else recognizes it easily in discussions? > > The argument you and Paul seem to be advancing is: > > 1) PKIX must not intrude on what you define as DANE 'turf' Nope, we just want to avoid confusion and needless complexity. CAA should be for CAs and ignored by RPs, TLSA should be for RPs. > > 2) DANE can do any sweet thing it likes on PKIX turf including rewrite the > certificate path validation mechanism. I don't have the slightest clue what you are refering to. rfc-2818 does not look like a product from PKIX, and rfc6125 was no product of PKIX (it was discussed on an IETF mailing list called certid). > > 3) The IETF must not allow anyone to propose an alternative mechanism to > solve the issues you have identified. It would be unusual for the IETF, after having newly chartered a new working group to provide a solution, that shortly thereafter another working group that has not previously workd on solutions for this issue adopts a work item with the intent to compete with the new working group. > > 4) The market should be allowed to decide whether your proposal is accepted. Do you have a problem with that? The event (whose name I'm not supposed to name) showed up which problems exist with the "TLS X.509 PKI". The CAs had their 15 years, now let the IETF DANE WG build a solution and see whether the market likes it. > > The DANE charter specifies the following: > > "The solutions specified by this working group rely upon the security of the > DNS to provide source authentication for public keys." > > > The charter allows DANE to PROVIDE source authentication of keys. Nowhere > does the charter state that DANE is going to make statements about > certificates. Huh? C'mon, you know that the most common wrapping for public keys is X.509 certs, so it would be stupid not to support public keys wrapped in X.509 certs in DANE, wouldn't it. It also happens to be a popular wrapping in other areas of the IETF. Doing stuff that fits together seems reasonable. If the charter said "public keys wrapped in X.509 certs are out of scope" that would be a different issue -- but as much as you would like that, the DANE charter doesn't say that. Your fear seems to be that DANE might obviate DV-validated certs issued by CAs, because there is not much value proposition. There should not be a tax on the use of TLS on the internet to encrypt traffic, and DANE might help to provide "free licenses" for the use of TLS. -Martin PS: I'm offline for the next couple of days From hallam@gmail.com Sun Jun 12 18:00:53 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553B411E813E for ; Sun, 12 Jun 2011 18:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Q4kSQPrJmlWe for ; Sun, 12 Jun 2011 18:00:52 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7775711E807C for ; Sun, 12 Jun 2011 18:00:52 -0700 (PDT) Received: by yie30 with SMTP id 30so881946yie.31 for ; Sun, 12 Jun 2011 18:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=puMX71YnMOWCTzroIFg3UTyij0FpGFdWNkwJqcJO82w=; b=w5BFFgST/IQrHLed7LP0mp1chLPAr1UEasO0ntjelF43L6eBcZlNSERq1LQ4eFM/Yc NuPyEtg0i790QXI6JAFN21sS/fTNkwIz1CsltRV6fuL8uwF3ayNIh7xQHOG5RDX2NwHN NlbSrLY5vJ3VN4do24v5v8WDx6EvpJM7KvwZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PEkmrR3ZC8jXcvjRWqK9GigU2M2scETdr8ZLmB+Vmu4i1/dufh6rx64gPeKp1Dpgye le1KbqxDZOLccERKyiTc6l5VGoctU+TpFlVsC3iz6u7W0/grUz6iuNfHRnxWulTM7ZAy p+YvBAjGZd8zRqqfrKLyF8P4V4e9Mmt++cT1U= MIME-Version: 1.0 Received: by 10.101.11.14 with SMTP id o14mr4242625ani.88.1307926851835; Sun, 12 Jun 2011 18:00:51 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Sun, 12 Jun 2011 18:00:51 -0700 (PDT) In-Reply-To: <201106122223.p5CMNg5H009465@fs4113.wdf.sap.corp> References: <201106122223.p5CMNg5H009465@fs4113.wdf.sap.corp> Date: Sun, 12 Jun 2011 21:00:51 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016e68fcec465569f04a58d7341 Cc: pkix@ietf.org Subject: Re: [pkix] TLS server authentication schemes... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 01:00:53 -0000 --0016e68fcec465569f04a58d7341 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 12, 2011 at 6:23 PM, Martin Rex wrote: > Phillip Hallam-Baker wrote: > > > > Again you are engaging in invective and insult. Using the -gate suffix is > a > > tabloid journalism tactic. > > I'm sorry if this term is offending to you, I really did not mean > to use it as an insult. It characterizes a specific event that is > used to demonstrate a much more general problem with the trust > model that is used by TLS. > It was a pejorative term used by F-secure as an attack against one of their competitors. > The Term Watergate wasn't used as an insult against the watergate > office complex, but instead as a reference to where it happened. > This particular event of misissued certificates could have > happened with any CA, not just Commodo. But it happened at Commodo, > just like that other event happened at Watergate. Its the -gate suffix that is the problem here. Comodo fraudulent certificate incident would be acceptable. Comodo nuclear catastrophe, Comodogate etc not acceptable. > The argument you and Paul seem to be advancing is: > > > > 1) PKIX must not intrude on what you define as DANE 'turf' > > Nope, we just want to avoid confusion and needless complexity. > CAA should be for CAs and ignored by RPs, TLSA should be for RPs. We are not finished with the design of TLSA yet. We seem to have agreement that there is a potential overlap. Is it really beyond possibility that we can't agree on a common syntax? I am quite happy to rev the syntax of CAA if that makes sense. But do remember that the syntax there is chosen to match the syntax of PKIX > 4) The market should be allowed to decide whether your proposal is > accepted. > > Do you have a problem with that? > No, but that position is incompatible with the position 'nobody else allowed to work in this area'. The event (whose name I'm not supposed to name) showed up which problems > exist with the "TLS X.509 PKI". The CAs had their 15 years, now let > the IETF DANE WG build a solution and see whether the market > likes it. X.509 did not get a clear path. When X.509 emerged the IETF was working on DNSSEC, SPKI and PGP all at the exact same time. > Your fear seems to be that DANE might obviate DV-validated certs > issued by CAs, because there is not much value proposition. > There should not be a tax on the use of TLS on the internet to > encrypt traffic, and DANE might help to provide "free licenses" > for the use of TLS. No, my fear is that the DANE group risks mucking up the best chance for getting rid of them. -- Website: http://hallambaker.com/ --0016e68fcec465569f04a58d7341 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jun 12, 2011 at 6:23 PM, Martin = Rex <mrex@sap.com&= gt; wrote:
Phillip Hallam-Baker wrote:
>
> Again you are engaging in invective and insult. Using the -gate suffix= is a
> tabloid journalism tactic.

I'm sorry if this term is offending to you, I really did not mean=
to use it as an insult. =A0It characterizes a specific event that is
used to demonstrate a much more general problem with the trust
model that is used by TLS.
=A0
It was a pejo= rative term used by F-secure as an attack against one of their competitors.=

=A0
The Term Watergate wasn't used as an insult against the watergate
office complex, but instead as a reference to where it happened.
This particular event of misissued certificates could have
happened with any CA, not just Commodo. =A0But it happened at Commodo,
just like that other event happened at Watergate.

Its the -gate suffix that is the problem here.

<= div>Comodo fraudulent certificate incident would be acceptable. Comodo nucl= ear catastrophe, Comodogate etc not acceptable.
=A0

> The argument you and Paul seem to be advancing is:
>
> 1) PKIX must not intrude on what you define as DANE 'turf'

Nope, we just want to avoid confusion and needless complexity.
CAA should be for CAs and ignored by RPs, TLSA should be for RPs.

We are not finished with the design of TLSA yet.=A0<= /div>

We seem to have agreement that there is a potentia= l overlap. Is it really beyond possibility that we can't agree on a com= mon syntax?

I am quite happy to rev the syntax of CAA if that makes= sense. But do remember that the syntax there is chosen to match the syntax= of PKIX=A0

> 4) The market should be allowed to decide whether yo= ur proposal is accepted.

Do you have a problem with that?

= No, but that position is incompatible with the position 'nobody else al= lowed to work in this area'.


The event (whose name I'm not supposed to name) showed up which problem= s
exist with the "TLS X.509 PKI". =A0The CAs had their 15 years, no= w let
the IETF DANE WG build a solution and see whether the market
likes it.

X.509 did not get a clear path.

When X.509 emerged the IETF was working on DNSSEC, = SPKI and PGP all at the exact same time.

=A0
Your fear seems to be that DANE might obviate DV-validated certs
issued by CAs, because there is not much value proposition.
There should not be a tax on the use of TLS on the internet to
encrypt traffic, and DANE might help to provide "free licenses" for the use of TLS.

No, my fear is that the= DANE group risks mucking up the best chance for getting rid of them.
=

=A0
--
Website: http://hallambaker.com/

--0016e68fcec465569f04a58d7341-- From paul.hoffman@vpnc.org Mon Jun 13 08:52:32 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E86F11E80F8 for ; Mon, 13 Jun 2011 08:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 IwABmY09-1iV for ; Mon, 13 Jun 2011 08:52:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEBB11E80CE for ; Mon, 13 Jun 2011 08:52:29 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p5DFp6Eq051689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Jun 2011 08:51:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4DF51ADF.6080300@cs.tcd.ie> Date: Mon, 13 Jun 2011 08:51:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6A4FD90D-B8FB-4041-9A0E-1822D8B02021@vpnc.org> References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> <4DF51ADF.6080300@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: [pkix] CAA and identifiers X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:52:32 -0000 On Jun 12, 2011, at 1:00 PM, Stephen Farrell wrote: > I just had a read of this. Seems overly complicated to me by > quite a bit. >=20 > I think this should just define a way to nominate one or more > CAs as the chosen CAs for a domain and that's all. >=20 > What'd be wrong with looking up a domain and getting back an > RR with comma-sep list of strings representing the CAs that > the domain owner wants to use? The rest (and lots of the > language) just seems like useless complexity. >=20 > I don't even think we need to standardise on the name form > used - the CABforum people could agree on trademarks or > a FCFS list or whatever - its the issuing CA's responsibility > to know its own name(s) when it sees it(them), everything > else is unnecessary. (Including specifying the action when > the name(s) are not present.) This misses the point that these DNS records are going to be formed and = put in by DNS admins. Asking a DNS admin to pick the right name form for = the CA seems onerous. If we can instead say "the name comes from the = cert you are using or the cert you want to be using, and here is how to = extract it", that will lead to fewer false negatives where the DNS admin = gets the desired name wrong. Further, if we go with your proposal, we can't even say "get the name = from the Subject or the SubjectAltName" because some CA have tortured = these fields to death. The current draft uses policy OIDs, which are completely unfamiliar to = DNS admins, but at least you can get it from a CA cert you are holding. = My preference would be a hash of the CA's public key, but I can also see = some positive value to using the policy OID. However, I think "let the = CAs pick names and somehow transmit them to the DNS admins" is not a = good way to get interop. --Paul Hoffman From stephen.farrell@cs.tcd.ie Mon Jun 13 10:05:14 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBE911E8162 for ; Mon, 13 Jun 2011 10:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.922 X-Spam-Level: X-Spam-Status: No, score=-105.922 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 XB4UcMXHTGOM for ; Mon, 13 Jun 2011 10:05:13 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id C888611E8154 for ; Mon, 13 Jun 2011 10:05:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C0E45171C57; Mon, 13 Jun 2011 18:05:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1307984707; bh=FlPxqzRlJHuE0x xWYKj7xpS7mx4z7WpNbhTm3na60jE=; b=w44/11guGFq5KaAdHq22QzxQoOPBuk Vo/eKjpYUyIex7CD2FToN1RCG/FiDx2tSn76XX9/VtBtc0x6IQYeUPjfQjcuHdTZ OdfCTwx6+v60S1Mlq27i1JF+QPRtZKtc3hBzWbvmQwQVGRiyz7jFwXwO5gmoqKRq x26nXn3MFsi80VlhyLYUcJgZXEAEsOf6Tj3hLe6Pgl+2iNo6T4Q92uL9qHGZAJNr IWrgFfkCH1TZBvzbkG7joot32HCFPUTn8ogI7boawznuOG295L2B7OgjLbf5ATJz SEGDFsBNwd/on40LamNDx/JQvBYKG5DdMwd7T91s1EY2y33AXG2MOExw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id s5YBcWozYhy8; Mon, 13 Jun 2011 18:05:07 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 42D24171C2D; Mon, 13 Jun 2011 18:05:06 +0100 (IST) Message-ID: <4DF64341.30206@cs.tcd.ie> Date: Mon, 13 Jun 2011 18:05:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Hoffman References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> <4DF51ADF.6080300@cs.tcd.ie> <6A4FD90D-B8FB-4041-9A0E-1822D8B02021@vpnc.org> In-Reply-To: <6A4FD90D-B8FB-4041-9A0E-1822D8B02021@vpnc.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] CAA and identifiers X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 17:05:14 -0000 On 13/06/11 16:51, Paul Hoffman wrote: > On Jun 12, 2011, at 1:00 PM, Stephen Farrell wrote: > >> I just had a read of this. Seems overly complicated to me by >> quite a bit. >> >> I think this should just define a way to nominate one or more >> CAs as the chosen CAs for a domain and that's all. >> >> What'd be wrong with looking up a domain and getting back an >> RR with comma-sep list of strings representing the CAs that >> the domain owner wants to use? The rest (and lots of the >> language) just seems like useless complexity. >> >> I don't even think we need to standardise on the name form >> used - the CABforum people could agree on trademarks or >> a FCFS list or whatever - its the issuing CA's responsibility >> to know its own name(s) when it sees it(them), everything >> else is unnecessary. (Including specifying the action when >> the name(s) are not present.) > > This misses the point that these DNS records are going to be formed and put in by DNS admins. Asking a DNS admin to pick the right name form for the CA seems onerous. If we can instead say "the name comes from the cert you are using or the cert you want to be using, and here is how to extract it", that will lead to fewer false negatives where the DNS admin gets the desired name wrong. > > Further, if we go with your proposal, we can't even say "get the name from the Subject or the SubjectAltName" because some CA have tortured these fields to death. > > The current draft uses policy OIDs, which are completely unfamiliar to DNS admins, but at least you can get it from a CA cert you are holding. My preference would be a hash of the CA's public key, but I can also see some positive value to using the policy OID. However, I think "let the CAs pick names and somehow transmit them to the DNS admins" is not a good way to get interop. Well, you might be right...or not:-) The relevant interop here (absent RPs using CAA) is that the CAA RR just needs to include (or not) something an issuer recognises as representing itself. If that's missing then the issuer should fall back to special processing and not just fire ahead and issue a cert. I think that should be much less demanding than the usual case where the issuer name has to be processed automatically by RP code written by many other 3rd parties. In this case, its only the issuer's own code that compares the value. In particular, if the special processing is (I believe, but I could be wrong) likely to involve a human, and if CAA is mostly used by higher-value domains worried about bad or careless CAs, then a relatively high proportion of false negatives won't really be a problem. (And would likely lead to an issuer choosing a new and less problematic value I expect.) It *might* be easier to use something from a cert or trust anchor, but I suspect that (in particular first time out) cut'n'paste from the issuer's web page will be easier and maybe is what's likely to actually happen, in which case, why not just let each issuer choose what they want? I don't think accidental string collisions here are a serious concern really. I'm also not at all convinced that there's a security benefit in doing anything computational for this value. I'd be fine with those string values being OIDs, (in string form), or DNs, or trademarks, or the date of birth of the CEO, or a truncated hash of a public key or whatever. I think we can just let the actual issuers choose this one. It could be reasonable to say that the values MUST be at least 8 bytes long and MUST NOT contain NULL or stuff like that, but I don't see much of a need for anything else really. But I don't think this is a huge point really, other than maybe providing a welcome case where we can deliberately decide to choose something much simpler than the usual sort of identifier needed in a PKI. However, it could equally be the case that I'm wrong about the lack of security impact for some of this, but I've no doubt that'll be thrashed on the list and we'll end up with something that works. Cheers, S. > > --Paul Hoffman > > From koichi.sugimoto@globalsign.com Wed Jun 15 01:04:18 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3535621F84C0 for ; Wed, 15 Jun 2011 01:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DEAR_SOMETHING=1.605, 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 YBW+JQ2cbgx6 for ; Wed, 15 Jun 2011 01:04:17 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD1421F84BF for ; Wed, 15 Jun 2011 01:04:17 -0700 (PDT) Received: by pwi5 with SMTP id 5so240107pwi.31 for ; Wed, 15 Jun 2011 01:04:17 -0700 (PDT) Received: by 10.68.23.133 with SMTP id m5mr83795pbf.73.1308125056897; Wed, 15 Jun 2011 01:04:16 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id o2sm143353pbj.17.2011.06.15.01.04.15 (version=SSLv3 cipher=OTHER); Wed, 15 Jun 2011 01:04:16 -0700 (PDT) Received: by pzk5 with SMTP id 5so73167pzk.31 for ; Wed, 15 Jun 2011 01:04:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.52.70 with SMTP id r6mr79799pbo.465.1308125055511; Wed, 15 Jun 2011 01:04:15 -0700 (PDT) Received: by 10.68.52.166 with HTTP; Wed, 15 Jun 2011 01:04:15 -0700 (PDT) In-Reply-To: References: <201106122223.p5CMNg5H009465@fs4113.wdf.sap.corp> Date: Wed, 15 Jun 2011 17:04:15 +0900 Message-ID: From: koichi sugimoto To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [pkix] TLS server authentication schemes... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 08:04:18 -0000 Dear Sirs, Anyway, I do not feel good to use PKIX or IETF in order to attack specific service like DV or to benefit specific group. If DANE or CAA purposes such a thing, then, the draft should be removed from standards. But it truely aims to reduce some security risks, it must be discussed more costructive. As for bit 6 of CAA, IMHO, it shuld be used as black list, not as white lis= t. If some certificate mis-issued by some CA, then, RP can block the certifica= te. I think it might be more efficient than OCSP and CRL. Regards, Koichi Sugimoto. 2011/6/13 Phillip Hallam-Baker : > > > On Sun, Jun 12, 2011 at 6:23 PM, Martin Rex wrote: >> >> Phillip Hallam-Baker wrote: >> > >> > Again you are engaging in invective and insult. Using the -gate suffix >> > is a >> > tabloid journalism tactic. >> >> I'm sorry if this term is offending to you, I really did not mean >> to use it as an insult. =A0It characterizes a specific event that is >> used to demonstrate a much more general problem with the trust >> model that is used by TLS. > > > It was a pejorative term used by F-secure as an attack against one of the= ir > competitors. > >> >> The Term Watergate wasn't used as an insult against the watergate >> office complex, but instead as a reference to where it happened. >> This particular event of misissued certificates could have >> happened with any CA, not just Commodo. =A0But it happened at Commodo, >> just like that other event happened at Watergate. > > Its the -gate suffix that is the problem here. > Comodo fraudulent certificate incident would be acceptable. Comodo nuclea= r > catastrophe, Comodogate etc not acceptable. > >> >> > The argument you and Paul seem to be advancing is: >> > >> > 1) PKIX must not intrude on what you define as DANE 'turf' >> >> Nope, we just want to avoid confusion and needless complexity. >> CAA should be for CAs and ignored by RPs, TLSA should be for RPs. > > We are not finished with the design of TLSA yet. > We seem to have agreement that there is a potential overlap. Is it really > beyond possibility that we can't agree on a common syntax? > I am quite happy to rev the syntax of CAA if that makes sense. But do > remember that the syntax there is chosen to match the syntax of PKIX >> >> > 4) The market should be allowed to decide whether your proposal is >> > accepted. >> >> Do you have a problem with that? > > No, but that position is incompatible with the position 'nobody else allo= wed > to work in this area'. > >> The event (whose name I'm not supposed to name) showed up which problems >> exist with the "TLS X.509 PKI". =A0The CAs had their 15 years, now let >> the IETF DANE WG build a solution and see whether the market >> likes it. > > X.509 did not get a clear path. > When X.509 emerged the IETF was working on DNSSEC, SPKI and PGP all at th= e > exact same time. > >> >> Your fear seems to be that DANE might obviate DV-validated certs >> issued by CAs, because there is not much value proposition. >> There should not be a tax on the use of TLS on the internet to >> encrypt traffic, and DANE might help to provide "free licenses" >> for the use of TLS. > > No, my fear is that the DANE group risks mucking up the best chance for > getting rid of them. > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > From internet-drafts@ietf.org Thu Jun 16 01:20:46 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1529311E80D9; Thu, 16 Jun 2011 01:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 QvXrmXpBEUNL; Thu, 16 Jun 2011 01:20:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1E211E80C0; Thu, 16 Jun 2011 01:20:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110616082044.1775.25295.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2011 01:20:44 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-cmp-transport-protocols-12.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 08:20:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : Internet X.509 Public Key Infrastructure -- Transport Pr= otocols for CMP Author(s) : Tomi Kause Martin Peylo Filename : draft-ietf-pkix-cmp-transport-protocols-12.txt Pages : 19 Date : 2011-06-16 This document describes how to layer the Certificate Management Protocol over various transport protocols. It is the "CMPtrans&quo= t; document referenced in RFC 4210 and therefore updates the reference given therein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols= -12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-= 12.txt From kent@bbn.com Thu Jun 16 06:54:00 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C528E11E80E3 for ; Thu, 16 Jun 2011 06:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, 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 RZrDCxCcevr6 for ; Thu, 16 Jun 2011 06:54:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5148111E8100 for ; Thu, 16 Jun 2011 06:54:00 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:47675 helo=[192.168.1.10]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QXD1C-00070d-UD for pkix@ietf.org; Thu, 16 Jun 2011 09:53:59 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 16 Jun 2011 09:53:46 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] WGLC for draft-ietf-pkix-rfc5272-bis-03 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 13:54:00 -0000 Starts today. Closes on 6/30. Steve From kent@bbn.com Thu Jun 16 07:04:30 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B454211E813C for ; Thu, 16 Jun 2011 07:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.413 X-Spam-Level: X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 HXlfjAKI2i0b for ; Thu, 16 Jun 2011 07:04:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 31B4311E8129 for ; Thu, 16 Jun 2011 07:04:30 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:40275 helo=[192.168.1.10]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QXDBN-0007E2-LD for pkix@ietf.org; Thu, 16 Jun 2011 10:04:29 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 16 Jun 2011 10:04:27 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 14:04:30 -0000 Havingf returned from vacation, and looking over the extensive discussion on the CAA doc, I think it best to remove the discussion of RP use of this feature, and focus instead on how CAs are expected to use it. Steve From denis.pinkas@bull.net Thu Jun 16 07:04:39 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CDB11E816D for ; Thu, 16 Jun 2011 07:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.342 X-Spam-Level: ** X-Spam-Status: No, score=2.342 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_BAD_ID=2.837] 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 BEwhEy+a5qdN for ; Thu, 16 Jun 2011 07:04:38 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE0011E8169 for ; Thu, 16 Jun 2011 07:04:38 -0700 (PDT) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id 3950C418072 for ; Thu, 16 Jun 2011 16:14:00 +0200 (CEST) Received: from denispinkaspc ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with ESMTP id 2011061616043703:12202 ; Thu, 16 Jun 2011 16:04:37 +0200 From: "Denis Pinkas" To: "pkix" Date: Thu, 16 Jun 2011 16:04:37 +0200 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.6.8.6 References: X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 16/06/2011 16:04:37, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 16/06/2011 16:04:38, Serialize complete at 16/06/2011 16:04:38 Content-Type: multipart/alternative; boundary="----=_NextPart_11061616043719157165120_002" Subject: Re: [pkix] WGLC for draft-ietf-pkix-rfc5272-bis-03 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: denis.pinkas@bull.net List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 14:04:39 -0000 ------=_NextPart_11061616043719157165120_002 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ISO-8859-1" RG8geW91IHJlYWxseSBiZWxpZXZlIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gc2VuZCBhIGxhc3Qg Y2FsbCBvbiBhIGRvY3VtZW50IHdoaWNoIHN0aWxsIGNvbnRhaW5zOg0KNi4gIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zDQoNCiAgIFRvIGJlIHN1cHBsaWVkLg0KDQpEZW5pcw0KLS0tLS0gTWVzc2Fn ZSByZed1IC0tLS0tIA0KRGUgOiBwa2l4LWJvdW5jZXMgDQrAIDogcGtpeCANCkRhdGUgOiAyMDEx LTA2LTE2LCAxNTo1Mzo0Ng0KU3VqZXQgOiBbcGtpeF0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1wa2l4 LXJmYzUyNzItYmlzLTAzDQoNCg0KU3RhcnRzIHRvZGF5LiBDbG9zZXMgb24gNi8zMC4NCg0KU3Rl dmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwa2l4 IG1haWxpbmcgbGlzdA0KcGtpeEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wa2l4DQo= ------=_NextPart_11061616043719157165120_002 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="ISO-8859-1" PEhUTUw+PEhFQUQ+PFRJVExFPjwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJLc0RIVE1MRURMaWIu b2N4LCBGcmVlV2FyZSBIVE1MIEVkaXRvciAxLjE2NC4yLCCpIEt1cnQgU2VuZmVyIiANCm5hbWU9 R0VORVJBVE9SPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiIGxlZnRNYXJnaW49NSB0b3BNYXJnaW49NSANCiNm ZmZmZmY+DQo8UD5EbyB5b3UgcmVhbGx5IGJlbGlldmUgdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBz ZW5kJm5ic3A7YSBsYXN0IGNhbGwgb24gYSANCmRvY3VtZW50IHdoaWNoIHN0aWxsIGNvbnRhaW5z OjwvUD4NCjxQPjYuJm5ic3A7IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPEJSPjxCUj4mbmJzcDsm bmJzcDsgVG8gYmUgDQpzdXBwbGllZC48QlI+PEJSPkRlbmlzPC9QPg0KPEJMT0NLUVVPVEUgDQpz dHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6 IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+ DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVdFSUdIVDogbm9ybWFsOyBGT05ULVNJWkU6IDlwdDsg TElORS1IRUlHSFQ6IG5vcm1hbDsgRk9OVC1TVFlMRTogbm9ybWFsOyBGT05ULVZBUklBTlQ6IG5v cm1hbCI+LS0tLS0gDQogIE1lc3NhZ2UgcmXndSAtLS0tLSA8L0RJVj4NCiAgPERJViANCiAgc3R5 bGU9IkZPTlQtV0VJR0hUOiBub3JtYWw7IEZPTlQtU0laRTogOXB0OyBCQUNLR1JPVU5EOiAjZTRl NGU0OyBMSU5FLUhFSUdIVDogbm9ybWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtVkFSSUFO VDogbm9ybWFsOyBmb250LWNvbG9yOiBibGFjayI+PEI+RGUgDQogIDo8L0I+IDxBIGhyZWY9Im1h aWx0byA6cGtpeC1ib3VuY2VzQGlldGYub3JnIj5wa2l4LWJvdW5jZXM8L0E+IDwvRElWPg0KICA8 RElWIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IG5vcm1hbDsgRk9OVC1TSVpFOiA5cHQ7IExJTkUt SEVJR0hUOiBub3JtYWw7IEZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1WQVJJQU5UOiBub3JtYWwi PjxCPsAgDQogIDo8L0I+IDxBIGhyZWY9Im1haWx0byA6cGtpeEBpZXRmLm9yZyI+cGtpeDwvQT4g PC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVdFSUdIVDogbm9ybWFsOyBGT05ULVNJWkU6 IDlwdDsgTElORS1IRUlHSFQ6IG5vcm1hbDsgRk9OVC1TVFlMRTogbm9ybWFsOyBGT05ULVZBUklB TlQ6IG5vcm1hbCI+PEI+RGF0ZSANCiAgOjwvQj4gMjAxMS0wNi0xNiwgMTU6NTM6NDY8L0RJVj4N CiAgPERJViANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBub3JtYWw7IEZPTlQtU0laRTogOXB0OyBM SU5FLUhFSUdIVDogbm9ybWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtVkFSSUFOVDogbm9y bWFsIj48Qj5TdWpldCANCiAgOjwvQj4gW3BraXhdIFdHTEMgZm9yIGRyYWZ0LWlldGYtcGtpeC1y ZmM1MjcyLWJpcy0wMzwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAg PERJVj48L0RJVj4NCiAgPERJVj4NCiAgPERJVj5TdGFydHMgdG9kYXkuIENsb3NlcyBvbiANCiAg Ni8zMC48QlI+PEJSPlN0ZXZlPEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPEJSPnBraXggDQogIG1haWxpbmcgbGlzdDxCUj48QSBocmVmPSJtYWlsdG86 IHBraXhAaWV0Zi5vcmciPnBraXhAaWV0Zi5vcmc8L0E+PEJSPjxBIA0KICBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXgiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcGtpeDwvQT48QlI+PEJSPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9U RT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_11061616043719157165120_002-- From wwwrun@rfc-editor.org Thu Jun 16 11:02:22 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57BD11E8228 for ; Thu, 16 Jun 2011 11:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUELKCcwvldS for ; Thu, 16 Jun 2011 11:02:22 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE9811E8225 for ; Thu, 16 Jun 2011 11:02:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0D08898C4F6; Thu, 16 Jun 2011 11:02:22 -0700 (PDT) To: paul.hoffman@vpnc.org, jimsch@exmsft.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20110616180222.0D08898C4F6@rfc-editor.org> Date: Thu, 16 Jun 2011 11:02:22 -0700 (PDT) Cc: pkix@ietf.org, rfc-editor@rfc-editor.org Subject: [pkix] [Technical Errata Reported] RFC5912 (2839) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 18:02:22 -0000 The following errata report has been submitted for RFC5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=2839 -------------------------------------- Type: Technical Reported by: Carl Wallace Section: 14 Original Text ------------- Corrected Text -------------- Notes ----- anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 } does not appear in the PKIX1Implicit-2009 module. It appears in the body of RFC 5280 and in the corresponding ASN.1 module in RFC 5280. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5912 (draft-ietf-pkix-new-asn1-08) -------------------------------------- Title : New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) Publication Date : June 2010 Author(s) : P. Hoffman, J. Schaad Category : INFORMATIONAL Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From kent@bbn.com Mon Jun 20 10:13:01 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307AD11E8133 for ; Mon, 20 Jun 2011 10:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 P5pMZhgXrz9q for ; Mon, 20 Jun 2011 10:13:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 63CB011E80B5 for ; Mon, 20 Jun 2011 10:13:00 -0700 (PDT) Received: from dhcp89-089-178.bbn.com ([128.89.89.178]:49169) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QYi1s-000C6r-Ds; Mon, 20 Jun 2011 13:12:52 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110616180222.0D08898C4F6@rfc-editor.org> References: <20110616180222.0D08898C4F6@rfc-editor.org> Date: Mon, 20 Jun 2011 13:12:47 -0400 To: RFC Errata System From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: stefan@aaa-sec.com, paul.hoffman@vpnc.org, jimsch@exmsft.com, pkix@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (2839) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 17:13:01 -0000 At 11:02 AM -0700 6/16/11, RFC Errata System wrote: >The following errata report has been submitted for RFC5912, >"New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=2839 > >-------------------------------------- >Type: Technical >Reported by: Carl Wallace > >Section: 14 > >Original Text >------------- > > >Corrected Text >-------------- > > >Notes >----- >anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 } does >not appear in the PKIX1Implicit-2009 module. It appears in the body >of RFC 5280 and in the corresponding ASN.1 module in RFC 5280. OK. Noted. Steve From kent@bbn.com Fri Jun 24 08:56:42 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D188D9E8051 for ; Fri, 24 Jun 2011 08:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.237 X-Spam-Level: X-Spam-Status: No, score=-105.237 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, 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 VKlRzCKN0JIw for ; Fri, 24 Jun 2011 08:56:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3FB9E8041 for ; Fri, 24 Jun 2011 08:56:28 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:33802 helo=[192.168.1.12]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qa8k1-000EvF-MV for pkix@ietf.org; Fri, 24 Jun 2011 11:56:28 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 24 Jun 2011 11:55:58 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] Call for Agenda Items X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 15:56:42 -0000 Folks, We have a tentative PKIX slot at IETF 81 on Monday, from 1-3 PM, room 205 B. I will manage the agenda this time, so please send mail to me if you wish to request a slot. Thanks, Steve From kent@bbn.com Fri Jun 24 08:58:51 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492719E8050 for ; Fri, 24 Jun 2011 08:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.294 X-Spam-Level: X-Spam-Status: No, score=-106.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 zb4a6j7mleAu for ; Fri, 24 Jun 2011 08:58:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B69E29E8048 for ; Fri, 24 Jun 2011 08:58:50 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:47784 helo=[192.168.1.12]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qa8mQ-0003Xy-2f for pkix@ietf.org; Fri, 24 Jun 2011 11:58:50 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 24 Jun 2011 11:58:46 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] WGLC for draft-ietf-pkix-rfc5272-bis-03 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 15:58:51 -0000 Deni correctly noted that the Secuirity Consideration section for this draft is TBD. Since it is a "bis" I assume that Jim will be able to reuse the original SC text, with minor mods. So, the WGLC will continue, and I have asked Jim to supply the SC text. Sorry for the confusion, Steve From internet-drafts@ietf.org Thu Jun 30 04:07:14 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4D021F8734; Thu, 30 Jun 2011 04:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 Bq8IGS7TimcO; Thu, 30 Jun 2011 04:07:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2411F21F8724; Thu, 30 Jun 2011 04:07:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110630110714.11469.54312.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 04:07:14 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-cmp-transport-protocols-13.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 11:07:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : Internet X.509 Public Key Infrastructure -- HTTP Transpo= rt for CMP Author(s) : Tomi Kause Martin Peylo Filename : draft-ietf-pkix-cmp-transport-protocols-13.txt Pages : 17 Date : 2011-06-30 This document describes how to layer the Certificate Management Protocol over HTTP. It is the "CMPtrans" document referenced = in RFC 4210 and therefore updates the reference given therein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols= -13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-= 13.txt From peter.sylvester@edelweb.fr Thu Jun 30 08:45:36 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B96821F85AD for ; Thu, 30 Jun 2011 08:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 9AshuQuu1N50 for ; Thu, 30 Jun 2011 08:45:35 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD4811E8181 for ; Thu, 30 Jun 2011 08:45:33 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 9F9CA7DAF for ; Thu, 30 Jun 2011 17:45:32 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 7CB2616F64 for ; Thu, 30 Jun 2011 17:45:32 +0200 (CEST) Received: from [192.168.18.186] (unknown [192.168.18.186]) by smtps.on-x.com (Postfix) with ESMTP id 87592782B for ; Thu, 30 Jun 2011 17:45:32 +0200 (CEST) Message-ID: <4E0C9A45.8070407@edelweb.fr> Date: Thu, 30 Jun 2011 17:46:13 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pkix] EdelWeb timestampng end of service X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:45:36 -0000 Hello, this is to inform you that the URL http://www.edelweb.fr/cgi-bin/service-tsp will go out of service after many years of loyal service. Several editors of software and others have hard coded the old address as a default TSA in their software or configuration files. We are sorry for them. This URL has been deprecated since years, a good one can be found reading http://timestamping.edelweb.fr Thanks for your attention and sorry for the inconvenience of this message for those who are not interested in timestamping Peter Sylvester From mrex@sap.com Thu Jun 30 10:46:37 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3881211E82A5 for ; Thu, 30 Jun 2011 10:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.212 X-Spam-Level: X-Spam-Status: No, score=-10.212 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 i-mUfvRtAa7v for ; Thu, 30 Jun 2011 10:46:36 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C008811E82A4 for ; Thu, 30 Jun 2011 10:46:35 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p5UHkXmF014944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Jun 2011 19:46:33 +0200 (MEST) From: Martin Rex Message-Id: <201106301746.p5UHkXYV014149@fs4113.wdf.sap.corp> To: peter.sylvester@edelweb.fr (Peter Sylvester) Date: Thu, 30 Jun 2011 19:46:32 +0200 (MEST) In-Reply-To: <4E0C9A45.8070407@edelweb.fr> from "Peter Sylvester" at Jun 30, 11 05:46:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: [pkix] rfc3161 TimeStamps and sha1-based sigs/imprints in pkcs7/cms X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 17:46:37 -0000 Peter Sylvester wrote: > > We are sorry for them. This URL has been deprecated > since years, a good one can be found reading > > http://timestamping.edelweb.fr > > Thanks for your attention and sorry for the inconvenience > of this message for those who are not interested in timestamping Speaking of rfc3161 timestamping, most public services seem to be limited to sha1WithRsaEncryption { 1, 2, 840, 113549, 1, 1, 5 } which looks like an anachronism and a security problem to me. Are the proposals or is there a standard how to migrate to a more resonable signature algorithm such as sha256WithRsaEncryption { 1, 2, 840, 113549, 1, 1, 11 } e.g. when the MessageImprint uses SHA256? While requesting this feature explicitly through a specific TSA policy OID would theoretically be possible, this very same approach would be quite non-portable. The original plan was to _have_completed_ phasing out the use of SHA-1 for digital signatures by the end of 2010, but that target seems to have been missed entirely. There is a significant availability of RSA 2048-bit certificates, but the use of sha256WithRsaEncryption is still at homeopathic levels. The purpose of rfc3161 timestamps is to prove that something existed before or at a certain time, and the two most common uses I can think of are: - determine whether a digital signature was created within the validity period of the signer certificate - determine whether a digital signature was created before the point in time when the signer certificate was revoked Both these cases, a purposes looking into the future, sometimes far into the future (think e.g. about signed×tamped code), and I seriously question the security of timestamps with sha1-based signatures (or sha1-based message imprints or the original, often indirect signatures on the underlying pkcs7/CMS) for purposes with a useful lifetime of many years into the future. -Martin From peter.sylvester@edelweb.fr Thu Jun 30 21:22:35 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF3421F872C for ; Thu, 30 Jun 2011 21:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Su3QyusxN+e6 for ; Thu, 30 Jun 2011 21:22:33 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 66E0821F872A for ; Thu, 30 Jun 2011 21:22:33 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 3E7B97DBA; Fri, 1 Jul 2011 06:22:32 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id DA50216F64; Fri, 1 Jul 2011 06:22:31 +0200 (CEST) Received: from [78.251.36.87] (unknown [78.251.36.87]) by smtps.on-x.com (Postfix) with ESMTP id 1AF9A782B; Fri, 1 Jul 2011 06:22:30 +0200 (CEST) Message-ID: <4E0D4B85.1030407@edelweb.fr> Date: Fri, 01 Jul 2011 06:22:29 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: mrex@sap.com References: <201106301746.p5UHkXYV014149@fs4113.wdf.sap.corp> In-Reply-To: <201106301746.p5UHkXYV014149@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] rfc3161 TimeStamps and sha1-based sigs/imprints in pkcs7/cms X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 04:22:35 -0000 signing/finishing a contract on paper and leaving it near/in a cloud ? you don't do that in the paperworld. On 06/30/2011 07:46 PM, Martin Rex wrote: > Peter Sylvester wrote: >> We are sorry for them. This URL has been deprecated >> since years, a good one can be found reading >> >> http://timestamping.edelweb.fr >> >> Thanks for your attention and sorry for the inconvenience >> of this message for those who are not interested in timestamping > Speaking of rfc3161 timestamping, most public services seem to > be limited to sha1WithRsaEncryption { 1, 2, 840, 113549, 1, 1, 5 } > which looks like an anachronism and a security problem to me. > > Are the proposals or is there a standard how to migrate to > a more resonable signature algorithm such as > sha256WithRsaEncryption { 1, 2, 840, 113549, 1, 1, 11 } > > e.g. when the MessageImprint uses SHA256? > > While requesting this feature explicitly through a specific > TSA policy OID would theoretically be possible, this very > same approach would be quite non-portable. > > The original plan was to _have_completed_ phasing out the use of SHA-1 > for digital signatures by the end of 2010, but that target seems to > have been missed entirely. There is a significant availability of > RSA 2048-bit certificates, but the use of sha256WithRsaEncryption > is still at homeopathic levels. > > > The purpose of rfc3161 timestamps is to prove that something existed > before or at a certain time, and the two most common uses I can > think of are: > > - determine whether a digital signature was created within > the validity period of the signer certificate > > - determine whether a digital signature was created before > the point in time when the signer certificate was revoked > > Both these cases, a purposes looking into the future, sometimes > far into the future (think e.g. about signed×tamped code), > and I seriously question the security of timestamps with > sha1-based signatures (or sha1-based message imprints or the > original, often indirect signatures on the underlying pkcs7/CMS) > for purposes with a useful lifetime of many years into the future. > > > -Martin >