From James.H.Manger@team.telstra.com Sun Dec 2 16:13:32 2012 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 3DD1621F8903 for ; Sun, 2 Dec 2012 16:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.028 X-Spam-Level: X-Spam-Status: No, score=0.028 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 EYa86aq4XYnF for ; Sun, 2 Dec 2012 16:13:31 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7375D21F88F4 for ; Sun, 2 Dec 2012 16:13:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,359,1352034000"; d="scan'208";a="111915653" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 03 Dec 2012 11:13:30 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6914"; a="101365364" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcbni.tcif.telstra.com.au with ESMTP; 03 Dec 2012 11:13:30 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Mon, 3 Dec 2012 11:13:30 +1100 From: "Manger, James H" To: pkix mailing list , Phillip Hallam-Baker Date: Mon, 3 Dec 2012 11:13:28 +1100 Thread-Topic: CAA ABNF Thread-Index: Ac3MHhIoNqThfw5eRMWTTE+EUglZ6QAdaHqQART5iYA= Message-ID: <255B9BB34FB7D647A506DC292726F6E115028CD38C@WSMSG3153V.srv.dir.telstra.com> References: <20121126213608.17569.30919.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E1150252B6F3@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150252B6F3@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [pkix] CAA ABNF 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, 03 Dec 2012 00:13:32 -0000 T25lIG1vcmUgdGVjaG5pY2FsIHR5cG8gaW4gZHJhZnQtaWV0Zi1wa2l4LWNhYTogdGhlIEFCTkYg aW4gc2VjdGlvbiA1LjIgIkNBQSBpc3N1ZSBQcm9wZXJ0eSIgZm9yIHBhcmFtZXRlcnMgaXMgbm90 IHF1aXRlIHJpZ2h0LiA8dmFsdWU+IGlzIDwqVkNIQVI+LCB3aGljaCBhbGxvd3MgIjsiLCB3aGlj aCBpcyBhbWJpZ3VvdXMgd2l0aCAiOyIgYXMgYSBzZXBhcmF0b3Igb2YgPHBhcmFtZXRlcj5zLg0K DQpGb3IgaW5zdGFuY2UsIGRvZXMgdGhlIGZvbGxvd2luZyBDQUEgUlIgdmFsdWUgaGF2ZSAxIHBh cmFtZXRlciAod2l0aCB2YWx1ZSAiMzQ7YmFyPTEiKSBvciAyIHBhcmFtZXRlcnM/DQoNCiAgQ0FB IDAgaXNzdWUgImNhLmV4YW1wbGUubmV0OyBmb289MzQ7YmFyPTEiDQoNCkdpdmVuIHRoYXQgZXZl cnl0aGluZyBhZnRlciB0aGUgZmlyc3QgIjsiIGlzIG5vbi1zdGFuZGFyZCwgdGhlIENBQSBzcGVj IGNvdWxkIGRlZmluZSB0aGUgImlzc3VlIiBwcm9wZXJ0eSdzIHZhbHVlIGFzOg0KDQogIGlzc3Vl LXZhbCA9IHNwYWNlIFtkb21haW5dIHNwYWNlIFsiOyIgZXh0cmFdDQoNCiAgZXh0cmEgPSAqVkNI QVINCg0KQWx0ZXJuYXRpdmUsIGNoYW5nZSA8dmFsdWU+IGZyb20gPCpWQ0hBUj4gdG8gPCV4MjEt M0EgLyAleDNDLTdFPi4NCiAgDQoNCkRvZXMgYW55IGV4dHJhIHBhcnQgYWZ0ZXIgdGhlIGRvbWFp biBuZWVkIHRvIGJlIHVuZGVyc3Rvb2QgaWYgdGhlIGNyaXRpY2FsIGZsYWcgaXMgc2V0PyBGb3Ig aW5zdGFuY2UsIGlzIHJlZC1jYS5leGFtcGxlIGFsbG93ZWQgdG8gaXNzdWUgYSBjZXJ0IGlmIGl0 IGRvZXNuJ3QgdW5kZXJzdGFuZCB0aGUgImZvbyIgcGFyYW1ldGVyIGdpdmVuIHRoZXNlIENBQSBy ZWNvcmRzPyBJIHRoaW5rIHVuZGVyc3RhbmRpbmcgImlzc3VlIiBpcyBzdWZmaWNpZW50IHNvIHJl ZC1jYSBtYXkgaXNzdWUgdGhlIGNlcnQuIENhbiBjYS5leGFtcGxlLm5ldCBpc3N1ZSBhIGNlcnQg aWYgaXQgZG9lc24ndCB1bmRlcnN0YW5kICJmb28iPyBNaWdodCBiZSB3b3J0aCBleHBsaWNpdGx5 IG1lbnRpb25pbmcgaW4gdGhlIHNwZWMuDQoNCiAgQ0FBIDEyOCBpc3N1ZSAiY2EuZXhhbXBsZS5u ZXQ7IGZvbz0zNCINCiAgQ0FBICAgMCBpc3N1ZSAicmVkLWNhLmV4YW1wbGUiDQoNCi0tDQpKYW1l cyBNYW5nZXINCg0K From bergtau@gmail.com Tue Dec 4 20:55:19 2012 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 0344F21F8C0D for ; Tue, 4 Dec 2012 20:55:19 -0800 (PST) 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 Bky5RWLNnoyg for ; Tue, 4 Dec 2012 20:55:17 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3F021F8BC1 for ; Tue, 4 Dec 2012 20:55:17 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so7996562ieb.31 for ; Tue, 04 Dec 2012 20:55:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DAgeRy9TNTxVTJmgA9yTtJqM3ihVuc6ahd4tovS7zCE=; b=1DjoqxpKtguxTWck9i1OLy53F1lx2mlH7uJf0FWg5y4+maE5NwXvBtHnBBGPlqn/C5 knYhO+PFcdRzFXbyxJDBF++eY302wKXD5MzLPZ+r8uSxcouB9u36fzf9U95Z+0FZKKNz E48h6JH669E5LnAPcogLQSli3NwDJWekV20eT6nFNk9i84qebNbuk1pd/NzvC9+B6L5s 20E4v+gbnHahq/7SrFXt1RdzBrmKz1c5jeDei5k+8wIgmeCccLlCa1PWTvB/bE6s54ZE RZsVN2M09a+b2/t7ZQ/0LlfKocABiuIoHXfz1mt3/EjJTpnnUrxof5B/vnPisCqEfZ5v 2eEQ== MIME-Version: 1.0 Received: by 10.42.51.207 with SMTP id f15mr13161112icg.16.1354683316940; Tue, 04 Dec 2012 20:55:16 -0800 (PST) Received: by 10.64.11.1 with HTTP; Tue, 4 Dec 2012 20:55:16 -0800 (PST) In-Reply-To: <53EA47528D6ACF4486AA152F92C2B6982E9D7E@xmb-rcd-x03.cisco.com> References: <50AA956B.10000@gmail.com> <53EA47528D6ACF4486AA152F92C2B6982E9D7E@xmb-rcd-x03.cisco.com> Date: Tue, 4 Dec 2012 23:55:16 -0500 Message-ID: From: Michael Jenkins To: "Max Pritikin (pritikin)" Content-Type: multipart/alternative; boundary=20cf301cc2c8e3b0fa04d013c924 Cc: "" , "" Subject: Re: [pkix] EST trust anchor definition 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, 05 Dec 2012 04:55:19 -0000 --20cf301cc2c8e3b0fa04d013c924 Content-Type: text/plain; charset=ISO-8859-1 I think that the tables, broken out according to TAs and Certs, are a big improvement. However, the TA table has really taken a hard turn /away/ from the ability to specify a single TA as the one to use for EST. Without digging through a lot of cert guts over and over, I'll never know if any particular validation is terminating in the selected TA, be it a provided vendor-supplied initialization root, or a "public" CA, or a locally supplied root. I'm not prejudiced toward one or the other of those options, as long as it's the one I've initially configured - that is, as long as I have a way of expressing which TA must terminate my EST transactions. Ideally that would happen through some kind of labeling, but I don't think that there's anything that does that now, natively, in a system trust anchor store. Other solutions would be to remove all trust anchors /except/ the selected one (drastic, but might work for some specific-use devices), or to configure the EST client app with a keyID for the selected trust anchor (and then check that it's the one used). The draft does say that the client needs to be configured with the correct trust anchor (through out-of-band means), but after that all references to TAs are "TA Database". If I can't guarantee that I'm using the TA that I configured, there was no point in configuring one. Hope that makes sense. If I'm interpreting the table incorrectly, let me know where I went wrong. Mike On Mon, Nov 19, 2012 at 3:56 PM, Max Pritikin (pritikin) wrote: > Thanks for all the feedback. We've already updated the table similar to > what you recommend below so its good to see we're on the same page. > > Below is the current table in our working copy. I'll read through your > suggestions carefully to see if additional clarity can be gained. > > Similarly I'll go through you other email of specific feedback and merge > them to the revisions we've made since the ietf85 meeting. > > - max > > Current table in our working revision (best viewed in monospaced font): > > Certificates and their corresponding uses: > +--------------+--------------------+-------------------------------+ > | Certificate | Issuer | Use and section references | > +==============+====================+===============================+ > | EST server | The CA served by | Presented by the EST server | > | certificate | the EST server | during the TLS handshake | > | | | | > | | | Section 3.3.1.1 | > +--------------+--------------------+-------------------------------+ > | EST server | A CA | Presented by the EST server | > | certificate | authenticatable by | during the TLS handshake | > | | a third-party TA | | > | | | Section 3.3.1.1, and | > | | | Security Considerations | > +--------------+--------------------+-------------------------------+ > | EST client | A CA | Presented by the EST client | > | certificate | authenticatable by | to the EST server by clients | > | | a third-party TA | that have not yet enrolled | > | | e.g., a device | | > | | manufacturer | Section 3.3.1.2 | > +--------------+--------------------+-------------------------------+ > | EST client | The CA served by | Presented by the EST client | > | certificate | the EST server | to PKI End Entities. | > | | | Including to the EST server | > | | | during future EST operations | > | | | | > | | | Section 3.3.1.2 | > +--------------+--------------------+-------------------------------+ > | EST client | The CA served by | Presented by the EST client | > | certificate | the EST server | to PKI End Entities. | > | | | Clients can obtain certs | > | | | that can not be used for EST | > | | | client authentication | > | | | | > | | | Section 4.4.1 | > +--------------+--------------------+-------------------------------+ > > > Figure 3 > > > > > > > > > > > > > Pritikin, et al. Expires May 21, 2013 [Page 12] > Internet-Draft EST November 2012 > > > Trust Anchor databases and their corresponding uses: > +--------------+----------------------------------------------------+ > | TA database | Use and section references | > +==============+====================================================+ > | EST server | EST servers use this TA database to authenticate | > | TA database | certificates issued by the CA, including EST | > | | client certificates during enroll/re-enroll | > | | operations | > | | | > | | Section 3.3.1.2 | > +--------------+----------------------------------------------------+ > | EST server | EST servers use this TA database to authenticate | > | Third-Party | certificates issued by third-party TAs. | > | TA database | e.g., EST client certificates issued by a device | > | | manufacturer | > | | | > | | Section 3.3.1.2 | > +--------------+----------------------------------------------------+ > | EST client | EST clients use this TA database to authenticate | > | EST CA | certificates issued by the EST CA, including EST | > | TA database | server certificates. | > | | | > | | Section 3.3.1.1 and | > | | Section 4.3 | > +--------------+----------------------------------------------------+ > | EST client | EST clients use this trust anchor database to | > | Third-Party | authenticate an EST server that uses an externally | > | TA database | issued certificate. | > | | | > | | | > | | Section 3.3.1.1 and | > | | Security Considerations | > +--------------+----------------------------------------------------+ > > > Figure 4 > > On Nov 19, 2012, at 1:24 PM, M Jenkins > wrote: > > I think that the current EST draft is weak when it comes to talking about > trust anchors. Many of the right ideas are there, but a bit scattered > about. Figure (Table) 3 has a lot of this information, but there's some > fuzz in it, and it's not very explicit about how crucial TA initialization > is to the security of the protocol. > > A specific concern is a perception that *any* trust anchor that happens to > be in a trust anchor store might be used to terminate a certificate > validation chain. The use of the phrase "third party Trust Anchor Database" > is worrisome. Who cares if the TA comes from any (acceptable) third party - > if you can't ensure that your validation chain is going to terminate in > that TA in the first place? The present state of TA store management > doesn't inherently provide this selectability. I think that explicit text > is needed here. > > I would suggest that table in Figure 3 be replaced with something like the > following: > > Trust Anchors > +--------------------------------------------------------------+ > | NOTE: EST Servers and Clients must be initialized to know | > | which specific public keys in their trust anchor | > | stores correspond to which function from this table. | > +---------------+----------------------------------------------+ > | CA Root | * End of validation path of all CA certs | > | public key | * End of validation path of Device Cert | > | | * May be identical to EST Server TA | > | | * May be identical to EST Client TA > | | * Obtainable by /CACerts command | > +---------------+----------------------------------------------+ > | EST Server TA | * End of validation path of EST Server cert | > | | * Must be securely installed to EST Client | > | | * Must be obtained securely, out-of-band | > +---------------+----------------------------------------------+ > | EST Client TA | * End of valid. path of EST Client init cert | > | | * Must be securely installed to EST Server | > | | * Must be obtained securely, out-of-band | > +---------------+----------------------------------------------+ > > Certificates > +---------------+----------------------------------------------+ > | CA Signing | * Crsp. private key signs Device Cert | > | Certificate | * Intermediate CA certs may exist in path | > | | * Obtainable by /CACerts command | > | | * Must be validated against CA Root > +---------------+----------------------------------------------+ > | EST Server | * Used by EST Client during TLS handshake | > | Certificate | * Must be validated against EST Server TA | > +---------------+----------------------------------------------+ > | EST Client | * Used by EST Server during initial enroll | > | Init Cert | (if certificate TLS auth used) | > | | * Must be validated against EST Client TA > +---------------+----------------------------------------------+ > | Device Cert | * Any certificate returned as a result of | > | | /simpleEnroll, /simpleReEnroll, /fullCMC, | > | | or /serverKeyGen | > | | * May be used for subsequent EST sessions | > +---------------+----------------------------------------------+ > | NOTE: The CA, EST Server, EST Client, and other servers may | > | have other certificates for other purposes, including | > | inter-server communication during EST sessions. | > +--------------------------------------------------------------+ > > Mike > > > --20cf301cc2c8e3b0fa04d013c924 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think that the tables, broken out according to TAs and Certs, are a = big improvement. However, the TA table has really taken a hard turn /away/ = from the ability to specify a single TA as the one to use for EST. Without = digging through a lot of cert guts over and over, I'll never know if an= y particular validation is terminating in the selected TA, be it a provided= vendor-supplied initialization root, or a "public" CA, or a loca= lly supplied root. I'm not prejudiced toward one or the other of those = options, as long as it's the one I've initially configured - that i= s, as long as I have a way of expressing which TA must terminate my EST tra= nsactions.

Ideally that would happen through some kind of la= beling, but I don't think that there's anything that does that now,= natively, in a system trust anchor store. Other solutions would be to remo= ve all trust anchors /except/ the selected one (drastic, but might work for= some specific-use devices), or to configure the EST client app with a keyI= D for the selected trust anchor (and then check that it's the one used)= .

The draft does say that the client needs to be configur= ed with the correct trust anchor (through out-of-band means), but after tha= t all references to TAs are "TA Database". If I can't guarant= ee that I'm using the TA that I configured, there was no point in confi= guring one.

Hope that makes sense. If I'm interpreting the tabl= e incorrectly, let me know where I went wrong.

Mik= e


On Mon= , Nov 19, 2012 at 3:56 PM, Max Pritikin (pritikin) <pritikin@cisco.com> wrote:
Thanks for all the feedback. We've already updated the table similar to= what you recommend below so its good to see we're on the same page.=A0

Below is the current table in our working copy. I'll read through = your suggestions carefully to see if additional clarity can be gained.=A0

Similarly I'll go through you other email of specific feedback and= merge them to the revisions we've made since the ietf85 meeting.=A0

- max

Current table in our working revision (best viewed in monospaced font)= :

=A0 =A0Certificates and their corresponding uses:=
=A0 =A0+--------------+--------------------+-------------------------------= +
=A0 =A0| Certificate =A0| Issuer =A0 =A0 =A0 =A0 =A0 =A0 | Use and section = references =A0 =A0|
=A0 =A0+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
=A0 =A0| EST server =A0 | The CA served by =A0 | Presented by the EST serve= r =A0 |
=A0 =A0| certificate =A0| the EST server =A0 =A0 | during the TLS handshake= =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| Section 3.3.1.1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0+--------------+--------------------+-------------------------------= +
=A0 =A0| EST server =A0 | A CA =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Presented by t= he EST server =A0 |
=A0 =A0| certificate =A0| authenticatable by | during the TLS handshake =A0= =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| a third-party TA =A0 | =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| Section 3.3.1.1, and =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| Security Considerations =A0 =A0 =A0 |
=A0 =A0+--------------+--------------------+-------------------------------= +
=A0 =A0| EST client =A0 | A CA =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Presented by t= he EST client =A0 |
=A0 =A0| certificate =A0| authenticatable by | to the EST server by clients= =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| a third-party TA =A0 | that have not = yet enrolled =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| e.g., a device =A0 =A0 | =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| manufacturer =A0 =A0 =A0 | Section 3.= 3.1.2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0+--------------+--------------------+-------------------------------= +
=A0 =A0| EST client =A0 | The CA served by =A0 | Presented by the EST clien= t =A0 |
=A0 =A0| certificate =A0| the EST server =A0 =A0 | to PKI End Entities. =A0= =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| Including to the EST server =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| during future EST operations =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| Section 3.3.1.2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0+--------------+--------------------+-------------------------------= +
=A0 =A0| EST client =A0 | The CA served by =A0 | Presented by the EST clien= t =A0 |
=A0 =A0| certificate =A0| the EST server =A0 =A0 | to PKI End Entities. =A0= =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| Clients can obtain certs =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| that can not be used for EST =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| client authentication =A0 =A0 =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| Section 4.4.1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0+--------------+--------------------+-------------------------------= +


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Figure 3=












Pritikin, et al. =A0 =A0 =A0 =A0 =A0Expires May 21, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 [Page 12]
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EST =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 November 2012


=A0 =A0Trust Anchor databases and their corresponding uses:
=A0 =A0+--------------+----------------------------------------------------= +
=A0 =A0| TA database =A0| Use and section references =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
=A0 =A0| EST server =A0 | EST servers use this TA database to authenticate = =A0 |
=A0 =A0| TA database =A0| certificates issued by the CA, including EST =A0 = =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| client certificates during enroll/re-= enroll =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| operations =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| Section 3.3.1.2 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0+--------------+----------------------------------------------------= +
=A0 =A0| EST server =A0 | EST servers use this TA database to authenticate = =A0 |
=A0 =A0| Third-Party =A0| certificates issued by third-party TAs. =A0 =A0 = =A0 =A0 =A0 =A0|
=A0 =A0| TA database =A0| e.g., EST client certificates issued by a device = =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| manufacturer =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| Section 3.3.1.2 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0+--------------+----------------------------------------------------= +
=A0 =A0| EST client =A0 | EST clients use this TA database to authenticate = =A0 |
=A0 =A0| EST CA =A0 =A0 =A0 | certificates issued by the EST CA, including = EST =A0 |
=A0 =A0| TA database =A0| server certificates. =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| Section 3.3.1.1 and =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| Section 4.3 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0+--------------+----------------------------------------------------= +
=A0 =A0| EST client =A0 | EST clients use this trust anchor database to =A0= =A0 =A0|
=A0 =A0| Third-Party =A0| authenticate an EST server that uses an externall= y |
=A0 =A0| TA database =A0| issued certificate. =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| Section 3.3.1.1 and =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0| Security Considerations =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0+--------------+----------------------------------------------------= +


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Figure 4=

On Nov 19, 2012, at 1:24 PM, M Jenkins <bergtau@gmail.com>
=A0wrote:

I think that the current EST draft is weak when i= t comes to talking about trust anchors. Many of the right ideas are there, = but a bit scattered about. Figure (Table) 3 has a lot of this information, = but there's some fuzz in it, and it's not very explicit about how crucial TA initialization is to the security o= f the protocol.

A specific concern is a perception that *any* trust anchor that happens to = be in a trust anchor store might be used to terminate a certificate validat= ion chain. The use of the phrase "third party Trust Anchor Database&qu= ot; is worrisome. Who cares if the TA comes from any (acceptable) third party - if you can't ensure that your vali= dation chain is going to terminate in that TA in the first place? The prese= nt state of TA store management doesn't inherently provide this selecta= bility. I think that explicit text is needed here.

I would suggest that table in Figure 3 be replaced with something like the = following:

Trust Anchors
+--------------------------------------------------------------+
| NOTE: EST Servers and Clients must be initialized to know =A0=A0=A0|
| =A0=A0=A0=A0=A0=A0which specific public keys in their trust anchor =A0=A0= =A0=A0=A0=A0|
| =A0=A0=A0=A0=A0=A0stores correspond to which function from this table. = =A0=A0|
+---------------+----------------------------------------------+
| CA Root =A0=A0=A0=A0=A0=A0| * End of validation path of all CA certs =A0= =A0=A0=A0|
| =A0public key =A0=A0| * End of validation path of Device Cert =A0=A0=A0= =A0=A0|
| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| * May be identical to EST Ser= ver TA =A0=A0=A0=A0=A0=A0=A0=A0=A0|
| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| * May be identical to EST Cli= ent TA
| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| * Obtainable by /CACerts comm= and =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|
+---------------+----------------------------------------------+
| EST Server TA | * End of validation path of EST Server cert =A0|
| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| * Must be securely installed = to EST Client =A0=A0|
| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| * Must be obtained securely, = out-of-band =A0=A0=A0=A0|
+---------------+----------------------------------------------+
| EST Client TA | * End of valid. path of EST Client init cert |
| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| * Must be securely installed = to EST Server =A0=A0|
| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| * Must be obtained securely, = out-of-band =A0=A0=A0=A0|
+---------------+----------------------------------------------+

Certificates
+---------------+----------------------------------------------+
| CA Signing =A0=A0=A0| * Crsp. private key signs Device Cert =A0=A0=A0=A0= =A0=A0=A0|
| =A0Certificate =A0| * Intermediate CA certs may exist in path =A0=A0=A0|<= br> | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| * Obtainable by /CACerts comm= and =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|
| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| * Must be validated against C= A Root
+---------------+----------------------------------------------+
| EST Server =A0=A0=A0| * Used by EST Client during TLS handshake =A0=A0=A0= |
| =A0Certificate =A0| * Must be validated against EST Server TA =A0=A0=A0|<= br> +---------------+----------------------------------------------+
| EST Client =A0=A0=A0| * Used by EST Server during initial enroll =A0=A0|<= br> | =A0Init Cert =A0=A0=A0| =A0=A0=A0(if certificate TLS auth used) =A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0|
| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| * Must be validated against E= ST Client TA
+---------------+----------------------------------------------+
| Device Cert =A0=A0| * Any certificate returned as a result of =A0=A0=A0|<= br> | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| =A0=A0=A0/simpleEnroll, /simp= leReEnroll, /fullCMC, |
| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| =A0=A0=A0or /serverKeyGen =A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0| * May be used for subsequent = EST sessions =A0=A0=A0|
+---------------+----------------------------------------------+
| NOTE: The CA, EST Server, EST Client, and other servers may =A0|
| =A0=A0=A0=A0=A0=A0have other certificates for other purposes, including = =A0|
| =A0=A0=A0=A0=A0=A0inter-server communication during EST sessions. =A0=A0= =A0=A0=A0=A0=A0|
+--------------------------------------------------------------+

Mike


--20cf301cc2c8e3b0fa04d013c924-- From pritikin@cisco.com Wed Dec 5 14:51:01 2012 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 2A94A21F8CE7 for ; Wed, 5 Dec 2012 14:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 IF2G9822Ofb4 for ; Wed, 5 Dec 2012 14:51:00 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D1C5821F8C64 for ; Wed, 5 Dec 2012 14:50:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12479; q=dns/txt; s=iport; t=1354747860; x=1355957460; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ADU1KLMJ07ov/IPh7YYS7+yax3Ft4X/4p+Q8b6w/Hes=; b=l7sf6e9fF6c2pUyjg8dK18yLVDPMPABVruKd59Be2Myfs7a6duQkliFa UaOGISQuWV0kQaUYOjfXocxi75rIoYgD3RjopEoSRMPCskUT2wVmVuSvs vxXr6AvJIjLv+A5nBorT5l6vKhQCmv9g5gdJ5cjdsS3vkvZpGqm4/TiBr w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAETOv1CtJXHB/2dsb2JhbABEviQWc4IeAQEBAwFsDQULAgEIDgoKJCERJQIEDgUIE4djAwkGuQ0NiVSLTmkLg1VhA4gqjAONDYUQgnKBZQcXBhg X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149882490" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 05 Dec 2012 22:50:59 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qB5Moxvn020597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Dec 2012 22:50:59 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.191]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 16:50:58 -0600 From: "Max Pritikin (pritikin)" To: Michael Jenkins Thread-Topic: EST trust anchor definition Thread-Index: AQHNxpPc6GwWl6LMpkqCCG9K56Si9pfyCDwAgBgYoACAASywAA== Date: Wed, 5 Dec 2012 22:50:58 +0000 Message-ID: <53EA47528D6ACF4486AA152F92C2B698B90D43@xmb-rcd-x03.cisco.com> References: <50AA956B.10000@gmail.com> <53EA47528D6ACF4486AA152F92C2B6982E9D7E@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.0.223] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [pkix] EST trust anchor definition 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, 05 Dec 2012 22:51:01 -0000 On Dec 4, 2012, at 9:55 PM, Michael Jenkins wrote: > I think that the tables, broken out according to TAs and Certs, are a big= improvement. However, the TA table has really taken a hard turn /away/ fro= m the ability to specify a single TA as the one to use for EST. What prevents the client from having a "Third-Party TA Database" that conta= ins only TA's (or a single TA) to be used for EST? > Without digging through a lot of cert guts over and over, I'll never know= if any particular validation is terminating in the selected TA, be it a pr= ovided vendor-supplied initialization root, or a "public" CA, or a locally = supplied root. I'm not prejudiced toward one or the other of those options,= as long as it's the one I've initially configured - that is, as long as I = have a way of expressing which TA must terminate my EST transactions. >=20 > Ideally that would happen through some kind of labeling, but I don't thin= k that there's anything that does that now, natively, in a system trust anc= hor store. Other solutions would be to remove all trust anchors /except/ th= e selected one (drastic, but might work for some specific-use devices), or = to configure the EST client app with a keyID for the selected trust anchor = (and then check that it's the one used). >=20 > The draft does say that the client needs to be configured with the correc= t trust anchor (through out-of-band means), but after that all references t= o TAs are "TA Database". If I can't guarantee that I'm using the TA that I = configured, there was no point in configuring one. We can make this the "selected TA Database" and we can indicate that: "The Client MUST support a configurable option to enable checking all or a subset of either the EST client Third-Party TA database or the EST client TA database." Would that address your concerns? - max >=20 > Hope that makes sense. If I'm interpreting the table incorrectly, let me = know where I went wrong. >=20 > Mike >=20 >=20 > On Mon, Nov 19, 2012 at 3:56 PM, Max Pritikin (pritikin) wrote: > Thanks for all the feedback. We've already updated the table similar to w= hat you recommend below so its good to see we're on the same page.=20 >=20 > Below is the current table in our working copy. I'll read through your su= ggestions carefully to see if additional clarity can be gained.=20 >=20 > Similarly I'll go through you other email of specific feedback and merge = them to the revisions we've made since the ietf85 meeting.=20 >=20 > - max >=20 > Current table in our working revision (best viewed in monospaced font): >=20 > Certificates and their corresponding uses: > +--------------+--------------------+-------------------------------+ > | Certificate | Issuer | Use and section references | > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > | EST server | The CA served by | Presented by the EST server | > | certificate | the EST server | during the TLS handshake | > | | | | > | | | Section 3.3.1.1 | > +--------------+--------------------+-------------------------------+ > | EST server | A CA | Presented by the EST server | > | certificate | authenticatable by | during the TLS handshake | > | | a third-party TA | | > | | | Section 3.3.1.1, and | > | | | Security Considerations | > +--------------+--------------------+-------------------------------+ > | EST client | A CA | Presented by the EST client | > | certificate | authenticatable by | to the EST server by clients | > | | a third-party TA | that have not yet enrolled | > | | e.g., a device | | > | | manufacturer | Section 3.3.1.2 | > +--------------+--------------------+-------------------------------+ > | EST client | The CA served by | Presented by the EST client | > | certificate | the EST server | to PKI End Entities. | > | | | Including to the EST server | > | | | during future EST operations | > | | | | > | | | Section 3.3.1.2 | > +--------------+--------------------+-------------------------------+ > | EST client | The CA served by | Presented by the EST client | > | certificate | the EST server | to PKI End Entities. | > | | | Clients can obtain certs | > | | | that can not be used for EST | > | | | client authentication | > | | | | > | | | Section 4.4.1 | > +--------------+--------------------+-------------------------------+ >=20 >=20 > Figure 3 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Pritikin, et al. Expires May 21, 2013 [Page 12] > Internet-Draft EST November 2012 >=20 >=20 > Trust Anchor databases and their corresponding uses: > +--------------+----------------------------------------------------+ > | TA database | Use and section references | > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > | EST server | EST servers use this TA database to authenticate | > | TA database | certificates issued by the CA, including EST | > | | client certificates during enroll/re-enroll | > | | operations | > | | | > | | Section 3.3.1.2 | > +--------------+----------------------------------------------------+ > | EST server | EST servers use this TA database to authenticate | > | Third-Party | certificates issued by third-party TAs. | > | TA database | e.g., EST client certificates issued by a device | > | | manufacturer | > | | | > | | Section 3.3.1.2 | > +--------------+----------------------------------------------------+ > | EST client | EST clients use this TA database to authenticate | > | EST CA | certificates issued by the EST CA, including EST | > | TA database | server certificates. | > | | | > | | Section 3.3.1.1 and | > | | Section 4.3 | > +--------------+----------------------------------------------------+ > | EST client | EST clients use this trust anchor database to | > | Third-Party | authenticate an EST server that uses an externally | > | TA database | issued certificate. | > | | | > | | | > | | Section 3.3.1.1 and | > | | Security Considerations | > +--------------+----------------------------------------------------+ >=20 >=20 > Figure 4 >=20 > On Nov 19, 2012, at 1:24 PM, M Jenkins > wrote: >=20 >> I think that the current EST draft is weak when it comes to talking abou= t trust anchors. Many of the right ideas are there, but a bit scattered abo= ut. Figure (Table) 3 has a lot of this information, but there's some fuzz i= n it, and it's not very explicit about how crucial TA initialization is to = the security of the protocol. >>=20 >> A specific concern is a perception that *any* trust anchor that happens = to be in a trust anchor store might be used to terminate a certificate vali= dation chain. The use of the phrase "third party Trust Anchor Database" is = worrisome. Who cares if the TA comes from any (acceptable) third party - if= you can't ensure that your validation chain is going to terminate in that = TA in the first place? The present state of TA store management doesn't inh= erently provide this selectability. I think that explicit text is needed he= re. >>=20 >> I would suggest that table in Figure 3 be replaced with something like t= he following: >>=20 >> Trust Anchors >> +--------------------------------------------------------------+ >> | NOTE: EST Servers and Clients must be initialized to know | >> | which specific public keys in their trust anchor | >> | stores correspond to which function from this table. | >> +---------------+----------------------------------------------+ >> | CA Root | * End of validation path of all CA certs | >> | public key | * End of validation path of Device Cert | >> | | * May be identical to EST Server TA | >> | | * May be identical to EST Client TA >> | | * Obtainable by /CACerts command | >> +---------------+----------------------------------------------+ >> | EST Server TA | * End of validation path of EST Server cert | >> | | * Must be securely installed to EST Client | >> | | * Must be obtained securely, out-of-band | >> +---------------+----------------------------------------------+ >> | EST Client TA | * End of valid. path of EST Client init cert | >> | | * Must be securely installed to EST Server | >> | | * Must be obtained securely, out-of-band | >> +---------------+----------------------------------------------+ >>=20 >> Certificates >> +---------------+----------------------------------------------+ >> | CA Signing | * Crsp. private key signs Device Cert | >> | Certificate | * Intermediate CA certs may exist in path | >> | | * Obtainable by /CACerts command | >> | | * Must be validated against CA Root >> +---------------+----------------------------------------------+ >> | EST Server | * Used by EST Client during TLS handshake | >> | Certificate | * Must be validated against EST Server TA | >> +---------------+----------------------------------------------+ >> | EST Client | * Used by EST Server during initial enroll | >> | Init Cert | (if certificate TLS auth used) | >> | | * Must be validated against EST Client TA >> +---------------+----------------------------------------------+ >> | Device Cert | * Any certificate returned as a result of | >> | | /simpleEnroll, /simpleReEnroll, /fullCMC, | >> | | or /serverKeyGen | >> | | * May be used for subsequent EST sessions | >> +---------------+----------------------------------------------+ >> | NOTE: The CA, EST Server, EST Client, and other servers may | >> | have other certificates for other purposes, including | >> | inter-server communication during EST sessions. | >> +--------------------------------------------------------------+ >>=20 >> Mike >=20 >=20 From pritikin@cisco.com Wed Dec 5 14:52:35 2012 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 E6DDC21F881D for ; Wed, 5 Dec 2012 14:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 VYkTcfliks60 for ; Wed, 5 Dec 2012 14:52:31 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 43A2121F87D1 for ; Wed, 5 Dec 2012 14:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12758; q=dns/txt; s=iport; t=1354747950; x=1355957550; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2TGg6TJpZJvyCirv0XjkTU8JRVisf6lYaeuMEXRV0bQ=; b=IsR59ZJWAx4ZFyouBSmTFRCrKlI0zuDw9e4Gs0nM7m+dZDyUdSbhalPJ wnUV/z/BbThBAbTtxlhWiJgexKkJQaqhts5xB/yL1jAFxs4TzZaZaFsvz DRZDpWgzlApuuW60zugWJav5xVPOsQ9dHsHnZsx11ns1q1ba5GQmT2rT2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAETOv1CtJV2a/2dsb2JhbABEviQWc4IeAQEBAwFsDRACAQgOCgokIRElAgQOBQgTh2MDCQa5DQ2JVItOaQuDVWEDiCqMA40NhRCCcoFlBxcGGA X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149882898" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 05 Dec 2012 22:52:28 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qB5MqSsq029419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Dec 2012 22:52:28 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.191]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 16:52:28 -0600 From: "Max Pritikin (pritikin)" To: Michael Jenkins Thread-Topic: EST trust anchor definition Thread-Index: AQHNxpPc6GwWl6LMpkqCCG9K56Si9g== Date: Wed, 5 Dec 2012 22:52:27 +0000 Message-ID: <53EA47528D6ACF4486AA152F92C2B698B90D7A@xmb-rcd-x03.cisco.com> References: <50AA956B.10000@gmail.com> <53EA47528D6ACF4486AA152F92C2B6982E9D7E@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.0.223] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] EST trust anchor definition 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, 05 Dec 2012 22:52:35 -0000 (I corrected Peter Yee's email address) On Dec 5, 2012, at 3:50 PM, Max Pritikin wrote: >=20 > On Dec 4, 2012, at 9:55 PM, Michael Jenkins wrote: >=20 >> I think that the tables, broken out according to TAs and Certs, are a bi= g improvement. However, the TA table has really taken a hard turn /away/ fr= om the ability to specify a single TA as the one to use for EST. >=20 > What prevents the client from having a "Third-Party TA Database" that con= tains only TA's (or a single TA) to be used for EST? >=20 >> Without digging through a lot of cert guts over and over, I'll never kno= w if any particular validation is terminating in the selected TA, be it a p= rovided vendor-supplied initialization root, or a "public" CA, or a locally= supplied root. I'm not prejudiced toward one or the other of those options= , as long as it's the one I've initially configured - that is, as long as I= have a way of expressing which TA must terminate my EST transactions. >>=20 >> Ideally that would happen through some kind of labeling, but I don't thi= nk that there's anything that does that now, natively, in a system trust an= chor store. Other solutions would be to remove all trust anchors /except/ t= he selected one (drastic, but might work for some specific-use devices), or= to configure the EST client app with a keyID for the selected trust anchor= (and then check that it's the one used). >>=20 >> The draft does say that the client needs to be configured with the corre= ct trust anchor (through out-of-band means), but after that all references = to TAs are "TA Database". If I can't guarantee that I'm using the TA that I= configured, there was no point in configuring one. >=20 > We can make this the "selected TA Database" and we can indicate that: >=20 > "The Client MUST support a configurable option to enable checking all or > a subset of either the EST client Third-Party TA database or the EST > client TA database." >=20 > Would that address your concerns? >=20 > - max >=20 >=20 >>=20 >> Hope that makes sense. If I'm interpreting the table incorrectly, let me= know where I went wrong. >>=20 >> Mike >>=20 >>=20 >> On Mon, Nov 19, 2012 at 3:56 PM, Max Pritikin (pritikin) wrote: >> Thanks for all the feedback. We've already updated the table similar to = what you recommend below so its good to see we're on the same page.=20 >>=20 >> Below is the current table in our working copy. I'll read through your s= uggestions carefully to see if additional clarity can be gained.=20 >>=20 >> Similarly I'll go through you other email of specific feedback and merge= them to the revisions we've made since the ietf85 meeting.=20 >>=20 >> - max >>=20 >> Current table in our working revision (best viewed in monospaced font): >>=20 >> Certificates and their corresponding uses: >> +--------------+--------------------+-------------------------------+ >> | Certificate | Issuer | Use and section references | >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >> | EST server | The CA served by | Presented by the EST server | >> | certificate | the EST server | during the TLS handshake | >> | | | | >> | | | Section 3.3.1.1 | >> +--------------+--------------------+-------------------------------+ >> | EST server | A CA | Presented by the EST server | >> | certificate | authenticatable by | during the TLS handshake | >> | | a third-party TA | | >> | | | Section 3.3.1.1, and | >> | | | Security Considerations | >> +--------------+--------------------+-------------------------------+ >> | EST client | A CA | Presented by the EST client | >> | certificate | authenticatable by | to the EST server by clients | >> | | a third-party TA | that have not yet enrolled | >> | | e.g., a device | | >> | | manufacturer | Section 3.3.1.2 | >> +--------------+--------------------+-------------------------------+ >> | EST client | The CA served by | Presented by the EST client | >> | certificate | the EST server | to PKI End Entities. | >> | | | Including to the EST server | >> | | | during future EST operations | >> | | | | >> | | | Section 3.3.1.2 | >> +--------------+--------------------+-------------------------------+ >> | EST client | The CA served by | Presented by the EST client | >> | certificate | the EST server | to PKI End Entities. | >> | | | Clients can obtain certs | >> | | | that can not be used for EST | >> | | | client authentication | >> | | | | >> | | | Section 4.4.1 | >> +--------------+--------------------+-------------------------------+ >>=20 >>=20 >> Figure 3 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Pritikin, et al. Expires May 21, 2013 [Page 12] >> Internet-Draft EST November 2012 >>=20 >>=20 >> Trust Anchor databases and their corresponding uses: >> +--------------+----------------------------------------------------+ >> | TA database | Use and section references | >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >> | EST server | EST servers use this TA database to authenticate | >> | TA database | certificates issued by the CA, including EST | >> | | client certificates during enroll/re-enroll | >> | | operations | >> | | | >> | | Section 3.3.1.2 | >> +--------------+----------------------------------------------------+ >> | EST server | EST servers use this TA database to authenticate | >> | Third-Party | certificates issued by third-party TAs. | >> | TA database | e.g., EST client certificates issued by a device | >> | | manufacturer | >> | | | >> | | Section 3.3.1.2 | >> +--------------+----------------------------------------------------+ >> | EST client | EST clients use this TA database to authenticate | >> | EST CA | certificates issued by the EST CA, including EST | >> | TA database | server certificates. | >> | | | >> | | Section 3.3.1.1 and | >> | | Section 4.3 | >> +--------------+----------------------------------------------------+ >> | EST client | EST clients use this trust anchor database to | >> | Third-Party | authenticate an EST server that uses an externally | >> | TA database | issued certificate. | >> | | | >> | | | >> | | Section 3.3.1.1 and | >> | | Security Considerations | >> +--------------+----------------------------------------------------+ >>=20 >>=20 >> Figure 4 >>=20 >> On Nov 19, 2012, at 1:24 PM, M Jenkins >> wrote: >>=20 >>> I think that the current EST draft is weak when it comes to talking abo= ut trust anchors. Many of the right ideas are there, but a bit scattered ab= out. Figure (Table) 3 has a lot of this information, but there's some fuzz = in it, and it's not very explicit about how crucial TA initialization is to= the security of the protocol. >>>=20 >>> A specific concern is a perception that *any* trust anchor that happens= to be in a trust anchor store might be used to terminate a certificate val= idation chain. The use of the phrase "third party Trust Anchor Database" is= worrisome. Who cares if the TA comes from any (acceptable) third party - i= f you can't ensure that your validation chain is going to terminate in that= TA in the first place? The present state of TA store management doesn't in= herently provide this selectability. I think that explicit text is needed h= ere. >>>=20 >>> I would suggest that table in Figure 3 be replaced with something like = the following: >>>=20 >>> Trust Anchors >>> +--------------------------------------------------------------+ >>> | NOTE: EST Servers and Clients must be initialized to know | >>> | which specific public keys in their trust anchor | >>> | stores correspond to which function from this table. | >>> +---------------+----------------------------------------------+ >>> | CA Root | * End of validation path of all CA certs | >>> | public key | * End of validation path of Device Cert | >>> | | * May be identical to EST Server TA | >>> | | * May be identical to EST Client TA >>> | | * Obtainable by /CACerts command | >>> +---------------+----------------------------------------------+ >>> | EST Server TA | * End of validation path of EST Server cert | >>> | | * Must be securely installed to EST Client | >>> | | * Must be obtained securely, out-of-band | >>> +---------------+----------------------------------------------+ >>> | EST Client TA | * End of valid. path of EST Client init cert | >>> | | * Must be securely installed to EST Server | >>> | | * Must be obtained securely, out-of-band | >>> +---------------+----------------------------------------------+ >>>=20 >>> Certificates >>> +---------------+----------------------------------------------+ >>> | CA Signing | * Crsp. private key signs Device Cert | >>> | Certificate | * Intermediate CA certs may exist in path | >>> | | * Obtainable by /CACerts command | >>> | | * Must be validated against CA Root >>> +---------------+----------------------------------------------+ >>> | EST Server | * Used by EST Client during TLS handshake | >>> | Certificate | * Must be validated against EST Server TA | >>> +---------------+----------------------------------------------+ >>> | EST Client | * Used by EST Server during initial enroll | >>> | Init Cert | (if certificate TLS auth used) | >>> | | * Must be validated against EST Client TA >>> +---------------+----------------------------------------------+ >>> | Device Cert | * Any certificate returned as a result of | >>> | | /simpleEnroll, /simpleReEnroll, /fullCMC, | >>> | | or /serverKeyGen | >>> | | * May be used for subsequent EST sessions | >>> +---------------+----------------------------------------------+ >>> | NOTE: The CA, EST Server, EST Client, and other servers may | >>> | have other certificates for other purposes, including | >>> | inter-server communication during EST sessions. | >>> +--------------------------------------------------------------+ >>>=20 >>> Mike >>=20 >>=20 >=20 From bergtau@gmail.com Thu Dec 6 08:13:51 2012 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 2EE2621F8796 for ; Thu, 6 Dec 2012 08:13:51 -0800 (PST) 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 8cGpI1i7ffKZ for ; Thu, 6 Dec 2012 08:13:49 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id 510B421F87B2 for ; Thu, 6 Dec 2012 08:13:49 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k14so10469934iea.24 for ; Thu, 06 Dec 2012 08:13:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uJqsECJ43VUfAVGTqjyoi9uHS/KD19Bzt/lsQZJH440=; b=edJOyKn7daX00c+WG1ZJ1vpEhFqul0H+kjZ3f6lAbTOHdZI2BQ/pT0jwdumAKrPkAU JyZCpZMio3W/qzyyLkQ3PMQ0E6qi6UCKI4dcO1rMxnUZwKM8wERGNyxDSvuc/9vhRojt 0zV76M4z3h4+ZbBKMKys490YH8L3p5Npozim7wEjFZR7b2nC0ari9cOithWYVbxDP50C b/PkxZqn4mzv+gyPn6VLvAvrlSVZAtVhcabL7sK9bAvTWjar2tKsX5A0Sha5fINiFwpP 9nzOVCXs+GrE8WmGJmCZrWsXX2mlLIuHaBQJTcV1aa+byxyL4DVBfglMZLOOi3GkgFrX EjRg== MIME-Version: 1.0 Received: by 10.50.169.100 with SMTP id ad4mr1955634igc.50.1354810428734; Thu, 06 Dec 2012 08:13:48 -0800 (PST) Received: by 10.64.11.1 with HTTP; Thu, 6 Dec 2012 08:13:48 -0800 (PST) In-Reply-To: <53EA47528D6ACF4486AA152F92C2B698B90D7A@xmb-rcd-x03.cisco.com> References: <50AA956B.10000@gmail.com> <53EA47528D6ACF4486AA152F92C2B6982E9D7E@xmb-rcd-x03.cisco.com> <53EA47528D6ACF4486AA152F92C2B698B90D7A@xmb-rcd-x03.cisco.com> Date: Thu, 6 Dec 2012 11:13:48 -0500 Message-ID: From: Michael Jenkins To: "Max Pritikin (pritikin)" Content-Type: multipart/alternative; boundary=e89a8f23462757bcf104d031625c Cc: "pkix@ietf.org" Subject: Re: [pkix] EST trust anchor definition 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, 06 Dec 2012 16:13:51 -0000 --e89a8f23462757bcf104d031625c Content-Type: text/plain; charset=ISO-8859-1 I suppose that helps - but it's more wordy and less clear, and therefore more prone to error. It's not that the system supporting the EST client can't have a TA database - I'm assuming it will. It's that the database is irrelevant to the protocol. I don't unlock the lock on my front door with a keyring, I do it with a key. Whether I only have one key, or whether I have 100, and whether I keep my 100 on a ring or in a box, is irrelevant. Crucially, I have to make sure the wrong thing doesn't happen. Say that I have a key to my neighbor's house. I want to enter my house. If my neighbor's house and mine look alike, and I walk up to his house by mistake, and I "use my keyring" to unlock the lock on the door - it works! Which is unfortunate for me, because his rabid dog just bit my leg. The problem I'm having with "TA Database" is that such databases are generally designed to make things work, not to make things work only in certain circumstances, as defined by the operator or local admin. It's no accident that most consumer systems come with a laundry-list of trust anchors, and there generally isn't any notification to the operator that any particular one was used during any particular transaction. Saying "use the TA Database" requires me to think up all of the ways that applying the entire database to my protocol might fail, and say how to prevent them. Saying "use only the XYZ trust anchor" is much more clear and precise. How to ensure that that particular trust anchor gets used is up to the system designer - which is a good thing, because I don't think it's desired that EST be limited to any one particular type of client system. On Wed, Dec 5, 2012 at 5:52 PM, Max Pritikin (pritikin) wrote: > > (I corrected Peter Yee's email address) > > On Dec 5, 2012, at 3:50 PM, Max Pritikin wrote: > > > > > On Dec 4, 2012, at 9:55 PM, Michael Jenkins wrote: > > > >> I think that the tables, broken out according to TAs and Certs, are a > big improvement. However, the TA table has really taken a hard turn /away/ > from the ability to specify a single TA as the one to use for EST. > > > > What prevents the client from having a "Third-Party TA Database" that > contains only TA's (or a single TA) to be used for EST? > > > >> Without digging through a lot of cert guts over and over, I'll never > know if any particular validation is terminating in the selected TA, be it > a provided vendor-supplied initialization root, or a "public" CA, or a > locally supplied root. I'm not prejudiced toward one or the other of those > options, as long as it's the one I've initially configured - that is, as > long as I have a way of expressing which TA must terminate my EST > transactions. > >> > >> Ideally that would happen through some kind of labeling, but I don't > think that there's anything that does that now, natively, in a system trust > anchor store. Other solutions would be to remove all trust anchors /except/ > the selected one (drastic, but might work for some specific-use devices), > or to configure the EST client app with a keyID for the selected trust > anchor (and then check that it's the one used). > >> > >> The draft does say that the client needs to be configured with the > correct trust anchor (through out-of-band means), but after that all > references to TAs are "TA Database". If I can't guarantee that I'm using > the TA that I configured, there was no point in configuring one. > > > > We can make this the "selected TA Database" and we can indicate that: > > > > "The Client MUST support a configurable option to enable checking all or > > a subset of either the EST client Third-Party TA database or the EST > > client TA database." > > > > Would that address your concerns? > > > > - max > > > > > >> > >> Hope that makes sense. If I'm interpreting the table incorrectly, let > me know where I went wrong. > >> > >> Mike > >> > >> > >> On Mon, Nov 19, 2012 at 3:56 PM, Max Pritikin (pritikin) < > pritikin@cisco.com> wrote: > >> Thanks for all the feedback. We've already updated the table similar to > what you recommend below so its good to see we're on the same page. > >> > >> Below is the current table in our working copy. I'll read through your > suggestions carefully to see if additional clarity can be gained. > >> > >> Similarly I'll go through you other email of specific feedback and > merge them to the revisions we've made since the ietf85 meeting. > >> > >> - max > >> > >> Current table in our working revision (best viewed in monospaced font): > >> > >> Certificates and their corresponding uses: > >> +--------------+--------------------+-------------------------------+ > >> | Certificate | Issuer | Use and section references | > >> +==============+====================+===============================+ > >> | EST server | The CA served by | Presented by the EST server | > >> | certificate | the EST server | during the TLS handshake | > >> | | | | > >> | | | Section 3.3.1.1 | > >> +--------------+--------------------+-------------------------------+ > >> | EST server | A CA | Presented by the EST server | > >> | certificate | authenticatable by | during the TLS handshake | > >> | | a third-party TA | | > >> | | | Section 3.3.1.1, and | > >> | | | Security Considerations | > >> +--------------+--------------------+-------------------------------+ > >> | EST client | A CA | Presented by the EST client | > >> | certificate | authenticatable by | to the EST server by clients | > >> | | a third-party TA | that have not yet enrolled | > >> | | e.g., a device | | > >> | | manufacturer | Section 3.3.1.2 | > >> +--------------+--------------------+-------------------------------+ > >> | EST client | The CA served by | Presented by the EST client | > >> | certificate | the EST server | to PKI End Entities. | > >> | | | Including to the EST server | > >> | | | during future EST operations | > >> | | | | > >> | | | Section 3.3.1.2 | > >> +--------------+--------------------+-------------------------------+ > >> | EST client | The CA served by | Presented by the EST client | > >> | certificate | the EST server | to PKI End Entities. | > >> | | | Clients can obtain certs | > >> | | | that can not be used for EST | > >> | | | client authentication | > >> | | | | > >> | | | Section 4.4.1 | > >> +--------------+--------------------+-------------------------------+ > >> > >> > >> Figure 3 > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Pritikin, et al. Expires May 21, 2013 [Page 12] > >> Internet-Draft EST November 2012 > >> > >> > >> Trust Anchor databases and their corresponding uses: > >> +--------------+----------------------------------------------------+ > >> | TA database | Use and section references | > >> +==============+====================================================+ > >> | EST server | EST servers use this TA database to authenticate | > >> | TA database | certificates issued by the CA, including EST | > >> | | client certificates during enroll/re-enroll | > >> | | operations | > >> | | | > >> | | Section 3.3.1.2 | > >> +--------------+----------------------------------------------------+ > >> | EST server | EST servers use this TA database to authenticate | > >> | Third-Party | certificates issued by third-party TAs. | > >> | TA database | e.g., EST client certificates issued by a device | > >> | | manufacturer | > >> | | | > >> | | Section 3.3.1.2 | > >> +--------------+----------------------------------------------------+ > >> | EST client | EST clients use this TA database to authenticate | > >> | EST CA | certificates issued by the EST CA, including EST | > >> | TA database | server certificates. | > >> | | | > >> | | Section 3.3.1.1 and | > >> | | Section 4.3 | > >> +--------------+----------------------------------------------------+ > >> | EST client | EST clients use this trust anchor database to | > >> | Third-Party | authenticate an EST server that uses an externally | > >> | TA database | issued certificate. | > >> | | | > >> | | | > >> | | Section 3.3.1.1 and | > >> | | Security Considerations | > >> +--------------+----------------------------------------------------+ > >> > >> > >> Figure 4 > >> > >> On Nov 19, 2012, at 1:24 PM, M Jenkins > >> wrote: > >> > >>> I think that the current EST draft is weak when it comes to talking > about trust anchors. Many of the right ideas are there, but a bit scattered > about. Figure (Table) 3 has a lot of this information, but there's some > fuzz in it, and it's not very explicit about how crucial TA initialization > is to the security of the protocol. > >>> > >>> A specific concern is a perception that *any* trust anchor that > happens to be in a trust anchor store might be used to terminate a > certificate validation chain. The use of the phrase "third party Trust > Anchor Database" is worrisome. Who cares if the TA comes from any > (acceptable) third party - if you can't ensure that your validation chain > is going to terminate in that TA in the first place? The present state of > TA store management doesn't inherently provide this selectability. I think > that explicit text is needed here. > >>> > >>> I would suggest that table in Figure 3 be replaced with something like > the following: > >>> > >>> Trust Anchors > >>> +--------------------------------------------------------------+ > >>> | NOTE: EST Servers and Clients must be initialized to know | > >>> | which specific public keys in their trust anchor | > >>> | stores correspond to which function from this table. | > >>> +---------------+----------------------------------------------+ > >>> | CA Root | * End of validation path of all CA certs | > >>> | public key | * End of validation path of Device Cert | > >>> | | * May be identical to EST Server TA | > >>> | | * May be identical to EST Client TA > >>> | | * Obtainable by /CACerts command | > >>> +---------------+----------------------------------------------+ > >>> | EST Server TA | * End of validation path of EST Server cert | > >>> | | * Must be securely installed to EST Client | > >>> | | * Must be obtained securely, out-of-band | > >>> +---------------+----------------------------------------------+ > >>> | EST Client TA | * End of valid. path of EST Client init cert | > >>> | | * Must be securely installed to EST Server | > >>> | | * Must be obtained securely, out-of-band | > >>> +---------------+----------------------------------------------+ > >>> > >>> Certificates > >>> +---------------+----------------------------------------------+ > >>> | CA Signing | * Crsp. private key signs Device Cert | > >>> | Certificate | * Intermediate CA certs may exist in path | > >>> | | * Obtainable by /CACerts command | > >>> | | * Must be validated against CA Root > >>> +---------------+----------------------------------------------+ > >>> | EST Server | * Used by EST Client during TLS handshake | > >>> | Certificate | * Must be validated against EST Server TA | > >>> +---------------+----------------------------------------------+ > >>> | EST Client | * Used by EST Server during initial enroll | > >>> | Init Cert | (if certificate TLS auth used) | > >>> | | * Must be validated against EST Client TA > >>> +---------------+----------------------------------------------+ > >>> | Device Cert | * Any certificate returned as a result of | > >>> | | /simpleEnroll, /simpleReEnroll, /fullCMC, | > >>> | | or /serverKeyGen | > >>> | | * May be used for subsequent EST sessions | > >>> +---------------+----------------------------------------------+ > >>> | NOTE: The CA, EST Server, EST Client, and other servers may | > >>> | have other certificates for other purposes, including | > >>> | inter-server communication during EST sessions. | > >>> +--------------------------------------------------------------+ > >>> > >>> Mike > >> > >> > > > > --e89a8f23462757bcf104d031625c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I suppose that helps - but it's more wordy and less clear, and therefor= e more prone to error. It's not that the system supporting the EST clie= nt can't have a TA database - I'm assuming it will. It's that t= he database is irrelevant to the protocol. I don't unlock the lock on m= y front door with a keyring, I do it with a key. Whether I only have one ke= y, or whether I have 100, and whether I keep my 100 on a ring or in a box, = is irrelevant.

Crucially, I have to make sure the wrong thing doesn't happen. Say = that I have a key to my neighbor's house. I want to enter my house. If = my neighbor's house and mine look alike, and I walk up to his house by = mistake, and I "use my keyring" to unlock the lock on the door - = it works! Which is unfortunate for me, because his rabid dog just bit my le= g.

The problem I'm having with "TA Database" is that such da= tabases are generally designed to make things work, not to make things work= only in certain circumstances, as defined by the operator or local admin. = It's no accident that most consumer systems come with a laundry-list of= trust anchors, and there generally isn't any notification to the opera= tor that any particular one was used during any particular transaction.

Saying "use the TA Database" requires me to think up all of t= he ways that applying the entire database to my protocol might fail, and sa= y how to prevent them. Saying "use only the XYZ trust anchor" is = much more clear and precise. How to ensure that that particular trust ancho= r gets used is up to the system designer - which is a good thing, because I= don't think it's desired that EST be limited to any one particular= type of client system.


On Wed, Dec 5= , 2012 at 5:52 PM, Max Pritikin (pritikin) <pritikin@cisco.com> wrote:

(I corrected Peter Yee's email address)

On Dec 5, 2012, at 3:50 PM, Max Pritikin <pritikin@cisco.com> wrote:

>
> On Dec 4, 2012, at 9:55 PM, Michael Jenkins <bergtau@gmail.com> wrote:
>
>> I think that the tables, broken out according to TAs and Certs, ar= e a big improvement. However, the TA table has really taken a hard turn /aw= ay/ from the ability to specify a single TA as the one to use for EST.
>
> What prevents the client from having a = "Third-Party TA Database" that contains only TA's (or a singl= e TA) to be used for EST?
>
>> Without digging through a lot of ce= rt guts over and over, I'll never know if any particular validation is = terminating in the selected TA, be it a provided vendor-supplied initializa= tion root, or a "public" CA, or a locally supplied root. I'm = not prejudiced toward one or the other of those options, as long as it'= s the one I've initially configured - that is, as long as I have a way = of expressing which TA must terminate my EST transactions.
>>
>> Ideally that would happen through some kind of labeling, but I don= 't think that there's anything that does that now, natively, in a s= ystem trust anchor store. Other solutions would be to remove all trust anch= ors /except/ the selected one (drastic, but might work for some specific-us= e devices), or to configure the EST client app with a keyID for the selecte= d trust anchor (and then check that it's the one used).
>>
>> The draft does say that the client needs to be configured with the= correct trust anchor (through out-of-band means), but after that all refer= ences to TAs are "TA Database". If I can't guarantee that I&#= 39;m using the TA that I configured, there was no point in configuring one.=
>
> We can make this the "selected TA = Database" and we can indicate that:
>
> "The Client MUST support a configurable option to enable checking= all or
> a subset of either the EST client Third-Party TA database or the EST > client TA database."
>
> Would that address your concerns?
>
> - max
>
>
>>
>> Hope that makes sens= e. If I'm interpreting the table incorrectly, let me know where I went = wrong.
>>
>> Mike
>>
>>
>> On Mon, Nov 19, 2012 at 3:56 PM, Max Pritikin (pritikin) <pritikin@cisco.com> wrote:
>> Thanks for all the feedback. We've already updated the table s= imilar to what you recommend below so its good to see we're on the same= page.
>>
>> Below is the current table in our working copy. I'll read thro= ugh your suggestions carefully to see if additional clarity can be gained.<= br> >>
>> Similarly I'll go through you other email of specific feedback= and merge them to the revisions we've made since the ietf85 meeting. >>
>> - max
>>
>> Current table in our working revision (best viewed in monospaced f= ont):
>>
>> =A0 Certificates and their corresponding uses:
>> =A0 +--------------+--------------------+-------------------------= ------+
>> =A0 | Certificate =A0| Issuer =A0 =A0 =A0 =A0 =A0 =A0 | Use and se= ction references =A0 =A0|
>> =A0 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
>> =A0 | EST server =A0 | The CA served by =A0 | Presented by the EST= server =A0 |
>> =A0 | certificate =A0| the EST server =A0 =A0 | during the TLS han= dshake =A0 =A0 =A0|
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| Section 3.3.1.1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 +--------------+--------------------+-------------------------= ------+
>> =A0 | EST server =A0 | A CA =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Presente= d by the EST server =A0 |
>> =A0 | certificate =A0| authenticatable by | during the TLS handsha= ke =A0 =A0 =A0|
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| a third-party TA =A0 | =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| Section 3.3.1.1, and =A0 =A0 =A0 =A0 =A0|
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| Security Considerations =A0 =A0 =A0 |
>> =A0 +--------------+--------------------+-------------------------= ------+
>> =A0 | EST client =A0 | A CA =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Presente= d by the EST client =A0 |
>> =A0 | certificate =A0| authenticatable by | to the EST server by c= lients =A0|
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| a third-party TA =A0 | that hav= e not yet enrolled =A0 =A0|
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| e.g., a device =A0 =A0 | =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| manufacturer =A0 =A0 =A0 | Sect= ion 3.3.1.2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 +--------------+--------------------+-------------------------= ------+
>> =A0 | EST client =A0 | The CA served by =A0 | Presented by the EST= client =A0 |
>> =A0 | certificate =A0| the EST server =A0 =A0 | to PKI End Entitie= s. =A0 =A0 =A0 =A0 =A0|
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| Including to the EST server =A0 |
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| during future EST operations =A0|
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| Section 3.3.1.2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 +--------------+--------------------+-------------------------= ------+
>> =A0 | EST client =A0 | The CA served by =A0 | Presented by the EST= client =A0 |
>> =A0 | certificate =A0| the EST server =A0 =A0 | to PKI End Entitie= s. =A0 =A0 =A0 =A0 =A0|
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| Clients can obtain certs =A0 =A0 =A0|
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| that can not be used for EST =A0|
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| client authentication =A0 =A0 =A0 =A0 |
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| Section 4.4.1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 +--------------+--------------------+-------------------------= ------+
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fi= gure 3
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Pritikin, et al. =A0 =A0 =A0 =A0 =A0Expires May 21, 2013 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 [Page 12]
>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EST =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 November 2012
>>
>>
>> =A0 Trust Anchor databases and their corresponding uses:
>> =A0 +--------------+----------------------------------------------= ------+
>> =A0 | TA database =A0| Use and section references =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
>> =A0 | EST server =A0 | EST servers use this TA database to authent= icate =A0 |
>> =A0 | TA database =A0| certificates issued by the CA, including ES= T =A0 =A0 =A0 |
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| client certificates during enro= ll/re-enroll =A0 =A0 =A0 =A0|
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| operations =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| Section 3.3.1.2 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>> =A0 +--------------+----------------------------------------------= ------+
>> =A0 | EST server =A0 | EST servers use this TA database to authent= icate =A0 |
>> =A0 | Third-Party =A0| certificates issued by third-party TAs. =A0= =A0 =A0 =A0 =A0 =A0|
>> =A0 | TA database =A0| e.g., EST client certificates issued by a d= evice =A0 |
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| manufacturer =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| Section 3.3.1.2 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>> =A0 +--------------+----------------------------------------------= ------+
>> =A0 | EST client =A0 | EST clients use this TA database to authent= icate =A0 |
>> =A0 | EST CA =A0 =A0 =A0 | certificates issued by the EST CA, incl= uding EST =A0 |
>> =A0 | TA database =A0| server certificates. =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| Section 3.3.1.1 and =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| Section 4.3 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>> =A0 +--------------+----------------------------------------------= ------+
>> =A0 | EST client =A0 | EST clients use this trust anchor database = to =A0 =A0 =A0|
>> =A0 | Third-Party =A0| authenticate an EST server that uses an ext= ernally |
>> =A0 | TA database =A0| issued certificate. =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| Section 3.3.1.1 and =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| Security Considerations =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>> =A0 +--------------+----------------------------------------------= ------+
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fi= gure 4
>>
>> On Nov 19, 2012, at 1:24 PM, M Jenkins <bergtau@gmail.com>
>> wrote:
>>
>>> I think that the current EST draft is weak when it comes to ta= lking about trust anchors. Many of the right ideas are there, but a bit sca= ttered about. Figure (Table) 3 has a lot of this information, but there'= ;s some fuzz in it, and it's not very explicit about how crucial TA ini= tialization is to the security of the protocol.
>>>
>>> A specific concern is a perception that *any* trust anchor tha= t happens to be in a trust anchor store might be used to terminate a certif= icate validation chain. The use of the phrase "third party Trust Ancho= r Database" is worrisome. Who cares if the TA comes from any (acceptab= le) third party - if you can't ensure that your validation chain is goi= ng to terminate in that TA in the first place? The present state of TA stor= e management doesn't inherently provide this selectability. I think tha= t explicit text is needed here.
>>>
>>> I would suggest that table in Figure 3 be replaced with someth= ing like the following:
>>>
>>> Trust Anchors
>>> +-------------------------------------------------------------= -+
>>> | NOTE: EST Servers and Clients must be initialized to know = =A0 =A0|
>>> | =A0 =A0 =A0 which specific public keys in their trust anchor= =A0 =A0 =A0 |
>>> | =A0 =A0 =A0 stores correspond to which function from this ta= ble. =A0 |
>>> +---------------+---------------------------------------------= -+
>>> | CA Root =A0 =A0 =A0 | * End of validation path of all CA cer= ts =A0 =A0 |
>>> | =A0public key =A0 | * End of validation path of Device Cert = =A0 =A0 =A0|
>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | * May be identical to EST Serv= er TA =A0 =A0 =A0 =A0 =A0|
>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | * May be identical to EST Clie= nt TA
>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | * Obtainable by /CACerts comma= nd =A0 =A0 =A0 =A0 =A0 =A0 |
>>> +---------------+---------------------------------------------= -+
>>> | EST Server TA | * End of validation path of EST Server cert = =A0|
>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | * Must be securely installed t= o EST Client =A0 |
>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | * Must be obtained securely, o= ut-of-band =A0 =A0 |
>>> +---------------+---------------------------------------------= -+
>>> | EST Client TA | * End of valid. path of EST Client init cert= |
>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | * Must be securely installed t= o EST Server =A0 |
>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | * Must be obtained securely, o= ut-of-band =A0 =A0 |
>>> +---------------+---------------------------------------------= -+
>>>
>>> Certificates
>>> +---------------+---------------------------------------------= -+
>>> | CA Signing =A0 =A0| * Crsp. private key signs Device Cert = =A0 =A0 =A0 =A0|
>>> | =A0Certificate =A0| * Intermediate CA certs may exist in pat= h =A0 =A0|
>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | * Obtainable by /CACerts comma= nd =A0 =A0 =A0 =A0 =A0 =A0 |
>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | * Must be validated against CA= Root
>>> +---------------+---------------------------------------------= -+
>>> | EST Server =A0 =A0| * Used by EST Client during TLS handshak= e =A0 =A0|
>>> | =A0Certificate =A0| * Must be validated against EST Server T= A =A0 =A0|
>>> +---------------+---------------------------------------------= -+
>>> | EST Client =A0 =A0| * Used by EST Server during initial enro= ll =A0 |
>>> | =A0Init Cert =A0 =A0| =A0 =A0(if certificate TLS auth used) = =A0 =A0 =A0 =A0 =A0 =A0|
>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | * Must be validated against ES= T Client TA
>>> +---------------+---------------------------------------------= -+
>>> | Device Cert =A0 | * Any certificate returned as a result of = =A0 =A0|
>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0/simpleEnroll, /simpleR= eEnroll, /fullCMC, |
>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0or /serverKeyGen =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | * May be used for subsequent E= ST sessions =A0 =A0|
>>> +---------------+---------------------------------------------= -+
>>> | NOTE: The CA, EST Server, EST Client, and other servers may = =A0|
>>> | =A0 =A0 =A0 have other certificates for other purposes, incl= uding =A0|
>>> | =A0 =A0 =A0 inter-server communication during EST sessions. = =A0 =A0 =A0 =A0|
>>> +-------------------------------------------------------------= -+
>>>
>>> Mike
>>
>>
>


--e89a8f23462757bcf104d031625c-- From dharkins@lounge.org Thu Dec 6 10:01:43 2012 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 C3CFA21F855E for ; Thu, 6 Dec 2012 10:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 YGjkgmn4wl4u for ; Thu, 6 Dec 2012 10:01:42 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6F08321F855C for ; Thu, 6 Dec 2012 10:01:42 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 82BE21022400A; Thu, 6 Dec 2012 10:01:41 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 6 Dec 2012 10:01:42 -0800 (PST) Message-ID: <272834c531520b7e91723a0d303c8260.squirrel@www.trepanning.net> In-Reply-To: References: <50AA956B.10000@gmail.com> <53EA47528D6ACF4486AA152F92C2B6982E9D7E@xmb-rcd-x03.cisco.com> <53EA47528D6ACF4486AA152F92C2B698B90D7A@xmb-rcd-x03.cisco.com> Date: Thu, 6 Dec 2012 10:01:42 -0800 (PST) From: "Dan Harkins" To: "Michael Jenkins" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "pkix@ietf.org" Subject: Re: [pkix] EST trust anchor definition 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, 06 Dec 2012 18:01:43 -0000 Hello, Perhaps I'm missing something but the "selected TA database" is allowing the client to verify the trustworthiness of the EST server's certificate. The client is still supposed to decide whether this is the _correct_ EST server by checking the contents of the certificate against whatever policy might be configured as well as performing the TLS handshake and ensuring that the EST server holds the private analog to the authenticated public key it now holds. To stretch your analogy, the "selected TA database" is allowing you to determine whether this is a bonafide Schlage deadbolt lock that you're looking at. Whether it's _your_ bonafide Schlage deadbolt lock is the next step you have to do by putting your key into the lock and seeing whether it opens the door. If your neighbor's rabid dog bites you then it's a sign that 2 keys open the same door which is a failure of a different kind. Dan. On Thu, December 6, 2012 8:13 am, Michael Jenkins wrote: > I suppose that helps - but it's more wordy and less clear, and therefore > more prone to error. It's not that the system supporting the EST client > can't have a TA database - I'm assuming it will. It's that the database is > irrelevant to the protocol. I don't unlock the lock on my front door with > a > keyring, I do it with a key. Whether I only have one key, or whether I > have > 100, and whether I keep my 100 on a ring or in a box, is irrelevant. > > Crucially, I have to make sure the wrong thing doesn't happen. Say that I > have a key to my neighbor's house. I want to enter my house. If my > neighbor's house and mine look alike, and I walk up to his house by > mistake, and I "use my keyring" to unlock the lock on the door - it works! > Which is unfortunate for me, because his rabid dog just bit my leg. > > The problem I'm having with "TA Database" is that such databases are > generally designed to make things work, not to make things work only in > certain circumstances, as defined by the operator or local admin. It's no > accident that most consumer systems come with a laundry-list of trust > anchors, and there generally isn't any notification to the operator that > any particular one was used during any particular transaction. > > Saying "use the TA Database" requires me to think up all of the ways that > applying the entire database to my protocol might fail, and say how to > prevent them. Saying "use only the XYZ trust anchor" is much more clear > and > precise. How to ensure that that particular trust anchor gets used is up > to > the system designer - which is a good thing, because I don't think it's > desired that EST be limited to any one particular type of client system. > > > On Wed, Dec 5, 2012 at 5:52 PM, Max Pritikin (pritikin) > wrote: > >> >> (I corrected Peter Yee's email address) >> >> On Dec 5, 2012, at 3:50 PM, Max Pritikin wrote: >> >> > >> > On Dec 4, 2012, at 9:55 PM, Michael Jenkins wrote: >> > >> >> I think that the tables, broken out according to TAs and Certs, are a >> big improvement. However, the TA table has really taken a hard turn >> /away/ >> from the ability to specify a single TA as the one to use for EST. >> > >> > What prevents the client from having a "Third-Party TA Database" that >> contains only TA's (or a single TA) to be used for EST? >> > >> >> Without digging through a lot of cert guts over and over, I'll never >> know if any particular validation is terminating in the selected TA, be >> it >> a provided vendor-supplied initialization root, or a "public" CA, or a >> locally supplied root. I'm not prejudiced toward one or the other of >> those >> options, as long as it's the one I've initially configured - that is, as >> long as I have a way of expressing which TA must terminate my EST >> transactions. >> >> >> >> Ideally that would happen through some kind of labeling, but I don't >> think that there's anything that does that now, natively, in a system >> trust >> anchor store. Other solutions would be to remove all trust anchors >> /except/ >> the selected one (drastic, but might work for some specific-use >> devices), >> or to configure the EST client app with a keyID for the selected trust >> anchor (and then check that it's the one used). >> >> >> >> The draft does say that the client needs to be configured with the >> correct trust anchor (through out-of-band means), but after that all >> references to TAs are "TA Database". If I can't guarantee that I'm using >> the TA that I configured, there was no point in configuring one. >> > >> > We can make this the "selected TA Database" and we can indicate that: >> > >> > "The Client MUST support a configurable option to enable checking all >> or >> > a subset of either the EST client Third-Party TA database or the EST >> > client TA database." >> > >> > Would that address your concerns? >> > >> > - max >> > >> > >> >> >> >> Hope that makes sense. If I'm interpreting the table incorrectly, let >> me know where I went wrong. >> >> >> >> Mike >> >> >> >> >> >> On Mon, Nov 19, 2012 at 3:56 PM, Max Pritikin (pritikin) < >> pritikin@cisco.com> wrote: >> >> Thanks for all the feedback. We've already updated the table similar >> to >> what you recommend below so its good to see we're on the same page. >> >> >> >> Below is the current table in our working copy. I'll read through >> your >> suggestions carefully to see if additional clarity can be gained. >> >> >> >> Similarly I'll go through you other email of specific feedback and >> merge them to the revisions we've made since the ietf85 meeting. >> >> >> >> - max >> >> >> >> Current table in our working revision (best viewed in monospaced >> font): >> >> >> >> Certificates and their corresponding uses: >> >> +--------------+--------------------+-------------------------------+ >> >> | Certificate | Issuer | Use and section references >> | >> >> +==============+====================+===============================+ >> >> | EST server | The CA served by | Presented by the EST server >> | >> >> | certificate | the EST server | during the TLS handshake >> | >> >> | | | >> | >> >> | | | Section 3.3.1.1 >> | >> >> +--------------+--------------------+-------------------------------+ >> >> | EST server | A CA | Presented by the EST server >> | >> >> | certificate | authenticatable by | during the TLS handshake >> | >> >> | | a third-party TA | >> | >> >> | | | Section 3.3.1.1, and >> | >> >> | | | Security Considerations >> | >> >> +--------------+--------------------+-------------------------------+ >> >> | EST client | A CA | Presented by the EST client >> | >> >> | certificate | authenticatable by | to the EST server by clients >> | >> >> | | a third-party TA | that have not yet enrolled >> | >> >> | | e.g., a device | >> | >> >> | | manufacturer | Section 3.3.1.2 >> | >> >> +--------------+--------------------+-------------------------------+ >> >> | EST client | The CA served by | Presented by the EST client >> | >> >> | certificate | the EST server | to PKI End Entities. >> | >> >> | | | Including to the EST server >> | >> >> | | | during future EST operations >> | >> >> | | | >> | >> >> | | | Section 3.3.1.2 >> | >> >> +--------------+--------------------+-------------------------------+ >> >> | EST client | The CA served by | Presented by the EST client >> | >> >> | certificate | the EST server | to PKI End Entities. >> | >> >> | | | Clients can obtain certs >> | >> >> | | | that can not be used for EST >> | >> >> | | | client authentication >> | >> >> | | | >> | >> >> | | | Section 4.4.1 >> | >> >> +--------------+--------------------+-------------------------------+ >> >> >> >> >> >> Figure 3 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Pritikin, et al. Expires May 21, 2013 [Page >> 12] >> >> Internet-Draft EST November >> 2012 >> >> >> >> >> >> Trust Anchor databases and their corresponding uses: >> >> +--------------+----------------------------------------------------+ >> >> | TA database | Use and section references >> | >> >> +==============+====================================================+ >> >> | EST server | EST servers use this TA database to authenticate >> | >> >> | TA database | certificates issued by the CA, including EST >> | >> >> | | client certificates during enroll/re-enroll >> | >> >> | | operations >> | >> >> | | >> | >> >> | | Section 3.3.1.2 >> | >> >> +--------------+----------------------------------------------------+ >> >> | EST server | EST servers use this TA database to authenticate >> | >> >> | Third-Party | certificates issued by third-party TAs. >> | >> >> | TA database | e.g., EST client certificates issued by a device >> | >> >> | | manufacturer >> | >> >> | | >> | >> >> | | Section 3.3.1.2 >> | >> >> +--------------+----------------------------------------------------+ >> >> | EST client | EST clients use this TA database to authenticate >> | >> >> | EST CA | certificates issued by the EST CA, including EST >> | >> >> | TA database | server certificates. >> | >> >> | | >> | >> >> | | Section 3.3.1.1 and >> | >> >> | | Section 4.3 >> | >> >> +--------------+----------------------------------------------------+ >> >> | EST client | EST clients use this trust anchor database to >> | >> >> | Third-Party | authenticate an EST server that uses an externally >> | >> >> | TA database | issued certificate. >> | >> >> | | >> | >> >> | | >> | >> >> | | Section 3.3.1.1 and >> | >> >> | | Security Considerations >> | >> >> +--------------+----------------------------------------------------+ >> >> >> >> >> >> Figure 4 >> >> >> >> On Nov 19, 2012, at 1:24 PM, M Jenkins >> >> wrote: >> >> >> >>> I think that the current EST draft is weak when it comes to talking >> about trust anchors. Many of the right ideas are there, but a bit >> scattered >> about. Figure (Table) 3 has a lot of this information, but there's some >> fuzz in it, and it's not very explicit about how crucial TA >> initialization >> is to the security of the protocol. >> >>> >> >>> A specific concern is a perception that *any* trust anchor that >> happens to be in a trust anchor store might be used to terminate a >> certificate validation chain. The use of the phrase "third party Trust >> Anchor Database" is worrisome. Who cares if the TA comes from any >> (acceptable) third party - if you can't ensure that your validation >> chain >> is going to terminate in that TA in the first place? The present state >> of >> TA store management doesn't inherently provide this selectability. I >> think >> that explicit text is needed here. >> >>> >> >>> I would suggest that table in Figure 3 be replaced with something >> like >> the following: >> >>> >> >>> Trust Anchors >> >>> +--------------------------------------------------------------+ >> >>> | NOTE: EST Servers and Clients must be initialized to know | >> >>> | which specific public keys in their trust anchor | >> >>> | stores correspond to which function from this table. | >> >>> +---------------+----------------------------------------------+ >> >>> | CA Root | * End of validation path of all CA certs | >> >>> | public key | * End of validation path of Device Cert | >> >>> | | * May be identical to EST Server TA | >> >>> | | * May be identical to EST Client TA >> >>> | | * Obtainable by /CACerts command | >> >>> +---------------+----------------------------------------------+ >> >>> | EST Server TA | * End of validation path of EST Server cert | >> >>> | | * Must be securely installed to EST Client | >> >>> | | * Must be obtained securely, out-of-band | >> >>> +---------------+----------------------------------------------+ >> >>> | EST Client TA | * End of valid. path of EST Client init cert | >> >>> | | * Must be securely installed to EST Server | >> >>> | | * Must be obtained securely, out-of-band | >> >>> +---------------+----------------------------------------------+ >> >>> >> >>> Certificates >> >>> +---------------+----------------------------------------------+ >> >>> | CA Signing | * Crsp. private key signs Device Cert | >> >>> | Certificate | * Intermediate CA certs may exist in path | >> >>> | | * Obtainable by /CACerts command | >> >>> | | * Must be validated against CA Root >> >>> +---------------+----------------------------------------------+ >> >>> | EST Server | * Used by EST Client during TLS handshake | >> >>> | Certificate | * Must be validated against EST Server TA | >> >>> +---------------+----------------------------------------------+ >> >>> | EST Client | * Used by EST Server during initial enroll | >> >>> | Init Cert | (if certificate TLS auth used) | >> >>> | | * Must be validated against EST Client TA >> >>> +---------------+----------------------------------------------+ >> >>> | Device Cert | * Any certificate returned as a result of | >> >>> | | /simpleEnroll, /simpleReEnroll, /fullCMC, | >> >>> | | or /serverKeyGen | >> >>> | | * May be used for subsequent EST sessions | >> >>> +---------------+----------------------------------------------+ >> >>> | NOTE: The CA, EST Server, EST Client, and other servers may | >> >>> | have other certificates for other purposes, including | >> >>> | inter-server communication during EST sessions. | >> >>> +--------------------------------------------------------------+ >> >>> >> >>> Mike >> >> >> >> >> > >> >> > From bergtau@gmail.com Tue Dec 11 05:57:56 2012 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 46ECF21F8779 for ; Tue, 11 Dec 2012 05:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 xnXwddaFBe94 for ; Tue, 11 Dec 2012 05:57:55 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFD021F876A for ; Tue, 11 Dec 2012 05:57:54 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id z4so2932337qan.10 for ; Tue, 11 Dec 2012 05:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=deFslE2fMxj0/IZCKiqjmaDXxlhbZG/mYNBWjbVveq8=; b=qtKYfOFxKkArOdKJzi6i5Tttkk/qHnXe4kq731aLHtLRcpxpAqG946U5T2Psms2Y1A +zJJilEDMbZD/DAkP7q8iVTBV2sR+nvbDQhtazVEfcsRfM8GZwrQOXeVxgWfkbt/OmlL roqFyi25yiXNoY/1EqQ5Pxfqjgg3H6MmngHDZ/VFjKJUi7CKRaAtsq9hi13emLgmkrcA NZP7CDKctgTe2eaNp1sqjhh7HAUSjSKbuRmKDRK6SmCQH01Wc6AajxdtOnVuh2ZvvFsg PYInbXbxJJ1O51vFt/HKWqsS0AQ6byqAPmhzyn7hnQ2dHBsVaFHUp8SzsRhcHhiVAfwt 7YlA== Received: by 10.49.127.238 with SMTP id nj14mr40163468qeb.9.1355234274349; Tue, 11 Dec 2012 05:57:54 -0800 (PST) Received: from rd2ul-30202l.infosec.tycho.ncsc.mil ([144.51.26.145]) by mx.google.com with ESMTPS id r13sm16033766qeu.11.2012.12.11.05.57.52 (version=SSLv3 cipher=OTHER); Tue, 11 Dec 2012 05:57:53 -0800 (PST) Message-ID: <50C73BDF.4030508@gmail.com> Date: Tue, 11 Dec 2012 08:57:51 -0500 From: M Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121116 Thunderbird/10.0.11 MIME-Version: 1.0 References: <50AA956B.10000@gmail.com> <53EA47528D6ACF4486AA152F92C2B6982E9D7E@xmb-rcd-x03.cisco.com> <53EA47528D6ACF4486AA152F92C2B698B90D7A@xmb-rcd-x03.cisco.com> <272834c531520b7e91723a0d303c8260.squirrel@www.trepanning.net> In-Reply-To: <272834c531520b7e91723a0d303c8260.squirrel@www.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] EST trust anchor definition 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, 11 Dec 2012 13:57:56 -0000 Sorry, hadn't noticed that I didn't send this to the list. Hi Dan. I'm concerned that the client can trust the contents of the cert (know that it has validated the correct cert) before it starts using the contents to check the server name. Likewise for the server, if the client has been initialized with an "enrollment certificate" (say by the vendor; the trust anchor would be provided by the vendor separately to the EST server operator). On 12/06/2012 01:01 PM, Dan Harkins wrote: > Hello, > > Perhaps I'm missing something but the "selected TA database" is allowing > the client to verify the trustworthiness of the EST server's certificate. The > client is still supposed to decide whether this is the _correct_ EST > server by > checking the contents of the certificate against whatever policy might > be configured as well as performing the TLS handshake and ensuring > that the EST server holds the private analog to the authenticated public > key it now holds. > > To stretch your analogy, the "selected TA database" is allowing you to > determine whether this is a bonafide Schlage deadbolt lock that you're > looking at. Whether it's _your_ bonafide Schlage deadbolt lock is the > next step you have to do by putting your key into the lock and seeing > whether it opens the door. If your neighbor's rabid dog bites you then > it's a sign that 2 keys open the same door which is a failure of a different > kind. > > Dan. > > On Thu, December 6, 2012 8:13 am, Michael Jenkins wrote: >> I suppose that helps - but it's more wordy and less clear, and therefore >> more prone to error. It's not that the system supporting the EST client >> can't have a TA database - I'm assuming it will. It's that the database is >> irrelevant to the protocol. I don't unlock the lock on my front door with >> a >> keyring, I do it with a key. Whether I only have one key, or whether I >> have >> 100, and whether I keep my 100 on a ring or in a box, is irrelevant. >> >> Crucially, I have to make sure the wrong thing doesn't happen. Say that I >> have a key to my neighbor's house. I want to enter my house. If my >> neighbor's house and mine look alike, and I walk up to his house by >> mistake, and I "use my keyring" to unlock the lock on the door - it works! >> Which is unfortunate for me, because his rabid dog just bit my leg. >> >> The problem I'm having with "TA Database" is that such databases are >> generally designed to make things work, not to make things work only in >> certain circumstances, as defined by the operator or local admin. It's no >> accident that most consumer systems come with a laundry-list of trust >> anchors, and there generally isn't any notification to the operator that >> any particular one was used during any particular transaction. >> >> Saying "use the TA Database" requires me to think up all of the ways that >> applying the entire database to my protocol might fail, and say how to >> prevent them. Saying "use only the XYZ trust anchor" is much more clear >> and >> precise. How to ensure that that particular trust anchor gets used is up >> to >> the system designer - which is a good thing, because I don't think it's >> desired that EST be limited to any one particular type of client system. >> >> >> On Wed, Dec 5, 2012 at 5:52 PM, Max Pritikin (pritikin) >> wrote: >> >>> (I corrected Peter Yee's email address) >>> >>> On Dec 5, 2012, at 3:50 PM, Max Pritikin wrote: >>> >>>> On Dec 4, 2012, at 9:55 PM, Michael Jenkins wrote: >>>> >>>>> I think that the tables, broken out according to TAs and Certs, are a >>> big improvement. However, the TA table has really taken a hard turn >>> /away/ >>> from the ability to specify a single TA as the one to use for EST. >>>> What prevents the client from having a "Third-Party TA Database" that >>> contains only TA's (or a single TA) to be used for EST? >>>>> Without digging through a lot of cert guts over and over, I'll never >>> know if any particular validation is terminating in the selected TA, be >>> it >>> a provided vendor-supplied initialization root, or a "public" CA, or a >>> locally supplied root. I'm not prejudiced toward one or the other of >>> those >>> options, as long as it's the one I've initially configured - that is, as >>> long as I have a way of expressing which TA must terminate my EST >>> transactions. >>>>> Ideally that would happen through some kind of labeling, but I don't >>> think that there's anything that does that now, natively, in a system >>> trust >>> anchor store. Other solutions would be to remove all trust anchors >>> /except/ >>> the selected one (drastic, but might work for some specific-use >>> devices), >>> or to configure the EST client app with a keyID for the selected trust >>> anchor (and then check that it's the one used). >>>>> The draft does say that the client needs to be configured with the >>> correct trust anchor (through out-of-band means), but after that all >>> references to TAs are "TA Database". If I can't guarantee that I'm using >>> the TA that I configured, there was no point in configuring one. >>>> We can make this the "selected TA Database" and we can indicate that: >>>> >>>> "The Client MUST support a configurable option to enable checking all >>> or >>>> a subset of either the EST client Third-Party TA database or the EST >>>> client TA database." >>>> >>>> Would that address your concerns? >>>> >>>> - max >>>> >>>> >>>>> Hope that makes sense. If I'm interpreting the table incorrectly, let >>> me know where I went wrong. >>>>> Mike >>>>> >>>>> >>>>> On Mon, Nov 19, 2012 at 3:56 PM, Max Pritikin (pritikin)< >>> pritikin@cisco.com> wrote: >>>>> Thanks for all the feedback. We've already updated the table similar >>> to >>> what you recommend below so its good to see we're on the same page. >>>>> Below is the current table in our working copy. I'll read through >>> your >>> suggestions carefully to see if additional clarity can be gained. >>>>> Similarly I'll go through you other email of specific feedback and >>> merge them to the revisions we've made since the ietf85 meeting. >>>>> - max >>>>> >>>>> Current table in our working revision (best viewed in monospaced >>> font): >>>>> Certificates and their corresponding uses: >>>>> +--------------+--------------------+-------------------------------+ >>>>> | Certificate | Issuer | Use and section references >>> | >>>>> +==============+====================+===============================+ >>>>> | EST server | The CA served by | Presented by the EST server >>> | >>>>> | certificate | the EST server | during the TLS handshake >>> | >>>>> | | | >>> | >>>>> | | | Section 3.3.1.1 >>> | >>>>> +--------------+--------------------+-------------------------------+ >>>>> | EST server | A CA | Presented by the EST server >>> | >>>>> | certificate | authenticatable by | during the TLS handshake >>> | >>>>> | | a third-party TA | >>> | >>>>> | | | Section 3.3.1.1, and >>> | >>>>> | | | Security Considerations >>> | >>>>> +--------------+--------------------+-------------------------------+ >>>>> | EST client | A CA | Presented by the EST client >>> | >>>>> | certificate | authenticatable by | to the EST server by clients >>> | >>>>> | | a third-party TA | that have not yet enrolled >>> | >>>>> | | e.g., a device | >>> | >>>>> | | manufacturer | Section 3.3.1.2 >>> | >>>>> +--------------+--------------------+-------------------------------+ >>>>> | EST client | The CA served by | Presented by the EST client >>> | >>>>> | certificate | the EST server | to PKI End Entities. >>> | >>>>> | | | Including to the EST server >>> | >>>>> | | | during future EST operations >>> | >>>>> | | | >>> | >>>>> | | | Section 3.3.1.2 >>> | >>>>> +--------------+--------------------+-------------------------------+ >>>>> | EST client | The CA served by | Presented by the EST client >>> | >>>>> | certificate | the EST server | to PKI End Entities. >>> | >>>>> | | | Clients can obtain certs >>> | >>>>> | | | that can not be used for EST >>> | >>>>> | | | client authentication >>> | >>>>> | | | >>> | >>>>> | | | Section 4.4.1 >>> | >>>>> +--------------+--------------------+-------------------------------+ >>>>> >>>>> >>>>> Figure 3 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Pritikin, et al. Expires May 21, 2013 [Page >>> 12] >>>>> Internet-Draft EST November >>> 2012 >>>>> >>>>> Trust Anchor databases and their corresponding uses: >>>>> +--------------+----------------------------------------------------+ >>>>> | TA database | Use and section references >>> | >>>>> +==============+====================================================+ >>>>> | EST server | EST servers use this TA database to authenticate >>> | >>>>> | TA database | certificates issued by the CA, including EST >>> | >>>>> | | client certificates during enroll/re-enroll >>> | >>>>> | | operations >>> | >>>>> | | >>> | >>>>> | | Section 3.3.1.2 >>> | >>>>> +--------------+----------------------------------------------------+ >>>>> | EST server | EST servers use this TA database to authenticate >>> | >>>>> | Third-Party | certificates issued by third-party TAs. >>> | >>>>> | TA database | e.g., EST client certificates issued by a device >>> | >>>>> | | manufacturer >>> | >>>>> | | >>> | >>>>> | | Section 3.3.1.2 >>> | >>>>> +--------------+----------------------------------------------------+ >>>>> | EST client | EST clients use this TA database to authenticate >>> | >>>>> | EST CA | certificates issued by the EST CA, including EST >>> | >>>>> | TA database | server certificates. >>> | >>>>> | | >>> | >>>>> | | Section 3.3.1.1 and >>> | >>>>> | | Section 4.3 >>> | >>>>> +--------------+----------------------------------------------------+ >>>>> | EST client | EST clients use this trust anchor database to >>> | >>>>> | Third-Party | authenticate an EST server that uses an externally >>> | >>>>> | TA database | issued certificate. >>> | >>>>> | | >>> | >>>>> | | >>> | >>>>> | | Section 3.3.1.1 and >>> | >>>>> | | Security Considerations >>> | >>>>> +--------------+----------------------------------------------------+ >>>>> >>>>> >>>>> Figure 4 >>>>> >>>>> On Nov 19, 2012, at 1:24 PM, M Jenkins >>>>> wrote: >>>>> >>>>>> I think that the current EST draft is weak when it comes to talking >>> about trust anchors. Many of the right ideas are there, but a bit >>> scattered >>> about. Figure (Table) 3 has a lot of this information, but there's some >>> fuzz in it, and it's not very explicit about how crucial TA >>> initialization >>> is to the security of the protocol. >>>>>> A specific concern is a perception that *any* trust anchor that >>> happens to be in a trust anchor store might be used to terminate a >>> certificate validation chain. The use of the phrase "third party Trust >>> Anchor Database" is worrisome. Who cares if the TA comes from any >>> (acceptable) third party - if you can't ensure that your validation >>> chain >>> is going to terminate in that TA in the first place? The present state >>> of >>> TA store management doesn't inherently provide this selectability. I >>> think >>> that explicit text is needed here. >>>>>> I would suggest that table in Figure 3 be replaced with something >>> like >>> the following: >>>>>> Trust Anchors >>>>>> +--------------------------------------------------------------+ >>>>>> | NOTE: EST Servers and Clients must be initialized to know | >>>>>> | which specific public keys in their trust anchor | >>>>>> | stores correspond to which function from this table. | >>>>>> +---------------+----------------------------------------------+ >>>>>> | CA Root | * End of validation path of all CA certs | >>>>>> | public key | * End of validation path of Device Cert | >>>>>> | | * May be identical to EST Server TA | >>>>>> | | * May be identical to EST Client TA >>>>>> | | * Obtainable by /CACerts command | >>>>>> +---------------+----------------------------------------------+ >>>>>> | EST Server TA | * End of validation path of EST Server cert | >>>>>> | | * Must be securely installed to EST Client | >>>>>> | | * Must be obtained securely, out-of-band | >>>>>> +---------------+----------------------------------------------+ >>>>>> | EST Client TA | * End of valid. path of EST Client init cert | >>>>>> | | * Must be securely installed to EST Server | >>>>>> | | * Must be obtained securely, out-of-band | >>>>>> +---------------+----------------------------------------------+ >>>>>> >>>>>> Certificates >>>>>> +---------------+----------------------------------------------+ >>>>>> | CA Signing | * Crsp. private key signs Device Cert | >>>>>> | Certificate | * Intermediate CA certs may exist in path | >>>>>> | | * Obtainable by /CACerts command | >>>>>> | | * Must be validated against CA Root >>>>>> +---------------+----------------------------------------------+ >>>>>> | EST Server | * Used by EST Client during TLS handshake | >>>>>> | Certificate | * Must be validated against EST Server TA | >>>>>> +---------------+----------------------------------------------+ >>>>>> | EST Client | * Used by EST Server during initial enroll | >>>>>> | Init Cert | (if certificate TLS auth used) | >>>>>> | | * Must be validated against EST Client TA >>>>>> +---------------+----------------------------------------------+ >>>>>> | Device Cert | * Any certificate returned as a result of | >>>>>> | | /simpleEnroll, /simpleReEnroll, /fullCMC, | >>>>>> | | or /serverKeyGen | >>>>>> | | * May be used for subsequent EST sessions | >>>>>> +---------------+----------------------------------------------+ >>>>>> | NOTE: The CA, EST Server, EST Client, and other servers may | >>>>>> | have other certificates for other purposes, including | >>>>>> | inter-server communication during EST sessions. | >>>>>> +--------------------------------------------------------------+ >>>>>> >>>>>> Mike >>>>> >>> > From piyush@ditenity.com Tue Dec 11 12:00:25 2012 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 C2CEB21F84FA for ; Tue, 11 Dec 2012 12:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JUjf6whAxdn for ; Tue, 11 Dec 2012 12:00:20 -0800 (PST) Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 915F021E804A for ; Tue, 11 Dec 2012 12:00:19 -0800 (PST) Received: by mail-yh0-f54.google.com with SMTP id s35so997729yhf.27 for ; Tue, 11 Dec 2012 12:00:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=WkHuhCOWw1+iHWVv4aEBF8wpHDejNw2R/PVVXEY8Bj4=; b=cwu8V+DFDUQMsad6GaY6wyoKwWCseRlE+bZTGkm2XjDfI5R/fGcLDDdfFDpwQXp0ar Bbm2TAKxmP/7GGYbGZIsq2AGwTvSBWOSzIXzb8dKTyAtPl2EcMOX9OyjmuClz8Hbj+aB 4EB6zhuWLVUjxqtAbcY5kCcEmKHPT0xcUk6LqPWqn3pKgjN08WdCM9wf+mgLvQR43TOw 93bSF7529/EQDXxec+pwNY8W+WJiPccdfll4XY50H4pntE+Vtq8q/DmAo8MjrjyKd/YY fdL7WC6zF2LunNtI52RMy+JYW8QGnBq/n24qPl/yCs1o8/WyyKDYUyL/Q02LVxOKWWHR Mt+g== Received: by 10.236.81.36 with SMTP id l24mr30010933yhe.93.1355256018720; Tue, 11 Dec 2012 12:00:18 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id z1sm29531642anj.2.2012.12.11.12.00.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Dec 2012 12:00:17 -0800 (PST) From: "Piyush Jain" To: "'M Jenkins'" References: <50AA956B.10000@gmail.com> <53EA47528D6ACF4486AA152F92C2B6982E9D7E@xmb-rcd-x03.cisco.com> <53EA47528D6ACF4486AA152F92C2B698B90D7A@xmb-rcd-x03.cisco.com> <272834c531520b7e91723a0d303c8260.squirrel@www.trepanning.net> <50C73BDF.4030508@gmail.com> In-Reply-To: <50C73BDF.4030508@gmail.com> Date: Tue, 11 Dec 2012 12:00:10 -0800 Message-ID: <019401cdd7da$212fde40$638f9ac0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJE93s3uxalBxdQy1GdTaiFQ3HnOAL1Xe+qAyo+whIBy6AImwFSDNIQAieLw0IBkddQgQHCzhEOlq/xUUA= Content-Language: en-us X-Gm-Message-State: ALoCoQkI0gGyR0yW3WLcu+O+e9g/Vmqgctx3xw+bHcHG8zSjKuqq+HB0P12e63UbvskeCxrr2T2P Cc: pkix@ietf.org Subject: Re: [pkix] EST trust anchor definition 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, 11 Dec 2012 20:00:26 -0000 I agree with you that some of the details about how the client trusts the server certificate are irrelevant to the protocol. I think that the draft should just specify the attributes of a trustworthy server certificate and leave the details of how that trustworthiness is determined to the client implementation. Whether it is done using local TA database, a local TA certificate or by sending the request to a DPV server is irrelevant. There may be scenarios where client may want to apply different server certificate validation policy depending on which EST server it is talking to (Getting a personal certificate from a public CA vs. getting a VPN client certificate from the enterprise. Bundling both the public CA root and the enterprise CA root in the same TA database should not be done in this case. -Piyush > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > M Jenkins > Sent: Tuesday, December 11, 2012 5:58 AM > Cc: pkix@ietf.org > Subject: Re: [pkix] EST trust anchor definition > > Sorry, hadn't noticed that I didn't send this to the list. > > Hi Dan. I'm concerned that the client can trust the contents of the cert (know > that it has validated the correct cert) before it starts using the contents to > check the server name. Likewise for the server, if the client has been > initialized with an "enrollment certificate" (say by the vendor; the trust > anchor would be provided by the vendor separately to the EST server > operator). > > On 12/06/2012 01:01 PM, Dan Harkins wrote: > > Hello, > > > > Perhaps I'm missing something but the "selected TA database" is > > allowing the client to verify the trustworthiness of the EST server's > > certificate. The client is still supposed to decide whether this is > > the _correct_ EST server by checking the contents of the certificate > > against whatever policy might be configured as well as performing the > > TLS handshake and ensuring that the EST server holds the private > > analog to the authenticated public key it now holds. > > > > To stretch your analogy, the "selected TA database" is allowing you > > to determine whether this is a bonafide Schlage deadbolt lock that > > you're looking at. Whether it's _your_ bonafide Schlage deadbolt lock > > is the next step you have to do by putting your key into the lock and > > seeing whether it opens the door. If your neighbor's rabid dog bites > > you then it's a sign that 2 keys open the same door which is a failure > > of a different kind. > > > > Dan. > > > > On Thu, December 6, 2012 8:13 am, Michael Jenkins wrote: > >> I suppose that helps - but it's more wordy and less clear, and > >> therefore more prone to error. It's not that the system supporting > >> the EST client can't have a TA database - I'm assuming it will. It's > >> that the database is irrelevant to the protocol. I don't unlock the > >> lock on my front door with a keyring, I do it with a key. Whether I > >> only have one key, or whether I have 100, and whether I keep my 100 > >> on a ring or in a box, is irrelevant. > >> > >> Crucially, I have to make sure the wrong thing doesn't happen. Say > >> that I have a key to my neighbor's house. I want to enter my house. > >> If my neighbor's house and mine look alike, and I walk up to his > >> house by mistake, and I "use my keyring" to unlock the lock on the door - > it works! > >> Which is unfortunate for me, because his rabid dog just bit my leg. > >> > >> The problem I'm having with "TA Database" is that such databases are > >> generally designed to make things work, not to make things work only > >> in certain circumstances, as defined by the operator or local admin. > >> It's no accident that most consumer systems come with a laundry-list > >> of trust anchors, and there generally isn't any notification to the > >> operator that any particular one was used during any particular > transaction. > >> > >> Saying "use the TA Database" requires me to think up all of the ways > >> that applying the entire database to my protocol might fail, and say > >> how to prevent them. Saying "use only the XYZ trust anchor" is much > >> more clear and precise. How to ensure that that particular trust > >> anchor gets used is up to the system designer - which is a good > >> thing, because I don't think it's desired that EST be limited to any > >> one particular type of client system. > >> > >> > >> On Wed, Dec 5, 2012 at 5:52 PM, Max Pritikin (pritikin) > >> wrote: > >> > >>> (I corrected Peter Yee's email address) > >>> > >>> On Dec 5, 2012, at 3:50 PM, Max Pritikin wrote: > >>> > >>>> On Dec 4, 2012, at 9:55 PM, Michael Jenkins > wrote: > >>>> > >>>>> I think that the tables, broken out according to TAs and Certs, > >>>>> are a > >>> big improvement. However, the TA table has really taken a hard turn > >>> /away/ from the ability to specify a single TA as the one to use for > >>> EST. > >>>> What prevents the client from having a "Third-Party TA Database" > >>>> that > >>> contains only TA's (or a single TA) to be used for EST? > >>>>> Without digging through a lot of cert guts over and over, I'll > >>>>> never > >>> know if any particular validation is terminating in the selected TA, > >>> be it a provided vendor-supplied initialization root, or a "public" > >>> CA, or a locally supplied root. I'm not prejudiced toward one or the > >>> other of those options, as long as it's the one I've initially > >>> configured - that is, as long as I have a way of expressing which TA > >>> must terminate my EST transactions. > >>>>> Ideally that would happen through some kind of labeling, but I > >>>>> don't > >>> think that there's anything that does that now, natively, in a > >>> system trust anchor store. Other solutions would be to remove all > >>> trust anchors /except/ the selected one (drastic, but might work for > >>> some specific-use devices), or to configure the EST client app with > >>> a keyID for the selected trust anchor (and then check that it's the > >>> one used). > >>>>> The draft does say that the client needs to be configured with the > >>> correct trust anchor (through out-of-band means), but after that all > >>> references to TAs are "TA Database". If I can't guarantee that I'm > >>> using the TA that I configured, there was no point in configuring one. > >>>> We can make this the "selected TA Database" and we can indicate that: > >>>> > >>>> "The Client MUST support a configurable option to enable checking > >>>> all > >>> or > >>>> a subset of either the EST client Third-Party TA database or the > >>>> EST client TA database." > >>>> > >>>> Would that address your concerns? > >>>> > >>>> - max > >>>> > >>>> > >>>>> Hope that makes sense. If I'm interpreting the table incorrectly, > >>>>> let > >>> me know where I went wrong. > >>>>> Mike > >>>>> > >>>>> > >>>>> On Mon, Nov 19, 2012 at 3:56 PM, Max Pritikin (pritikin)< > >>> pritikin@cisco.com> wrote: > >>>>> Thanks for all the feedback. We've already updated the table > >>>>> similar > >>> to > >>> what you recommend below so its good to see we're on the same page. > >>>>> Below is the current table in our working copy. I'll read through > >>> your > >>> suggestions carefully to see if additional clarity can be gained. > >>>>> Similarly I'll go through you other email of specific feedback and > >>> merge them to the revisions we've made since the ietf85 meeting. > >>>>> - max > >>>>> > >>>>> Current table in our working revision (best viewed in monospaced > >>> font): > >>>>> Certificates and their corresponding uses: > >>>>> +--------------+--------------------+-------------------------------+ > >>>>> | Certificate | Issuer | Use and section references > >>> | > >>>>> > +==============+====================+===================== > ==========+ > >>>>> | EST server | The CA served by | Presented by the EST server > >>> | > >>>>> | certificate | the EST server | during the TLS handshake > >>> | > >>>>> | | | > >>> | > >>>>> | | | Section 3.3.1.1 > >>> | > >>>>> +--------------+--------------------+-------------------------------+ > >>>>> | EST server | A CA | Presented by the EST server > >>> | > >>>>> | certificate | authenticatable by | during the TLS handshake > >>> | > >>>>> | | a third-party TA | > >>> | > >>>>> | | | Section 3.3.1.1, and > >>> | > >>>>> | | | Security Considerations > >>> | > >>>>> +--------------+--------------------+-------------------------------+ > >>>>> | EST client | A CA | Presented by the EST client > >>> | > >>>>> | certificate | authenticatable by | to the EST server by > >>>>> clients > >>> | > >>>>> | | a third-party TA | that have not yet enrolled > >>> | > >>>>> | | e.g., a device | > >>> | > >>>>> | | manufacturer | Section 3.3.1.2 > >>> | > >>>>> +--------------+--------------------+-------------------------------+ > >>>>> | EST client | The CA served by | Presented by the EST client > >>> | > >>>>> | certificate | the EST server | to PKI End Entities. > >>> | > >>>>> | | | Including to the EST server > >>> | > >>>>> | | | during future EST operations > >>> | > >>>>> | | | > >>> | > >>>>> | | | Section 3.3.1.2 > >>> | > >>>>> +--------------+--------------------+-------------------------------+ > >>>>> | EST client | The CA served by | Presented by the EST client > >>> | > >>>>> | certificate | the EST server | to PKI End Entities. > >>> | > >>>>> | | | Clients can obtain certs > >>> | > >>>>> | | | that can not be used for EST > >>> | > >>>>> | | | client authentication > >>> | > >>>>> | | | > >>> | > >>>>> | | | Section 4.4.1 > >>> | > >>>>> > >>>>> +--------------+--------------------+----------------------------- > >>>>> --+ > >>>>> > >>>>> > >>>>> Figure 3 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Pritikin, et al. Expires May 21, 2013 [Page > >>> 12] > >>>>> Internet-Draft EST November > >>> 2012 > >>>>> > >>>>> Trust Anchor databases and their corresponding uses: > >>>>> +--------------+----------------------------------------------------+ > >>>>> | TA database | Use and section references > >>> | > >>>>> > +==============+========================================== > ==========+ > >>>>> | EST server | EST servers use this TA database to authenticate > >>> | > >>>>> | TA database | certificates issued by the CA, including EST > >>> | > >>>>> | | client certificates during enroll/re-enroll > >>> | > >>>>> | | operations > >>> | > >>>>> | | > >>> | > >>>>> | | Section 3.3.1.2 > >>> | > >>>>> +--------------+----------------------------------------------------+ > >>>>> | EST server | EST servers use this TA database to authenticate > >>> | > >>>>> | Third-Party | certificates issued by third-party TAs. > >>> | > >>>>> | TA database | e.g., EST client certificates issued by a > >>>>> device > >>> | > >>>>> | | manufacturer > >>> | > >>>>> | | > >>> | > >>>>> | | Section 3.3.1.2 > >>> | > >>>>> +--------------+----------------------------------------------------+ > >>>>> | EST client | EST clients use this TA database to authenticate > >>> | > >>>>> | EST CA | certificates issued by the EST CA, including EST > >>> | > >>>>> | TA database | server certificates. > >>> | > >>>>> | | > >>> | > >>>>> | | Section 3.3.1.1 and > >>> | > >>>>> | | Section 4.3 > >>> | > >>>>> +--------------+----------------------------------------------------+ > >>>>> | EST client | EST clients use this trust anchor database to > >>> | > >>>>> | Third-Party | authenticate an EST server that uses an > >>>>> externally > >>> | > >>>>> | TA database | issued certificate. > >>> | > >>>>> | | > >>> | > >>>>> | | > >>> | > >>>>> | | Section 3.3.1.1 and > >>> | > >>>>> | | Security Considerations > >>> | > >>>>> > >>>>> +--------------+-------------------------------------------------- > >>>>> --+ > >>>>> > >>>>> > >>>>> Figure 4 > >>>>> > >>>>> On Nov 19, 2012, at 1:24 PM, M Jenkins > >>>>> wrote: > >>>>> > >>>>>> I think that the current EST draft is weak when it comes to > >>>>>> talking > >>> about trust anchors. Many of the right ideas are there, but a bit > >>> scattered about. Figure (Table) 3 has a lot of this information, but > >>> there's some fuzz in it, and it's not very explicit about how > >>> crucial TA initialization is to the security of the protocol. > >>>>>> A specific concern is a perception that *any* trust anchor that > >>> happens to be in a trust anchor store might be used to terminate a > >>> certificate validation chain. The use of the phrase "third party > >>> Trust Anchor Database" is worrisome. Who cares if the TA comes from > >>> any > >>> (acceptable) third party - if you can't ensure that your validation > >>> chain is going to terminate in that TA in the first place? The > >>> present state of TA store management doesn't inherently provide this > >>> selectability. I think that explicit text is needed here. > >>>>>> I would suggest that table in Figure 3 be replaced with something > >>> like > >>> the following: > >>>>>> Trust Anchors > >>>>>> +--------------------------------------------------------------+ > >>>>>> | NOTE: EST Servers and Clients must be initialized to know | > >>>>>> | which specific public keys in their trust anchor | > >>>>>> | stores correspond to which function from this table. | > >>>>>> +---------------+----------------------------------------------+ > >>>>>> | CA Root | * End of validation path of all CA certs | > >>>>>> | public key | * End of validation path of Device Cert | > >>>>>> | | * May be identical to EST Server TA | > >>>>>> | | * May be identical to EST Client TA > >>>>>> | | * Obtainable by /CACerts command | > >>>>>> +---------------+----------------------------------------------+ > >>>>>> | EST Server TA | * End of validation path of EST Server cert | > >>>>>> | | * Must be securely installed to EST Client | > >>>>>> | | * Must be obtained securely, out-of-band | > >>>>>> +---------------+----------------------------------------------+ > >>>>>> | EST Client TA | * End of valid. path of EST Client init cert | > >>>>>> | | * Must be securely installed to EST Server | > >>>>>> | | * Must be obtained securely, out-of-band | > >>>>>> +---------------+----------------------------------------------+ > >>>>>> > >>>>>> Certificates > >>>>>> +---------------+----------------------------------------------+ > >>>>>> | CA Signing | * Crsp. private key signs Device Cert | > >>>>>> | Certificate | * Intermediate CA certs may exist in path | > >>>>>> | | * Obtainable by /CACerts command | > >>>>>> | | * Must be validated against CA Root > >>>>>> +---------------+----------------------------------------------+ > >>>>>> | EST Server | * Used by EST Client during TLS handshake | > >>>>>> | Certificate | * Must be validated against EST Server TA | > >>>>>> +---------------+----------------------------------------------+ > >>>>>> | EST Client | * Used by EST Server during initial enroll | > >>>>>> | Init Cert | (if certificate TLS auth used) | > >>>>>> | | * Must be validated against EST Client TA > >>>>>> +---------------+----------------------------------------------+ > >>>>>> | Device Cert | * Any certificate returned as a result of | > >>>>>> | | /simpleEnroll, /simpleReEnroll, /fullCMC, | > >>>>>> | | or /serverKeyGen | > >>>>>> | | * May be used for subsequent EST sessions | > >>>>>> +---------------+----------------------------------------------+ > >>>>>> | NOTE: The CA, EST Server, EST Client, and other servers may | > >>>>>> | have other certificates for other purposes, including | > >>>>>> | inter-server communication during EST sessions. | > >>>>>> +--------------------------------------------------------------+ > >>>>>> > >>>>>> Mike > >>>>> > >>> > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From bruce.stephens@isode.com Thu Dec 13 08:20:03 2012 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 78D5821F8A28 for ; Thu, 13 Dec 2012 08:20:03 -0800 (PST) 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 oAJ7A0+N2xQK for ; Thu, 13 Dec 2012 08:20:02 -0800 (PST) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id E66E821F8A85 for ; Thu, 13 Dec 2012 08:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1355415596; d=isode.com; s=selector; i=@isode.com; bh=9axlQGFsjmr/xeiu9Op0jsNzD/HEcuz5oXZ4+JHKPj0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Hos6wTlHFg8a51BmVXi5XhXOiX6I/dPC6jKzPfmE8VO9L7jbSIJLGOMb8tnKp1gASDso06 NuMAyhReuwX6GO7SwegUGl7Z0kh3Ath3vKr/4sOBguZJ50yHdofM4MjbqTFKc8dM0QRGnA dFmu1INVBSdgkoOC4iST/QAhCNYhT9I=; Received: from tinier.isode.net (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id for ; Thu, 13 Dec 2012 16:19:54 +0000 Received: by tinier.isode.net (sSMTP sendmail emulation); Thu, 13 Dec 2012 16:19:54 +0000 From: Bruce Stephens To: pkix@ietf.org References: X-Hashcash: 1:20:121213:pkix@ietf.org::bDGDRu5NHreYWDc0:0000IEf7 Date: Thu, 13 Dec 2012 16:19:54 +0000 In-Reply-To: (Erwann Abalea's message of "Fri, 20 Jul 2012 19:16:12 +0200") Message-ID: <801uetorf9.fsf_-_@tinier.isode.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [pkix] url-encoding of OCSP HTTP GET requests (was Re: OCSP POST vs GET) 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, 13 Dec 2012 16:20:03 -0000 Erwann Abalea writes: > The "malformedRequest" response is the 5 bytes response it received (the = 5 at the end is the body size of the response). > > There's an extra leading '/' in the request. It may come from an extra tr= ailing '/' at the OCSP URL. Check your certificates, read the authorityInfo= Access extension. > > RFC2560 states this: > > [...] > GET {url}/{url-encoding of base-64 encoding of the DER encoding of > =C2=A0 =C2=A0the OCSPRequest} > [...] Is the {url-encoding} part required by anybody? That is, if my base64-encoded request is MEIwQDA+MDwwOjAJBgUrDgMCGgUABBRDjd0Ecx6qe7r2TYbGngjZE/bxaQQUj76OSES03/qykJ= F0zQNXx//ovQwCAWU=3D my reading of appendix A of RFC 2560 suggests I ought to quote the special characters (in particular / should be %2F, + should be %2B). Verisign's OCSP responder seems OK with that, but also seems fine without url-encoding. However, http://seclab7.ncsl.nist.gov (the responder used for the NIST PIV test cards) seems to reject url-encoded GET requests as malformed. It responds to requests that are just base64 encoded (and responds to HTTP POST as in the RFC). Is that a bug in the responder (or is my url-encoding subtly wrong in some way, though I'm using libcurl so I'm inclined to think it's probably correct)? (I guess my real question is whether it's safer to just ignore the RFC and remove the url-encoding call.) [...] From eabalea@gmail.com Thu Dec 13 09:47:35 2012 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 8556C21F88D5 for ; Thu, 13 Dec 2012 09:47:35 -0800 (PST) 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 VxqTCrw8HyV6 for ; Thu, 13 Dec 2012 09:47:31 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87ED921F89F2 for ; Thu, 13 Dec 2012 09:47:30 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2008791lbk.31 for ; Thu, 13 Dec 2012 09:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ASXoPhbHzQyz5K+NY4K7VpElASQHsMxtP8nhyO8IrkM=; b=W4oFdA6TYX+XJAXAd7KUqUaSMA7eESZ8DYPHEpBC6lJNan+D5Cv1nJVvaDe5SIMNEI gKMGK80vZQyQYLqjOcHyukdVYbGFR1MEwCULU0K3LTCQ19sq6HO4yEQ5uXT5/XrO0vSD DtyE7yz7XUQ0KRZTT9fw+fb5dZy9qaIpJf0Scnq8zyXSPp18v92JV2b8SN887rChzMND 9Ld+T6LtPodZuW2hMCZSXGDCcVVFafkn/u9dtrLucVWx/P8LuIKv7+7omuzfRnKMTgcz rbl7B8dlX9XzcXXbqeGnuBWNYkO9+VeZHbl0Cnv0WeoeELD0PH79WgtgfCIHZ4DCF2cm 6j7A== MIME-Version: 1.0 Received: by 10.112.54.6 with SMTP id f6mr1267757lbp.71.1355420849343; Thu, 13 Dec 2012 09:47:29 -0800 (PST) Received: by 10.114.17.167 with HTTP; Thu, 13 Dec 2012 09:47:29 -0800 (PST) In-Reply-To: <801uetorf9.fsf_-_@tinier.isode.net> References: <801uetorf9.fsf_-_@tinier.isode.net> Date: Thu, 13 Dec 2012 18:47:29 +0100 Message-ID: From: Erwann Abalea To: Bruce Stephens Content-Type: multipart/alternative; boundary=bcaec55400703f0e0a04d0bf8221 Cc: pkix@ietf.org Subject: Re: [pkix] url-encoding of OCSP HTTP GET requests (was Re: OCSP POST vs GET) 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, 13 Dec 2012 17:47:35 -0000 --bcaec55400703f0e0a04d0bf8221 Content-Type: text/plain; charset=UTF-8 Bonjour, 2012/12/13 Bruce Stephens > Erwann Abalea writes: > > > The "malformedRequest" response is the 5 bytes response it received (the > 5 at the end is the body size of the response). > > > > There's an extra leading '/' in the request. It may come from an extra > trailing '/' at the OCSP URL. Check your certificates, read the > authorityInfoAccess extension. > > > > RFC2560 states this: > > > > [...] > > GET {url}/{url-encoding of base-64 encoding of the DER encoding of > > the OCSPRequest} > > [...] > > Is the {url-encoding} part required by anybody? That is, if my > During my tests of OCSP responders, I've come accross responders that couldn't deal with non URL-encoded requests. '/', '+', and '=' are classified as "reserved" characters by RFC2396, and must be escaped (see 2.4, 2.4.2, 2.3). > base64-encoded request is > > > MEIwQDA+MDwwOjAJBgUrDgMCGgUABBRDjd0Ecx6qe7r2TYbGngjZE/bxaQQUj76OSES03/qykJF0zQNXx//ovQwCAWU= > > my reading of appendix A of RFC 2560 suggests I ought to quote the > special characters (in particular / should be %2F, + should be > %2B). Verisign's OCSP responder seems OK with that, but also seems fine > without url-encoding. > A lot of well-behaving OCSP responders accept both forms. > However, http://seclab7.ncsl.nist.gov (the responder used for the NIST > PIV test cards) seems to reject url-encoded GET requests as > malformed. It responds to requests that are just base64 encoded (and > responds to HTTP POST as in the RFC). > That's a bug in the responder. RFC2398/2.4.2 is non ambiguous on this point, an URI is always in escaped form, and as such MUST be unescaped before being processed. I hadn't played with this responder (because I don't have certificates to test it), but you could try to only escape '+' and '=' characters, leaving '/' intact. Playing now with this responder shows abnormal behaviour. I alternatively get different answers, with or without a request. With an empty request, I could get 3 different answers (1 OCSP error and 2 different OCSP responses for 2 different CAs). I would not consider it representative of a good OCSP responder. -- Erwann. --bcaec55400703f0e0a04d0bf8221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bonjour,

2012/12/13 Bruce Stephens= <bruce.stephens@isode.com>
Erwann Abalea <eabalea@gmail.com> writes:

> The "malformedRequest" response is the 5 bytes response it r= eceived (the 5 at the end is the body size of the response).
>
> There's an extra leading '/' in the request. It may come f= rom an extra trailing '/' at the OCSP URL. Check your certificates,= read the authorityInfoAccess extension.
>
> RFC2560 states this:
>
> [...]
> GET {url}/{url-encoding of base-64 encoding of the DER encoding of
> =C2=A0 =C2=A0the OCSPRequest}
> [...]

Is the {url-encoding} part required by anybody? That is, if my

During my tests of OCSP responders, I've come a= ccross responders that couldn't deal with non URL-encoded requests.
'/', '+', and '=3D' are classified as "re= served" characters by RFC2396, and must be escaped (see 2.4, 2.4.2, 2.= 3).
=C2=A0
base64-encoded request is

=C2=A0MEIwQDA+MDwwOjAJBgUrDgMCGgUABBRDjd0Ecx6qe7r2TYbGngjZE/bxaQQUj76OSES03= /qykJF0zQNXx//ovQwCAWU=3D

my reading of appendix A of RFC 2560 suggests I ought to quote the
special characters (in particular / should be %2F, + should be
%2B). Verisign's OCSP responder seems OK with that, but also seems fine=
without url-encoding.

A lot of well-beh= aving OCSP responders accept both forms.
=C2=A0
However, http://= seclab7.ncsl.nist.gov (the responder used for the NIST
PIV test cards) seems to reject url-encoded GET requests as
malformed. It responds to requests that are just base64 encoded (and
responds to HTTP POST as in the RFC).

T= hat's a bug in the responder. RFC2398/2.4.2 is non ambiguous on this po= int, an URI is always in escaped form, and as such MUST be unescaped before= being processed.
I hadn't played with this responder (because I don't have cert= ificates to test it), but you could try to only escape '+' and '= ;=3D' characters, leaving '/' intact.

Playing now with this responder shows abnormal behaviour. I alternatively g= et different answers, with or without a request. With an empty request, I c= ould get 3 different answers (1 OCSP error and 2 different OCSP responses f= or 2 different CAs).
I would not consider it representative of a good OCSP responder.
=

--
Erwann.
--bcaec55400703f0e0a04d0bf8221-- From piyush@ditenity.com Fri Dec 14 09:09:28 2012 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 09DC821F8956 for ; Fri, 14 Dec 2012 09:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LLSrGHDAC2D for ; Fri, 14 Dec 2012 09:09:27 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55A2321F8925 for ; Fri, 14 Dec 2012 09:09:27 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so3364592iaz.31 for ; Fri, 14 Dec 2012 09:09:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language :x-gm-message-state; bh=uJ+Szmd7JI+6jpIMYQexVTovnBRsiEU8FcklcQN3aCM=; b=J4pH6B5khlcJaySgeNwDB5+LBKAFosoMn5Wb1YUkINr9I61D7TubtOWwrT2eoDKs5G xoEpqJnf4ZIMlJVRoAjVXTQvWd8pPtYRdpEHelsON9ztHNBfLYB1RY0m4EoCNXl/Lmju 9v6x75Yo0qVa7lmATZVEFFZlSyhaNWZdOiyy8VDpeeCaopf53E85fwstEE0XYJHMGG9Y vR8SYHQEnJ8tfsczPY0ir5MlE65d/bTA7yeNNLJzZgddGhW/WKTkRPw3vmGag0Cgwl3b pxZAz3cg6/Ey3CjcpgZD1tAK+Fpo6iqQoBdWOLvny1iUf7YzKr/sZMK2x/O/iPJbwJZp 5STg== Received: by 10.50.236.72 with SMTP id us8mr2263992igc.28.1355504966900; Fri, 14 Dec 2012 09:09:26 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id uj6sm4389685igb.4.2012.12.14.09.09.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 09:09:25 -0800 (PST) From: "Piyush Jain" To: Date: Fri, 14 Dec 2012 09:09:21 -0800 Message-ID: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3aHP2+k1UCZ+fYR0SXQqG7rwstYA== Content-Language: en-us X-Gm-Message-State: ALoCoQlPgY5+rCV53kw0cPZOpP+5+Pz+SuNjGDXnf9/gMl/W8ZcK9JIlSw5y/Aq0EHRksmeJBoN6 Subject: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 17:09:28 -0000 Hi All, It seems that the current best practice is to use non-sequential serial numbers when issuing x.509 certificates. I understand that it had some value when weak hashing algorithms were being used to create the signature. But if you are using a strong hashing algorithm, what is the benefit of issuing certificates with random serial values? Thanks a lot in advance for any insights. -Piyush From eabalea@gmail.com Fri Dec 14 09:25:44 2012 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 6DEE921F89E6 for ; Fri, 14 Dec 2012 09:25:44 -0800 (PST) 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 vRnSbsjVeTij for ; Fri, 14 Dec 2012 09:25:43 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9032D21F89C1 for ; Fri, 14 Dec 2012 09:25:43 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2999438lbk.31 for ; Fri, 14 Dec 2012 09:25:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Awqq0jqzJbY9Sv5OTtO6+UeF0Mno5SwwO94ogMlLXM4=; b=s9JRw83HjdC98maBT3VmCQmabr9eSDjK5gn7BEorhqcJdZ8VTK9pmD4lW85WpDgy2T S4HrqmqNMC4K7R52PunheW1x0htcJLO5JkdvNKa9QD+5mP5cNw6ndye11hhsmUXsGgOC i/z/nqdnR4M4g9eP++6LaHMLQfzGHA7ytRuxRPNQSn5okbnsT5ZSillxn1Ex735Gf4Xb KxWQ/dAY6t6D2zyEbAR23s3X+AEP4sylet7C/IypilZe9g+pKotuphY4zFYRSCK31UqW H0QGrZKWgW1/VC3XUZac74rNAo+djouEwDDGDn6vx+veV/8G9fOYCUFz7zPFlj69TQkl a/SQ== MIME-Version: 1.0 Received: by 10.112.43.165 with SMTP id x5mr2495466lbl.76.1355505942533; Fri, 14 Dec 2012 09:25:42 -0800 (PST) Received: by 10.114.17.167 with HTTP; Fri, 14 Dec 2012 09:25:42 -0800 (PST) In-Reply-To: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> Date: Fri, 14 Dec 2012 18:25:42 +0100 Message-ID: From: Erwann Abalea To: Piyush Jain Content-Type: multipart/alternative; boundary=e0cb4efe34ca32182104d0d35218 Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 17:25:44 -0000 --e0cb4efe34ca32182104d0d35218 Content-Type: text/plain; charset=UTF-8 Bonjour, 2012/12/14 Piyush Jain > It seems that the current best practice is to use non-sequential serial > numbers when issuing x.509 certificates. > That's not only a "best practice", but also a requirement for several root programs. > I understand that it had some value when weak hashing algorithms were being > used to create the signature. > It still has some value, because weak hash functions are still used in a signature context. SHA1 isn't over. > But if you are using a strong hashing algorithm, what is the benefit of > issuing certificates with random serial values? > I don't see any benefit in such a situation. -- Erwann. --e0cb4efe34ca32182104d0d35218 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bonjour,

2012/12/14 Piyush Jain <piyus= h@ditenity.com>
It seems that the current best practice is to use non-sequential serial
numbers when issuing x.509 certificates.

That's not only a "best practice", but also a requirement f= or several root programs.
=C2=A0
I understand that it had some value when weak hashing algorithms were being=
used to create the signature.

It still = has some value, because weak hash functions are still used in a signature c= ontext. SHA1 isn't over.
=C2=A0
But if you are using a strong hashing algorithm, what is the benefit of
issuing certificates with random serial values?

I don't see any benefit in such a situation.
=C2=A0<= /div>
--
Erwann.
--e0cb4efe34ca32182104d0d35218-- From DPKemp@missi.ncsc.mil Fri Dec 14 09:34:18 2012 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 BF5DC21F8A4D for ; Fri, 14 Dec 2012 09:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHAJRIQkWMM6 for ; Fri, 14 Dec 2012 09:34:18 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id B480321F8A28 for ; Fri, 14 Dec 2012 09:34:17 -0800 (PST) Received: from clavin.missi.ncsc.mil (odysseus.missi.ncsc.mil [144.51.60.172]) by stingray.missi.ncsc.mil with ESMTP id qBEHYGaO034721 for ; Fri, 14 Dec 2012 12:34:16 -0500 (EST) Received: from clavin.missi.ncsc.mil ([169.254.1.149]) by odysseus.missi.ncsc.mil ([144.51.60.172]) with mapi id 14.01.0421.002; Fri, 14 Dec 2012 12:34:16 -0500 From: "Kemp, David P." To: "pkix@ietf.org" Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: Ac3aHP2+k1UCZ+fYR0SXQqG7rwstYAAAsvTg Date: Fri, 14 Dec 2012 17:34:16 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC850AF8D4D@clavin.missi.ncsc.mil> References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> In-Reply-To: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.54.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 17:34:18 -0000 Sparse namespaces are generic good security hygiene. Data mining, like tel= emarketer robocalling, is enabled by compact namespaces, and the large rand= om-looking URLs employed by, e.g., photo sharing websites are an attempt to= make mining more difficult. If the only way to retrieve a certificate from a directory or web repositor= y is to know its name or serial number, then making valid S/Ns difficult to= guess makes trawling more difficult and easier to detect. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piy= ush Jain Sent: Friday, December 14, 2012 12:09 PM To: pkix@ietf.org Subject: [pkix] Questioning the benefit of random serials over sequential o= nes in x.509 certificates Hi All, It seems that the current best practice is to use non-sequential serial num= bers when issuing x.509 certificates. I understand that it had some value when weak hashing algorithms were being= used to create the signature. =20 But if you are using a strong hashing algorithm, what is the benefit of iss= uing certificates with random serial values? Thanks a lot in advance for any insights. -Piyush _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From piyush@ditenity.com Fri Dec 14 10:04:36 2012 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 E9F6021F8AB4 for ; Fri, 14 Dec 2012 10:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 uINoKCoKTSUU for ; Fri, 14 Dec 2012 10:04:36 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4512221F8A70 for ; Fri, 14 Dec 2012 10:04:36 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6402010ieb.31 for ; Fri, 14 Dec 2012 10:04:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language:x-gm-message-state; bh=N6GClxovBc5kj9Zk3+XIk8wAYZBod73nPLD+RGh1WVE=; b=My5SgqHaxgYrQR9Ygg65hu4jXUXFx16tgMilyRUhb0P5QJ/eeO1QJ7LXMCunbh8mxq qPeo39B65q1GB5MF7vTQYFsQq+adhWv5q0KAfwx8IQJByzViN1D9K/OW32BMuapejtSC UP3k6rS6nI9leu1GVF+663esvVfRAOh+JXoUQYEZT03vrH9Q/BNrQEB4hu1LnIORv9Pj tXYr2QCUfsUJ5i7HDZDlDnBuXbVFQD8Arcsw0f2MN0XaJMJ5fmVSv+0WK+63LXxA1M7Q e1iIrZOzrxImF0BRKF0vBFBO8H9XRew1wQ4ByAlsjMWSL53qWQvfUoC2xqv4/LhrP1Ot mCWg== X-Received: by 10.50.150.175 with SMTP id uj15mr2408106igb.52.1355508275866; Fri, 14 Dec 2012 10:04:35 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id fv6sm7216259igc.17.2012.12.14.10.04.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 10:04:35 -0800 (PST) From: "Piyush Jain" To: "'Erwann Abalea'" References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> In-Reply-To: Date: Fri, 14 Dec 2012 10:04:31 -0800 Message-ID: <043901cdda25$78442770$68cc7650$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_043A_01CDD9E2.6A221FF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHRlKs7YuWAK+X+fx67nstxV6bEfQEe1CSNmAgn+yA= Content-Language: en-us X-Gm-Message-State: ALoCoQnnyrgDVp3g5f1R28bAukNYgHSQ0Bz5F2K3WVITdQGBrNRsm2G2RuvTEDDjjF0L7D+l3RLL Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 18:04:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_043A_01CDD9E2.6A221FF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Erwann, =20 I=E2=80=99m not sure what value does a root CA gets out of this. Since the intermediate certificates (issued by root) are also publicly = visible, it does not matter if the serial is random or not. =20 Isn=E2=80=99t it true that this works only if the attacker does not have = access to the issued certificate? Assuming the PK certificates are not public is sort of = counter-intuitive. =20 -Piyush =20 From: Erwann Abalea [mailto:eabalea@gmail.com]=20 Sent: Friday, December 14, 2012 9:26 AM To: Piyush Jain Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over = sequential ones in x.509 certificates =20 Bonjour, 2012/12/14 Piyush Jain It seems that the current best practice is to use non-sequential serial numbers when issuing x.509 certificates. =20 That's not only a "best practice", but also a requirement for several = root programs. =20 I understand that it had some value when weak hashing algorithms were = being used to create the signature. =20 It still has some value, because weak hash functions are still used in a = signature context. SHA1 isn't over. =20 But if you are using a strong hashing algorithm, what is the benefit of issuing certificates with random serial values? =20 I don't see any benefit in such a situation. =20 --=20 Erwann. ------=_NextPart_000_043A_01CDD9E2.6A221FF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks Erwann,

 

I=E2=80=99m not sure what value does a root CA gets out of = this.

Since the intermediate certificates (issued by root) are also = publicly visible, it does not matter if the serial is random or = not.

 

Isn=E2=80=99t it true that this works only if the attacker does not = have access to the issued certificate?

Assuming the PK certificates are not public is sort of = counter-intuitive.

 

-Piyush

 

From:= = Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, = December 14, 2012 9:26 AM
To: Piyush Jain
Cc: = pkix@ietf.org
Subject: Re: [pkix] Questioning the benefit of = random serials over sequential ones in x.509 = certificates

 

Bonjour,

2012/12/14 Piyush Jain <piyush@ditenity.com>

It seems that the current best practice is to use = non-sequential serial
numbers when issuing x.509 = certificates.

 

That's not only a "best practice", but also = a requirement for several root programs.

 

I = understand that it had some value when weak hashing algorithms were = being
used to create the = signature.

 

It still has some value, because weak hash functions = are still used in a signature context. SHA1 isn't = over.

 

But if = you are using a strong hashing algorithm, what is the benefit = of
issuing certificates with random serial = values?

 

I = don't see any benefit in such a situation.

 

--
Erwann.

------=_NextPart_000_043A_01CDD9E2.6A221FF0-- From eabalea@gmail.com Fri Dec 14 10:17:01 2012 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 D660721F8A90 for ; Fri, 14 Dec 2012 10:17:01 -0800 (PST) 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 vCMw8jfqgYim for ; Fri, 14 Dec 2012 10:17:01 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F083E21F8B1D for ; Fri, 14 Dec 2012 10:16:58 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3043667lbk.31 for ; Fri, 14 Dec 2012 10:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1HppoeRwJSuGFQWtlvAY1cByM8kzyrqaj6ra4MurkUQ=; b=sTmNR3UeYlDHCdIFE4D6/I1ZEHnUAZ6RIy3FuVYxTxC5mw+po6JM3l1aW/pZkKedF3 +kTzbSfF9hOcoFh377axQ45l+6u6A9mTsAwSbZeg/o1Ll8PL4bdCtDFUcx660BEtOTR9 lU9puw/E+jsSY9PcJ4hHS0ZJrcv+T3Fnst5XEi3NhBoQ8zCdyfyKgQRabzP6A75y++jQ ij6s57WXhfA3VqmUjOutGadZXnkgPkm80t7T/w0t1JB14K89s+Kue9dI2zgCEDD/gN7K pcLBnIesULSJNMj8OhnPWCUP9AOm+8xI1/E+eecMglf6VKm76eQPMgV3/WN2dmFJNak/ Tw/g== MIME-Version: 1.0 Received: by 10.112.16.106 with SMTP id f10mr2713780lbd.1.1355509017592; Fri, 14 Dec 2012 10:16:57 -0800 (PST) Received: by 10.114.17.167 with HTTP; Fri, 14 Dec 2012 10:16:57 -0800 (PST) In-Reply-To: <043901cdda25$78442770$68cc7650$@ditenity.com> References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <043901cdda25$78442770$68cc7650$@ditenity.com> Date: Fri, 14 Dec 2012 19:16:57 +0100 Message-ID: From: Erwann Abalea To: Piyush Jain Content-Type: multipart/alternative; boundary=f46d040167817bc8aa04d0d4090a Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 18:17:02 -0000 --f46d040167817bc8aa04d0d4090a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2012/12/14 Piyush Jain > > I=E2=80=99m not sure what value does a root CA gets out of this. > When mentioning root programs, I'm talking about root inclusion into public software (browsers, mainly), not certificates issued by the root CA. The "random serial" requirement is to be applied to CA software that issue end-user certificates. > **** > > Since the intermediate certificates (issued by root) are also publicly > visible, it does not matter if the serial is random or not. > This has nothing to do with secretly issued certificates, but with known prefix collision attacks. > **** > > Isn=E2=80=99t it true that this works only if the attacker does not have = access to > the issued certificate? > > Assuming the PK certificates are not public is sort of counter-intuitive.= * > *** > > ** > I'm not sure I'm following you. A certificate is a public object, for sure. I can't imagine what could be the use of a CA software accepting certificate requests but refusing access to the issued certificate. *From:* Erwann Abalea [mailto:eabalea@gmail.com] > *Sent:* Friday, December 14, 2012 9:26 AM > *To:* Piyush Jain > *Cc:* pkix@ietf.org > *Subject:* Re: [pkix] Questioning the benefit of random serials over > sequential ones in x.509 certificates**** > > ** ** > > Bonjour,**** > > 2012/12/14 Piyush Jain **** > > It seems that the current best practice is to use non-sequential serial > numbers when issuing x.509 certificates.**** > > ** ** > > That's not only a "best practice", but also a requirement for several roo= t > programs.**** > > **** > > I understand that it had some value when weak hashing algorithms were bei= ng > used to create the signature.**** > > ** ** > > It still has some value, because weak hash functions are still used in a > signature context. SHA1 isn't over.**** > > **** > > But if you are using a strong hashing algorithm, what is the benefit of > issuing certificates with random serial values?**** > > ** ** > > I don't see any benefit in such a situation.**** > > **** > > -- > Erwann.**** > --=20 Erwann. --f46d040167817bc8aa04d0d4090a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2012/12/14 Piyush Jain <= ;piyush@ditenity.c= om>

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">I=E2=80=99m not sure what value does a root CA ge= ts out of this.


When mentioning root programs, I'= ;m talking about root inclusion into public software (browsers, mainly), no= t certificates issued by the root CA. The "random serial" require= ment is to be applied to CA software that issue end-user certificates.
=C2=A0

Since the intermediate ce= rtificates (issued by root) are also publicly visible, it does not matter i= f the serial is random or not.


This has nothing to do with se= cretly issued certificates, but with known prefix collision attacks.
<= div>=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">

<= span style=3D"color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size= :11pt">Isn=E2=80=99t it true that this works only if the attacker does not = have access to the issued certificate?

Assuming the PK certifica= tes are not public is sort of counter-intuitive.


I'm not sure I'm following you.
A certificate is= a public object, for sure.
I can't imagine what could be the use of a CA software accepting c= ertificate requests but refusing access to the issued certificate.

<= p class=3D"MsoNormal"> From: Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, December 14, 2012 9:26 AM
To: Piyush JainCc: pkix@ietf.or= g
Subject: Re: [pkix] Questioning the benefit of random seria= ls over sequential ones in x.509 certificates

=C2=A0<= /u>

Bonjour,

2012/12/14 Piyush Jain <piyush@ditenity.com&g= t;

It seems that the current best practice is to use no= n-sequential serial
numbers when issuing x.509 certificates.

=C2=A0

That's not only a "best practice", but also a requirement for= several root programs.

= =C2=A0

I understand that it had some value when weak hashin= g algorithms were being
used to create the signature.

<= /blockquote>

=C2=A0

=

It still has some value, because weak hash functions are still used in a si= gnature context. SHA1 isn't over.

=C2=A0

But if you are using a strong hashing algorithm, wha= t is the benefit of
issuing certificates with random serial values?

=C2=A0<= /p>

I don't see any benefit in such a situation= .

=C2=A0

--
Erwann.

=



--
Erwann= .
--f46d040167817bc8aa04d0d4090a-- From piyush@ditenity.com Fri Dec 14 10:17:22 2012 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 19A5021F8B39 for ; Fri, 14 Dec 2012 10:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 vscDuzpktf70 for ; Fri, 14 Dec 2012 10:17:21 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5206721F8B0C for ; Fri, 14 Dec 2012 10:17:21 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6422201ieb.31 for ; Fri, 14 Dec 2012 10:17:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=0/6gHfb+IpRmXIHSg/WqxY02JWHum5kfFzFFrbwZHA8=; b=K8N0yHFfjgt6BsWhx1L7zmzT5hIV5YIKPEy95ibDKdzSEeupUAe6UAbX68e3WHqcVZ 2qBrxi+P5liElAeqbO6x4AdOaBAjPy9NWrm3uFASCnbyfdFk64s0fwZHAIGWUIL9oFoQ jFA0XkYPlCnOuUJLSoDAuU+UnvGpFq+dCSGNIOw41gN7gpxT4jRNEUdzG1i69QIiBSPF ZGkPiMPubN5Y/0myZZICcZeFDDgUnQAyi5vGFP62kHKiHziEZQ6aP3z37TJcBDwcix8M YNg74Cf4fa0oADPoMidG41VIkx0HU2Sxg0NHTv/dlhlzBVu1RSC4auGt6NCZHKg/WmTy uV0g== Received: by 10.50.195.135 with SMTP id ie7mr2516252igc.8.1355509037453; Fri, 14 Dec 2012 10:17:17 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id aa6sm7240511igc.14.2012.12.14.10.17.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 10:17:16 -0800 (PST) From: "Piyush Jain" To: "'Kemp, David P.'" , References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <5B1D7E570380A64989D4C069F7D14BC850AF8D4D@clavin.missi.ncsc.mil> In-Reply-To: <5B1D7E570380A64989D4C069F7D14BC850AF8D4D@clavin.missi.ncsc.mil> Date: Fri, 14 Dec 2012 10:17:13 -0800 Message-ID: <044601cdda27$3e67eb70$bb37c250$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHRlKs7YuWAK+X+fx67nstxV6bEfQHPydwdmAKjaTA= Content-Language: en-us X-Gm-Message-State: ALoCoQnIdRzWbptYUTiNj3Y+gzjlUXnchiZXAlZ9gyW7q7eYzHxMLAWutNOWRDR3FuoRYdHJyLdw Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 18:17:22 -0000 Thanks David, Please see inline. > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Kemp, David P. > Sent: Friday, December 14, 2012 9:34 AM > To: pkix@ietf.org > Subject: Re: [pkix] Questioning the benefit of random serials over sequential > ones in x.509 certificates > > Sparse namespaces are generic good security hygiene. Data mining, like > telemarketer robocalling, is enabled by compact namespaces, and the large > random-looking URLs employed by, e.g., photo sharing websites are an > attempt to make mining more difficult. > [Piyush] Good analogy. But in this case it is applicable only if certificate access is based on knowledge of the serial number. > If the only way to retrieve a certificate from a directory or web repository is > to know its name or serial number, then making valid S/Ns difficult to guess > makes trawling more difficult and easier to detect. > [Piyush] Are there such mechanisms in place for securing access to the directory? Can't you achieve the same by using a combination of serial and some other cert attribute such as CN? > Dave > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Piyush Jain > Sent: Friday, December 14, 2012 12:09 PM > To: pkix@ietf.org > Subject: [pkix] Questioning the benefit of random serials over sequential > ones in x.509 certificates > > Hi All, > > It seems that the current best practice is to use non-sequential serial > numbers when issuing x.509 certificates. > > I understand that it had some value when weak hashing algorithms were > being used to create the signature. > But if you are using a strong hashing algorithm, what is the benefit of issuing > certificates with random serial values? > > Thanks a lot in advance for any insights. > > -Piyush > > _______________________________________________ > 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 piyush@ditenity.com Fri Dec 14 10:27:35 2012 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 1486A21F8AD7 for ; Fri, 14 Dec 2012 10:27:35 -0800 (PST) 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 a55dqnELwIg0 for ; Fri, 14 Dec 2012 10:27:34 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 409E121F8A79 for ; Fri, 14 Dec 2012 10:27:34 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6438412ieb.31 for ; Fri, 14 Dec 2012 10:27:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=WPQRSBcvATPffxedIQZAEvqr4T96kodbgZj3PCRpxXA=; b=bZ9z7OQTXWFL86Cj+DZ9WSkXD3dwpBQ8lNyo3QjptqHmOo/UWZWcIU7ycyF4+jq8y0 w1FHVwrsW28eboy1ZJcltkbchhItOMNNcW3icocRgqvLRWlVaBzhOpfOyK6MxrX4x/tP w8xCaHq6t0xrxZoJLaQIjv/ndNMhJrqdG2ClXXTeI9XenbpaAlG8pAdm8jbAx9LyB+6k ie3jZCjakH+GhmMP2XMvQnvlcfIZKUJdTiJ8bXsqRNL93jnN6cI1bkcEo7/vpp2JHvhL NWndiYM0xtUjFQ9U9qxhQFGwXSpzvuIjNoWB3j54j+eryDbU2tx6fMmrA0XMVeqM97Nt +17Q== Received: by 10.50.16.210 with SMTP id i18mr2486392igd.53.1355509653627; Fri, 14 Dec 2012 10:27:33 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id v12sm4549345igv.3.2012.12.14.10.27.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 10:27:32 -0800 (PST) From: "Piyush Jain" To: "'Erwann Abalea'" References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <043901cdda25$78442770$68cc7650$@ditenity.com> In-Reply-To: Date: Fri, 14 Dec 2012 10:27:29 -0800 Message-ID: <049301cdda28$ad6c8610$08459230$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0494_01CDD9E5.9F4B68F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHRlKs7YuWAK+X+fx67nstxV6bEfQEe1CSNAnL+QMUButfRpZfmwNLQ Content-Language: en-us X-Gm-Message-State: ALoCoQlfsFy0Yvi/AweAmSDbJaycYd3w3M4zd6Tfk/sANdIGDSiwe/4SkgWKHvOEG7lc8f8qtY2K Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 18:27:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0494_01CDD9E5.9F4B68F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable May be I am missing something very basic. If the certificate is available to the attacker, how does random serial = help avoid a prefix collision attack. =20 The attacker just forges another certificate with same serial and keeps = on changing an extension with random value to force a hash collision. Whether the serial in the certificate is random or not should not have = any impact on the above process. =20 -Piyush =20 =20 From: Erwann Abalea [mailto:eabalea@gmail.com]=20 Sent: Friday, December 14, 2012 10:17 AM To: Piyush Jain Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over = sequential ones in x.509 certificates =20 =20 2012/12/14 Piyush Jain I=E2=80=99m not sure what value does a root CA gets out of this. =20 When mentioning root programs, I'm talking about root inclusion into = public software (browsers, mainly), not certificates issued by the root = CA. The "random serial" requirement is to be applied to CA software that = issue end-user certificates. =20 Since the intermediate certificates (issued by root) are also publicly = visible, it does not matter if the serial is random or not. =20 This has nothing to do with secretly issued certificates, but with known = prefix collision attacks. =20 Isn=E2=80=99t it true that this works only if the attacker does not have = access to the issued certificate? Assuming the PK certificates are not public is sort of = counter-intuitive. =20 I'm not sure I'm following you. A certificate is a public object, for sure. I can't imagine what could be the use of a CA software accepting = certificate requests but refusing access to the issued certificate. =20 From: Erwann Abalea [mailto:eabalea@gmail.com]=20 Sent: Friday, December 14, 2012 9:26 AM To: Piyush Jain Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over = sequential ones in x.509 certificates =20 Bonjour, 2012/12/14 Piyush Jain It seems that the current best practice is to use non-sequential serial numbers when issuing x.509 certificates. =20 That's not only a "best practice", but also a requirement for several = root programs. =20 I understand that it had some value when weak hashing algorithms were = being used to create the signature. =20 It still has some value, because weak hash functions are still used in a = signature context. SHA1 isn't over. =20 But if you are using a strong hashing algorithm, what is the benefit of issuing certificates with random serial values? =20 I don't see any benefit in such a situation. =20 --=20 Erwann. =20 --=20 Erwann. ------=_NextPart_000_0494_01CDD9E5.9F4B68F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

May be I am missing something very basic.

If the certificate is available to the attacker, how does random = serial help avoid a prefix collision attack.

 

The attacker just forges another certificate with same serial and = keeps on changing an extension with random value to force a hash = collision.

Whether the serial in the certificate is random or not should not = have any impact on the above process.

 

-Piyush

 

 

From:= = Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, = December 14, 2012 10:17 AM
To: Piyush Jain
Cc: = pkix@ietf.org
Subject: Re: [pkix] Questioning the benefit of = random serials over sequential ones in x.509 = certificates

 

 

2012/12/14 Piyush Jain <piyush@ditenity.com>

I=E2=80=99m not sure what value does a root CA gets out of = this.

 

When mentioning root programs, I'm talking about root = inclusion into public software (browsers, mainly), not certificates = issued by the root CA. The "random serial" requirement is to = be applied to CA software that issue end-user = certificates.

 

Since the intermediate certificates (issued by root) are also = publicly visible, it does not matter if the serial is random or = not.

 

This has nothing to do with secretly issued = certificates, but with known prefix collision = attacks.

 

Isn=E2=80=99t it true that this works only if the attacker does not = have access to the issued certificate?

Assuming the PK certificates are not public is sort of = counter-intuitive.

 

I'm not sure I'm following = you.

A certificate is a = public object, for sure.

I = can't imagine what could be the use of a CA software accepting = certificate requests but refusing access to the issued = certificate.

 

From:= = Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, = December 14, 2012 9:26 AM
To: Piyush Jain
Cc: pkix@ietf.org
Subject: Re: [pkix] = Questioning the benefit of random serials over sequential ones in x.509 = certificates

 <= /o:p>

Bonjour,

2012/12/14 = Piyush Jain <piyush@ditenity.com>

It seems = that the current best practice is to use non-sequential = serial
numbers when issuing x.509 certificates.

 <= /o:p>

That's not = only a "best practice", but also a requirement for several = root programs.

 <= /o:p>

I = understand that it had some value when weak hashing algorithms were = being
used to create the = signature.

 <= /o:p>

It still = has some value, because weak hash functions are still used in a = signature context. SHA1 isn't over.

 <= /o:p>

But if you = are using a strong hashing algorithm, what is the benefit of
issuing = certificates with random serial = values?

 <= /o:p>

I don't see = any benefit in such a situation.

 <= /o:p>

-- =
Erwann.



 

-- =
Erwann.

------=_NextPart_000_0494_01CDD9E5.9F4B68F0-- From schaen@mitre.org Fri Dec 14 10:51:36 2012 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 D32CC21F89EA for ; Fri, 14 Dec 2012 10:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 V1chaNhmoJz6 for ; Fri, 14 Dec 2012 10:51:36 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id AD0E521F89B6 for ; Fri, 14 Dec 2012 10:51:35 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 06828435022D; Fri, 14 Dec 2012 13:51:35 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D12CF43300E8; Fri, 14 Dec 2012 13:51:34 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Fri, 14 Dec 2012 13:51:34 -0500 From: "Schaen, Samuel I." To: Piyush Jain , 'Erwann Abalea' Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: AQHN2iiyrKg3YUWVmkOqP/gHiWwKCZgYowXA Date: Fri, 14 Dec 2012 18:51:33 +0000 Message-ID: <05B0827555CC904EAAF411605F38BF8306676FC3@IMCMBX01.MITRE.ORG> References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <043901cdda25$78442770$68cc7650$@ditenity.com> <049301cdda28$ad6c8610$08459230$@ditenity.com> In-Reply-To: <049301cdda28$ad6c8610$08459230$@ditenity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.55] Content-Type: multipart/alternative; boundary="_000_05B0827555CC904EAAF411605F38BF8306676FC3IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 18:51:36 -0000 --_000_05B0827555CC904EAAF411605F38BF8306676FC3IMCMBX01MITREOR_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbSBhIHByYWN0aWNhbCBwZXJzcGVjdGl2ZSwgdXNlIG9mIHJhbmRvbSBzZXJpYWwgbnVtYmVy cyBwcmVjbHVkZXMgdGhlIHVzZSBvZiBPQ1NQIHByZS1zaWduZWQgcmVzcG9uc2VzIHRoYXQgcmVs eSBvbiBhIENSTCAocmF0aGVyIHRoYW4gZGlyZWN0IGNvbm5lY3Rpb24gdG8gYSBDQSkgYW5kIG11 c3QgcHJvZHVjZSByZXNwb25zZXMgZm9yIGFsbCBwb3NzaWJsZSBjZXJ0aWZpY2F0ZXMgd2l0aGlu IHRoZSB1bmV4cGlyZWQgaXNzdWFuY2UgcmFuZ2UuDQoNCkZyb206IHBraXgtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBpeXVzaCBK YWluDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDE0LCAyMDEyIDE6MjcgUE0NClRvOiAnRXJ3YW5u IEFiYWxlYScNCkNjOiBwa2l4QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3BraXhdIFF1ZXN0aW9u aW5nIHRoZSBiZW5lZml0IG9mIHJhbmRvbSBzZXJpYWxzIG92ZXIgc2VxdWVudGlhbCBvbmVzIGlu IHguNTA5IGNlcnRpZmljYXRlcw0KDQpNYXkgYmUgSSBhbSBtaXNzaW5nIHNvbWV0aGluZyB2ZXJ5 IGJhc2ljLg0KSWYgdGhlIGNlcnRpZmljYXRlIGlzIGF2YWlsYWJsZSB0byB0aGUgYXR0YWNrZXIs IGhvdyBkb2VzIHJhbmRvbSBzZXJpYWwgaGVscCBhdm9pZCBhIHByZWZpeCBjb2xsaXNpb24gYXR0 YWNrLg0KDQpUaGUgYXR0YWNrZXIganVzdCBmb3JnZXMgYW5vdGhlciBjZXJ0aWZpY2F0ZSB3aXRo IHNhbWUgc2VyaWFsIGFuZCBrZWVwcyBvbiBjaGFuZ2luZyBhbiBleHRlbnNpb24gd2l0aCByYW5k b20gdmFsdWUgdG8gZm9yY2UgYSBoYXNoIGNvbGxpc2lvbi4NCldoZXRoZXIgdGhlIHNlcmlhbCBp biB0aGUgY2VydGlmaWNhdGUgaXMgcmFuZG9tIG9yIG5vdCBzaG91bGQgbm90IGhhdmUgYW55IGlt cGFjdCBvbiB0aGUgYWJvdmUgcHJvY2Vzcy4NCg0KLVBpeXVzaA0KDQoNCkZyb206IEVyd2FubiBB YmFsZWEgW21haWx0bzplYWJhbGVhQGdtYWlsLmNvbV0NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIg MTQsIDIwMTIgMTA6MTcgQU0NClRvOiBQaXl1c2ggSmFpbg0KQ2M6IHBraXhAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbcGtpeF0gUXVlc3Rpb25pbmcgdGhlIGJlbmVmaXQgb2YgcmFuZG9tIHNlcmlh bHMgb3ZlciBzZXF1ZW50aWFsIG9uZXMgaW4geC41MDkgY2VydGlmaWNhdGVzDQoNCg0KMjAxMi8x Mi8xNCBQaXl1c2ggSmFpbiA8cGl5dXNoQGRpdGVuaXR5LmNvbTxtYWlsdG86cGl5dXNoQGRpdGVu aXR5LmNvbT4+DQpJ4oCZbSBub3Qgc3VyZSB3aGF0IHZhbHVlIGRvZXMgYSByb290IENBIGdldHMg b3V0IG9mIHRoaXMuDQoNCldoZW4gbWVudGlvbmluZyByb290IHByb2dyYW1zLCBJJ20gdGFsa2lu ZyBhYm91dCByb290IGluY2x1c2lvbiBpbnRvIHB1YmxpYyBzb2Z0d2FyZSAoYnJvd3NlcnMsIG1h aW5seSksIG5vdCBjZXJ0aWZpY2F0ZXMgaXNzdWVkIGJ5IHRoZSByb290IENBLiBUaGUgInJhbmRv bSBzZXJpYWwiIHJlcXVpcmVtZW50IGlzIHRvIGJlIGFwcGxpZWQgdG8gQ0Egc29mdHdhcmUgdGhh dCBpc3N1ZSBlbmQtdXNlciBjZXJ0aWZpY2F0ZXMuDQoNClNpbmNlIHRoZSBpbnRlcm1lZGlhdGUg Y2VydGlmaWNhdGVzIChpc3N1ZWQgYnkgcm9vdCkgYXJlIGFsc28gcHVibGljbHkgdmlzaWJsZSwg aXQgZG9lcyBub3QgbWF0dGVyIGlmIHRoZSBzZXJpYWwgaXMgcmFuZG9tIG9yIG5vdC4NCg0KVGhp cyBoYXMgbm90aGluZyB0byBkbyB3aXRoIHNlY3JldGx5IGlzc3VlZCBjZXJ0aWZpY2F0ZXMsIGJ1 dCB3aXRoIGtub3duIHByZWZpeCBjb2xsaXNpb24gYXR0YWNrcy4NCg0KSXNu4oCZdCBpdCB0cnVl IHRoYXQgdGhpcyB3b3JrcyBvbmx5IGlmIHRoZSBhdHRhY2tlciBkb2VzIG5vdCBoYXZlIGFjY2Vz cyB0byB0aGUgaXNzdWVkIGNlcnRpZmljYXRlPw0KQXNzdW1pbmcgdGhlIFBLIGNlcnRpZmljYXRl cyBhcmUgbm90IHB1YmxpYyBpcyBzb3J0IG9mIGNvdW50ZXItaW50dWl0aXZlLg0KDQpJJ20gbm90 IHN1cmUgSSdtIGZvbGxvd2luZyB5b3UuDQpBIGNlcnRpZmljYXRlIGlzIGEgcHVibGljIG9iamVj dCwgZm9yIHN1cmUuDQpJIGNhbid0IGltYWdpbmUgd2hhdCBjb3VsZCBiZSB0aGUgdXNlIG9mIGEg Q0Egc29mdHdhcmUgYWNjZXB0aW5nIGNlcnRpZmljYXRlIHJlcXVlc3RzIGJ1dCByZWZ1c2luZyBh Y2Nlc3MgdG8gdGhlIGlzc3VlZCBjZXJ0aWZpY2F0ZS4NCg0KRnJvbTogRXJ3YW5uIEFiYWxlYSBb bWFpbHRvOmVhYmFsZWFAZ21haWwuY29tPG1haWx0bzplYWJhbGVhQGdtYWlsLmNvbT5dDQpTZW50 OiBGcmlkYXksIERlY2VtYmVyIDE0LCAyMDEyIDk6MjYgQU0NClRvOiBQaXl1c2ggSmFpbg0KQ2M6 IHBraXhAaWV0Zi5vcmc8bWFpbHRvOnBraXhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3BraXhd IFF1ZXN0aW9uaW5nIHRoZSBiZW5lZml0IG9mIHJhbmRvbSBzZXJpYWxzIG92ZXIgc2VxdWVudGlh bCBvbmVzIGluIHguNTA5IGNlcnRpZmljYXRlcw0KDQpCb25qb3VyLA0KMjAxMi8xMi8xNCBQaXl1 c2ggSmFpbiA8cGl5dXNoQGRpdGVuaXR5LmNvbTxtYWlsdG86cGl5dXNoQGRpdGVuaXR5LmNvbT4+ DQpJdCBzZWVtcyB0aGF0IHRoZSBjdXJyZW50IGJlc3QgcHJhY3RpY2UgaXMgdG8gdXNlIG5vbi1z ZXF1ZW50aWFsIHNlcmlhbA0KbnVtYmVycyB3aGVuIGlzc3VpbmcgeC41MDkgY2VydGlmaWNhdGVz Lg0KDQpUaGF0J3Mgbm90IG9ubHkgYSAiYmVzdCBwcmFjdGljZSIsIGJ1dCBhbHNvIGEgcmVxdWly ZW1lbnQgZm9yIHNldmVyYWwgcm9vdCBwcm9ncmFtcy4NCg0KSSB1bmRlcnN0YW5kIHRoYXQgaXQg aGFkIHNvbWUgdmFsdWUgd2hlbiB3ZWFrIGhhc2hpbmcgYWxnb3JpdGhtcyB3ZXJlIGJlaW5nDQp1 c2VkIHRvIGNyZWF0ZSB0aGUgc2lnbmF0dXJlLg0KDQpJdCBzdGlsbCBoYXMgc29tZSB2YWx1ZSwg YmVjYXVzZSB3ZWFrIGhhc2ggZnVuY3Rpb25zIGFyZSBzdGlsbCB1c2VkIGluIGEgc2lnbmF0dXJl IGNvbnRleHQuIFNIQTEgaXNuJ3Qgb3Zlci4NCg0KQnV0IGlmIHlvdSBhcmUgdXNpbmcgYSBzdHJv bmcgaGFzaGluZyBhbGdvcml0aG0sIHdoYXQgaXMgdGhlIGJlbmVmaXQgb2YNCmlzc3VpbmcgY2Vy dGlmaWNhdGVzIHdpdGggcmFuZG9tIHNlcmlhbCB2YWx1ZXM/DQoNCkkgZG9uJ3Qgc2VlIGFueSBi ZW5lZml0IGluIHN1Y2ggYSBzaXR1YXRpb24uDQoNCi0tDQpFcndhbm4uDQoNCg0KDQotLQ0KRXJ3 YW5uLg0K --_000_05B0827555CC904EAAF411605F38BF8306676FC3IMCMBX01MITREOR_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RnJvbSBhIHByYWN0aWNhbCBwZXJzcGVj dGl2ZSwgdXNlIG9mIHJhbmRvbSBzZXJpYWwgbnVtYmVycyBwcmVjbHVkZXMgdGhlIHVzZSBvZiBP Q1NQIHByZS1zaWduZWQgcmVzcG9uc2VzIHRoYXQgcmVseSBvbiBhIENSTCAocmF0aGVyIHRoYW4g ZGlyZWN0IGNvbm5lY3Rpb24NCiB0byBhIENBKSBhbmQgbXVzdCBwcm9kdWNlIHJlc3BvbnNlcyBm b3IgYWxsIHBvc3NpYmxlIGNlcnRpZmljYXRlcyB3aXRoaW4gdGhlIHVuZXhwaXJlZCBpc3N1YW5j ZSByYW5nZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcGtp eC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5QaXl1c2ggSmFpbjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIERlY2Vt YmVyIDE0LCAyMDEyIDE6MjcgUE08YnI+DQo8Yj5Ubzo8L2I+ICdFcndhbm4gQWJhbGVhJzxicj4N CjxiPkNjOjwvYj4gcGtpeEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3BraXhd IFF1ZXN0aW9uaW5nIHRoZSBiZW5lZml0IG9mIHJhbmRvbSBzZXJpYWxzIG92ZXIgc2VxdWVudGlh bCBvbmVzIGluIHguNTA5IGNlcnRpZmljYXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1h eSBiZSBJIGFtIG1pc3Npbmcgc29tZXRoaW5nIHZlcnkgYmFzaWMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB0aGUgY2VydGlmaWNhdGUg aXMgYXZhaWxhYmxlIHRvIHRoZSBhdHRhY2tlciwgaG93IGRvZXMgcmFuZG9tIHNlcmlhbCBoZWxw IGF2b2lkIGEgcHJlZml4IGNvbGxpc2lvbiBhdHRhY2suPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBhdHRhY2tlciBqdXN0IGZv cmdlcyBhbm90aGVyIGNlcnRpZmljYXRlIHdpdGggc2FtZSBzZXJpYWwgYW5kIGtlZXBzIG9uIGNo YW5naW5nIGFuIGV4dGVuc2lvbiB3aXRoIHJhbmRvbSB2YWx1ZSB0byBmb3JjZSBhIGhhc2gNCiBj b2xsaXNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5XaGV0aGVyIHRoZSBzZXJpYWwgaW4gdGhlIGNlcnRpZmljYXRlIGlzIHJhbmRvbSBv ciBub3Qgc2hvdWxkIG5vdCBoYXZlIGFueSBpbXBhY3Qgb24gdGhlIGFib3ZlIHByb2Nlc3MuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pi1QaXl1c2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEVyd2Fu biBBYmFsZWEgW21haWx0bzplYWJhbGVhQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBG cmlkYXksIERlY2VtYmVyIDE0LCAyMDEyIDEwOjE3IEFNPGJyPg0KPGI+VG86PC9iPiBQaXl1c2gg SmFpbjxicj4NCjxiPkNjOjwvYj4gcGtpeEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3BraXhdIFF1ZXN0aW9uaW5nIHRoZSBiZW5lZml0IG9mIHJhbmRvbSBzZXJpYWxzIG92ZXIg c2VxdWVudGlhbCBvbmVzIGluIHguNTA5IGNlcnRpZmljYXRlczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjIwMTIvMTIvMTQgUGl5dXNo IEphaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwaXl1c2hAZGl0ZW5pdHkuY29tIiB0YXJnZXQ9Il9i bGFuayI+cGl5dXNoQGRpdGVuaXR5LmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJltIG5vdCBzdXJlIHdoYXQgdmFsdWUgZG9l cyBhIHJvb3QgQ0EgZ2V0cyBvdXQgb2YgdGhpcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+V2hlbiBtZW50aW9uaW5nIHJvb3QgcHJvZ3JhbXMs IEknbSB0YWxraW5nIGFib3V0IHJvb3QgaW5jbHVzaW9uIGludG8gcHVibGljIHNvZnR3YXJlIChi cm93c2VycywgbWFpbmx5KSwgbm90IGNlcnRpZmljYXRlcyBpc3N1ZWQgYnkgdGhlIHJvb3QgQ0Eu IFRoZSAmcXVvdDtyYW5kb20gc2VyaWFsJnF1b3Q7IHJlcXVpcmVtZW50IGlzIHRvIGJlIGFwcGxp ZWQgdG8gQ0Egc29mdHdhcmUgdGhhdA0KIGlzc3VlIGVuZC11c2VyIGNlcnRpZmljYXRlcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaW5jZSB0aGUgaW50ZXJtZWRpYXRlIGNlcnRpZmlj YXRlcyAoaXNzdWVkIGJ5IHJvb3QpIGFyZSBhbHNvIHB1YmxpY2x5IHZpc2libGUsIGl0IGRvZXMg bm90IG1hdHRlciBpZiB0aGUgc2VyaWFsIGlzIHJhbmRvbSBvciBub3QuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+VGhpcyBoYXMgbm90aGluZyB0byBkbyB3aXRoIHNlY3JldGx5IGlzc3VlZCBjZXJ0aWZp Y2F0ZXMsIGJ1dCB3aXRoIGtub3duIHByZWZpeCBjb2xsaXNpb24gYXR0YWNrcy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPklzbuKAmXQgaXQgdHJ1ZSB0aGF0IHRoaXMgd29ya3Mgb25seSBpZiB0aGUg YXR0YWNrZXIgZG9lcyBub3QgaGF2ZSBhY2Nlc3MgdG8gdGhlIGlzc3VlZCBjZXJ0aWZpY2F0ZT88 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXNzdW1p bmcgdGhlIFBLIGNlcnRpZmljYXRlcyBhcmUgbm90IHB1YmxpYyBpcyBzb3J0IG9mIGNvdW50ZXIt aW50dWl0aXZlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JJ20gbm90IHN1cmUgSSdtIGZvbGxvd2luZyB5b3UuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+QSBjZXJ0aWZpY2F0ZSBpcyBhIHB1YmxpYyBvYmplY3QsIGZvciBz dXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgY2FuJ3QgaW1hZ2luZSB3aGF0IGNvdWxkIGJlIHRo ZSB1c2Ugb2YgYSBDQSBzb2Z0d2FyZSBhY2NlcHRpbmcgY2VydGlmaWNhdGUgcmVxdWVzdHMgYnV0 IHJlZnVzaW5nIGFjY2VzcyB0byB0aGUgaXNzdWVkIGNlcnRpZmljYXRlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBFcndhbm4gQWJhbGVh IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmVhYmFsZWFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+ZWFiYWxlYUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRGVj ZW1iZXIgMTQsIDIwMTIgOToyNiBBTTxicj4NCjxiPlRvOjwvYj4gUGl5dXNoIEphaW48YnI+DQo8 Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpwa2l4QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cGtpeEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtwa2l4XSBRdWVzdGlv bmluZyB0aGUgYmVuZWZpdCBvZiByYW5kb20gc2VyaWFscyBvdmVyIHNlcXVlbnRpYWwgb25lcyBp biB4LjUwOSBjZXJ0aWZpY2F0ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+ DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWlu Ij4NCkJvbmpvdXIsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0Oi41aW4iPg0KMjAxMi8xMi8xNCBQaXl1c2ggSmFpbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOnBpeXVzaEBkaXRlbml0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5waXl1c2hAZGl0ZW5p dHkuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluIj4NCkl0IHNlZW1zIHRoYXQgdGhlIGN1cnJlbnQgYmVzdCBwcmFjdGljZSBp cyB0byB1c2Ugbm9uLXNlcXVlbnRpYWwgc2VyaWFsPGJyPg0KbnVtYmVycyB3aGVuIGlzc3Vpbmcg eC41MDkgY2VydGlmaWNhdGVzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KVGhhdCdz IG5vdCBvbmx5IGEgJnF1b3Q7YmVzdCBwcmFjdGljZSZxdW90OywgYnV0IGFsc28gYSByZXF1aXJl bWVudCBmb3Igc2V2ZXJhbCByb290IHByb2dyYW1zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K SSB1bmRlcnN0YW5kIHRoYXQgaXQgaGFkIHNvbWUgdmFsdWUgd2hlbiB3ZWFrIGhhc2hpbmcgYWxn b3JpdGhtcyB3ZXJlIGJlaW5nPGJyPg0KdXNlZCB0byBjcmVhdGUgdGhlIHNpZ25hdHVyZS48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkl0IHN0aWxsIGhhcyBz b21lIHZhbHVlLCBiZWNhdXNlIHdlYWsgaGFzaCBmdW5jdGlvbnMgYXJlIHN0aWxsIHVzZWQgaW4g YSBzaWduYXR1cmUgY29udGV4dC4gU0hBMSBpc24ndCBvdmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41 aW4iPg0KQnV0IGlmIHlvdSBhcmUgdXNpbmcgYSBzdHJvbmcgaGFzaGluZyBhbGdvcml0aG0sIHdo YXQgaXMgdGhlIGJlbmVmaXQgb2Y8YnI+DQppc3N1aW5nIGNlcnRpZmljYXRlcyB3aXRoIHJhbmRv bSBzZXJpYWwgdmFsdWVzPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41 aW4iPg0KSSBkb24ndCBzZWUgYW55IGJlbmVmaXQgaW4gc3VjaCBhIHNpdHVhdGlvbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCi0tIDxicj4NCkVyd2Fubi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJy Pg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+LS0g PGJyPg0KRXJ3YW5uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_05B0827555CC904EAAF411605F38BF8306676FC3IMCMBX01MITREOR_-- From eabalea@gmail.com Fri Dec 14 10:59:19 2012 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 E698F21F8AA9 for ; Fri, 14 Dec 2012 10:59:19 -0800 (PST) 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 W6BHkQNU4T0V for ; Fri, 14 Dec 2012 10:59:19 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 69F2921F8A77 for ; Fri, 14 Dec 2012 10:59:18 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3076850lbk.31 for ; Fri, 14 Dec 2012 10:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+0s4Wh5jLLErDgUx3SjxgdbQOFZ+gKiGOrt9bFUQ800=; b=gVd/ggU4EMt9gntzMMg+k7aaS0nBCkSQuH53Ox1q28pdLdKFbnDisKGsoAT7Khq4Ym jTpu15w7GPMKb+KXzRF6SUt2OUZrj1iNuZ7Sc2ERhmnUodHqOQaBrpeyJvSiMRpkXInb am/ZoiAD8u3buu6VxF2iCx/tKXw3W9Y7ovtA+MhE7Q/V9Wo+Qehfldmbuo+DZa+QDaQM l31fkTIMKA8huoLrPbSncTjumBYqx3XOE72yjwpEEyTOvgwFGucWUrMhejgAahSCVoC7 cVLjETVcfSGp0AJ/DsX51TlQmUv0kNNFs5a53QoR0pUcJMJdoz4JpcMfD6JcGJWeHKok g2Lw== MIME-Version: 1.0 Received: by 10.152.105.203 with SMTP id go11mr3425623lab.53.1355511557192; Fri, 14 Dec 2012 10:59:17 -0800 (PST) Received: by 10.114.17.167 with HTTP; Fri, 14 Dec 2012 10:59:17 -0800 (PST) In-Reply-To: <049301cdda28$ad6c8610$08459230$@ditenity.com> References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <043901cdda25$78442770$68cc7650$@ditenity.com> <049301cdda28$ad6c8610$08459230$@ditenity.com> Date: Fri, 14 Dec 2012 19:59:17 +0100 Message-ID: From: Erwann Abalea To: Piyush Jain Content-Type: multipart/alternative; boundary=f46d04083e33dafc1e04d0d4a08d Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 18:59:20 -0000 --f46d04083e33dafc1e04d0d4a08d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2012/12/14 Piyush Jain > May be I am missing something very basic.**** > > If the certificate is available to the attacker, how does random serial > help avoid a prefix collision attack.**** > > ** ** > > The attacker just forges another certificate with same serial and keeps o= n > changing an extension with random value to force a hash collision. > The attacker doesn't choose the serial number. If it's not random, it can only guess it. The attacker also can't choose the extensions it will have in its certificate (or he might as well choose to simply get a basicConstraints:CA=3Dtrue certificate). Maybe you're mistaking this attack with a complete CA compromise? > **** > > Whether the serial in the certificate is random or not should not have an= y > impact on the above process. > You should read http://www.win.tue.nl/hashclash/rogue-ca/ It's well written. > *From:* Erwann Abalea [mailto:eabalea@gmail.com] > *Sent:* Friday, December 14, 2012 10:17 AM > > *To:* Piyush Jain > *Cc:* pkix@ietf.org > *Subject:* Re: [pkix] Questioning the benefit of random serials over > sequential ones in x.509 certificates**** > > ** ** > > ** ** > > 2012/12/14 Piyush Jain **** > > I=E2=80=99m not sure what value does a root CA gets out of this.**** > > ** ** > > When mentioning root programs, I'm talking about root inclusion into > public software (browsers, mainly), not certificates issued by the root C= A. > The "random serial" requirement is to be applied to CA software that issu= e > end-user certificates.**** > > **** > > Since the intermediate certificates (issued by root) are also publicly > visible, it does not matter if the serial is random or not.**** > > ** ** > > This has nothing to do with secretly issued certificates, but with known > prefix collision attacks.**** > > **** > > Isn=E2=80=99t it true that this works only if the attacker does not have = access to > the issued certificate?**** > > Assuming the PK certificates are not public is sort of counter-intuitive.= * > *** > > ** ** > > I'm not sure I'm following you.**** > > A certificate is a public object, for sure.**** > > I can't imagine what could be the use of a CA software accepting > certificate requests but refusing access to the issued certificate.**** > > ** ** > > *From:* Erwann Abalea [mailto:eabalea@gmail.com] > *Sent:* Friday, December 14, 2012 9:26 AM > *To:* Piyush Jain > *Cc:* pkix@ietf.org > *Subject:* Re: [pkix] Questioning the benefit of random serials over > sequential ones in x.509 certificates**** > > **** > > Bonjour,**** > > 2012/12/14 Piyush Jain **** > > It seems that the current best practice is to use non-sequential serial > numbers when issuing x.509 certificates.**** > > **** > > That's not only a "best practice", but also a requirement for several roo= t > programs.**** > > **** > > I understand that it had some value when weak hashing algorithms were bei= ng > used to create the signature.**** > > **** > > It still has some value, because weak hash functions are still used in a > signature context. SHA1 isn't over.**** > > **** > > But if you are using a strong hashing algorithm, what is the benefit of > issuing certificates with random serial values?**** > > **** > > I don't see any benefit in such a situation.**** > > **** > > -- > Erwann.**** > > > > **** > > ** ** > > -- > Erwann.**** > --=20 Erwann. --f46d04083e33dafc1e04d0d4a08d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2012/12/14 Piyush Jain <= ;piyush@ditenity.c= om>

May be I am missing something very basic.=

If the certificate is ava= ilable to the attacker, how does random serial help avoid a prefix collisio= n attack.

=C2=A0

The attacker just f= orges another certificate with same serial and keeps on changing an extensi= on with random value to force a hash collision.


The attacker doesn't choos= e the serial number. If it's not random, it can only guess it.
The attacker also can't choose the extensions it will have in its cer= tificate (or he might as well choose to simply get a basicConstraints:CA=3D= true certificate).
Maybe you're mistaking this attack with a complete CA compromise?<= /div>
=C2=A0

Whether the serial i= n the certificate is random or not should not have any impact on the above = process.


It's well written.
=C2=A0= =C2=A0

From: Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, December 14, 2012 10:17 AM


To: Piyush Jain
Cc: pkix@ietf.org
Subject: Re: [pkix] Qu= estioning the benefit of random serials over sequential ones in x.509 certi= ficates

<= /u>=C2=A0

=C2=A0

2012/12/14 Piyush Jain <piyush@ditenity.com>

I=E2=80=99m not sure= what value does a root CA gets out of this.

=

=C2=A0

When mentioning r= oot programs, I'm talking about root inclusion into public software (br= owsers, mainly), not certificates issued by the root CA. The "random s= erial" requirement is to be applied to CA software that issue end-user= certificates.

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">Since the intermediate certificates (issued by ro= ot) are also publicly visible, it does not matter if the serial is random o= r not.

=C2=A0

This has nothing to do with secretly is= sued certificates, but with known prefix collision attacks.

=C2=A0

Isn=E2=80=99t it true that this works only if the attacker = does not have access to the issued certificate?

Assuming the PK certifica= tes are not public is sort of counter-intuitive.

=C2=A0

I'm not sure I'm following you.

A certificate is a public object, f= or sure.

I can't imagine what could be the use= of a CA software accepting certificate requests but refusing access to the= issued certificate.

= =C2=A0

From: Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, December 14, 2012 9:26 AM
To: Piyush JainCc: pkix@ietf.or= g
Subject: Re: [pkix] Questioning the benefit of random seria= ls over sequential ones in x.509 certificates

=C2=A0

Bonjour,

<= div>

2012/12/14 Piyush Jain <piyush@ditenity.com>

It seems that the current best practice is to use no= n-sequential serial
numbers when issuing x.509 certificates.

=C2=A0

That's not only a "best practice", but also a requirement for= several root programs.

= =C2=A0

I understand that it had some value when weak hashin= g algorithms were being
used to create the signature.

<= /blockquote>

=C2=A0

=

It still has some value, because weak hash functions are still used in a si= gnature context. SHA1 isn't over.

=C2=A0

But if you are using a strong hashing algorithm, wha= t is the benefit of
issuing certificates with random serial values?

=C2=A0<= /p>

I don't see any benefit in such a situation= .

=C2=A0

--
Erwann.

=



=C2=A0

--
Erwann.

=


--
Erwann.
--f46d04083e33dafc1e04d0d4a08d-- From eabalea@gmail.com Fri Dec 14 11:01:46 2012 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 82B2B21F8B0E for ; Fri, 14 Dec 2012 11:01:46 -0800 (PST) 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 pZD+uhRO8Zhj for ; Fri, 14 Dec 2012 11:01:45 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3005F21F8AFE for ; Fri, 14 Dec 2012 11:01:45 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3064238lah.31 for ; Fri, 14 Dec 2012 11:01:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JzXKhuXBs14YF7o18VoWS98vS9qJ61skECymOTX++mg=; b=trNF+cT2CUCMXJgwxkk3h+zeVrW5BPyRqYIW4pBIQbjYVxnYdIhsbrRvwrhNzBaDIW hBFRJoHuC1igPkNHQ482FUewtT455xIOmJNWothBz74F0EEbzJhHrwxA6+iYbz7aZTqs pFPHBOwZRuNrv21U4eeiF+AFSpSWbbenFyBnQzAqWTtvzUrDIFvYkqIaOqyaTqtDuA4p MckJivpNw0BEvy+3C0FcRT7S5vCzqrPG22zpgZOijUNZxmGW8InEB2DTDP+/KTMvBhI3 Hs00yVc9YOHgv6VkllrLJO/XIA4BXhT2sHjaxuhNCcV3RN2n7I23VQzXI1zNjYFNupm1 D0xg== MIME-Version: 1.0 Received: by 10.112.54.6 with SMTP id f6mr2746732lbp.71.1355511704011; Fri, 14 Dec 2012 11:01:44 -0800 (PST) Received: by 10.114.17.167 with HTTP; Fri, 14 Dec 2012 11:01:43 -0800 (PST) In-Reply-To: <05B0827555CC904EAAF411605F38BF8306676FC3@IMCMBX01.MITRE.ORG> References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <043901cdda25$78442770$68cc7650$@ditenity.com> <049301cdda28$ad6c8610$08459230$@ditenity.com> <05B0827555CC904EAAF411605F38BF8306676FC3@IMCMBX01.MITRE.ORG> Date: Fri, 14 Dec 2012 20:01:43 +0100 Message-ID: From: Erwann Abalea To: "Schaen, Samuel I." Content-Type: multipart/alternative; boundary=bcaec55400709b42ec04d0d4a992 Cc: "pkix@ietf.org" Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 19:01:46 -0000 --bcaec55400709b42ec04d0d4a992 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's right. Some root programs accept the randomness to be added in the subjectName, before any user-supplied data, in a dedicated AVA. That's acceptable. 2012/12/14 Schaen, Samuel I. > From a practical perspective, use of random serial numbers precludes the > use of OCSP pre-signed responses that rely on a CRL (rather than direct > connection to a CA) and must produce responses for all possible > certificates within the unexpired issuance range.**** > > ** ** > > *From:* pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] *On Behalf > Of *Piyush Jain > *Sent:* Friday, December 14, 2012 1:27 PM > *To:* 'Erwann Abalea' > > *Cc:* pkix@ietf.org > *Subject:* Re: [pkix] Questioning the benefit of random serials over > sequential ones in x.509 certificates**** > > ** ** > > May be I am missing something very basic.**** > > If the certificate is available to the attacker, how does random serial > help avoid a prefix collision attack.**** > > ** ** > > The attacker just forges another certificate with same serial and keeps o= n > changing an extension with random value to force a hash collision.**** > > Whether the serial in the certificate is random or not should not have an= y > impact on the above process.**** > > ** ** > > -Piyush**** > > ** ** > > ** ** > > *From:* Erwann Abalea [mailto:eabalea@gmail.com] > *Sent:* Friday, December 14, 2012 10:17 AM > *To:* Piyush Jain > *Cc:* pkix@ietf.org > *Subject:* Re: [pkix] Questioning the benefit of random serials over > sequential ones in x.509 certificates**** > > ** ** > > ** ** > > 2012/12/14 Piyush Jain **** > > I=E2=80=99m not sure what value does a root CA gets out of this.**** > > ** ** > > When mentioning root programs, I'm talking about root inclusion into > public software (browsers, mainly), not certificates issued by the root C= A. > The "random serial" requirement is to be applied to CA software that issu= e > end-user certificates.**** > > **** > > Since the intermediate certificates (issued by root) are also publicly > visible, it does not matter if the serial is random or not.**** > > ** ** > > This has nothing to do with secretly issued certificates, but with known > prefix collision attacks.**** > > **** > > Isn=E2=80=99t it true that this works only if the attacker does not have= access > to the issued certificate?**** > > Assuming the PK certificates are not public is sort of counter-intuitive.= * > *** > > ** ** > > I'm not sure I'm following you.**** > > A certificate is a public object, for sure.**** > > I can't imagine what could be the use of a CA software accepting > certificate requests but refusing access to the issued certificate.**** > > ** ** > > *From:* Erwann Abalea [mailto:eabalea@gmail.com] > *Sent:* Friday, December 14, 2012 9:26 AM > *To:* Piyush Jain > *Cc:* pkix@ietf.org > *Subject:* Re: [pkix] Questioning the benefit of random serials over > sequential ones in x.509 certificates**** > > **** > > Bonjour,**** > > 2012/12/14 Piyush Jain **** > > It seems that the current best practice is to use non-sequential serial > numbers when issuing x.509 certificates.**** > > **** > > That's not only a "best practice", but also a requirement for several roo= t > programs.**** > > **** > > I understand that it had some value when weak hashing algorithms were > being > used to create the signature.**** > > **** > > It still has some value, because weak hash functions are still used in a > signature context. SHA1 isn't over.**** > > **** > > But if you are using a strong hashing algorithm, what is the benefit of > issuing certificates with random serial values?**** > > **** > > I don't see any benefit in such a situation.**** > > **** > > -- > Erwann.**** > > > > **** > > ** ** > > -- > Erwann.**** > --=20 Erwann. --bcaec55400709b42ec04d0d4a992 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's right.
Some root programs accept the randomness to be added = in the subjectName, before any user-supplied data, in a dedicated AVA. That= 's acceptable.

2012/12/14 Schaen, Sam= uel I. <schaen@mitre.org>

From a practical perspect= ive, use of random serial numbers precludes the use of OCSP pre-signed resp= onses that rely on a CRL (rather than direct connection to a CA) and must produce responses for all possible certificates within t= he unexpired issuance range.

=C2=A0

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piyush Jain
Sent: Friday, December 14, 2012 1:27 PM
To: 'Erwann Abalea'


Cc: pkix@ietf.org=
Subject: Re: [pkix] Questioning the benefit of random serials over s= equential ones in x.509 certificates

=C2=A0

From: Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, December 14, 2012 10:17 AM
To: Piyush Jain
Cc: pkix@ietf.org=
Subject: Re: [pkix] Questioning the benefit of random serials over s= equential ones in x.509 certificates

=C2=A0

=C2=A0

2012/12/14 Piyush Jain &l= t;piyush@ditenity.= com>

I=E2=80=99m not sure what value does a root CA g= ets out of this.

=C2=A0

When mentioning root prog= rams, I'm talking about root inclusion into public software (browsers, = mainly), not certificates issued by the root CA. The "random serial&qu= ot; requirement is to be applied to CA software that issue end-user certificates.

=C2=A0

Since the intermediate certificates (issued by r= oot) are also publicly visible, it does not matter if the serial is random = or not.

=C2=A0

This has nothing to do wi= th secretly issued certificates, but with known prefix collision attacks.

=C2=A0

Isn=E2=80=99t it true that this works only if th= e attacker does not have access to the issued certificate?=

Assuming the PK certificates are not public is s= ort of counter-intuitive.

=C2=A0

I'm not sure I'm = following you.

A certificate is a public= object, for sure.

I can't imagine what = could be the use of a CA software accepting certificate requests but refusi= ng access to the issued certificate.

=C2=A0

From: Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, December 14, 2012 9:26 AM
To: Piyush Jain
Cc: pkix@ietf.org=
Subject: Re: [pkix] Questioning the benefit of random serials over s= equential ones in x.509 certificates

=C2=A0

Bonjour,

2012/12/14 Piyush Jain <piyush@ditenity.com>

It seems that the current best practice is to use non-sequential serial
numbers when issuing x.509 certificates.

=C2=A0

That's not only a "best practice", but also a requirement for= several root programs.

=C2=A0

I understand that it had some value when weak hashing algorithms were being=
used to create the signature.

=C2=A0

It still has some value, because weak hash functions are still used in a si= gnature context. SHA1 isn't over.

=C2=A0

But if you are using a strong hashing algorithm, what is the benefit of
issuing certificates with random serial values?

=C2=A0

I don't see any benefit in such a situation.

=C2=A0

--
Erwann.



=C2=A0

--
Erwann.




--
Erwann.
--bcaec55400709b42ec04d0d4a992-- From piyush@ditenity.com Fri Dec 14 11:02:46 2012 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 C6C2121F8B12 for ; Fri, 14 Dec 2012 11:02:46 -0800 (PST) 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 Sem-2oQjtA5V for ; Fri, 14 Dec 2012 11:02:46 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3D5921F8B0C for ; Fri, 14 Dec 2012 11:02:45 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6497580ieb.31 for ; Fri, 14 Dec 2012 11:02:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=OaJqMvCYeOo+CAYUV6fCj47SGKGJ/Lp3g0UyXJ9GIMU=; b=bPexViL7udG0K6bYWSChzmTF7Opyg2eSPMav3JuakcjQc//MQ3RkISduE7Mu86Ro7G dn2PtSXvqpnWQM87u50o2HV51Q6PfJ6mIhAL7jRGFdNCqtG5emLVHLfYaI6JKGWYSxut IMKF09fKdqrrvu8zhMrKvO6wILvHQnz2da0uUVlq8hxUOhof2HAJg9XxmXVvDe63c+cd PBAvyZKtRQNC/rCsCekqG0hltFYlM9zXYNkiI8mfDOOtbuwvDRz+hqb5jDDP7jssldSW ZnuMvYsvNKkCzahKlVBY0DmF7viL5kqORLmPHSomkKr6apLzX33Etys4dwoQH0bLvqDw wJ5Q== Received: by 10.50.170.1 with SMTP id ai1mr2586174igc.30.1355511765330; Fri, 14 Dec 2012 11:02:45 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id uz1sm4588227igb.16.2012.12.14.11.02.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 11:02:44 -0800 (PST) From: "Piyush Jain" To: "'Schaen, Samuel I.'" , "'Erwann Abalea'" References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <043901cdda25$78442770$68cc7650$@ditenity.com> <049301cdda28$ad6c8610$08459230$@ditenity.com> <05B0827555CC904EAAF411605F38BF8306676FC3@IMCMBX01.MITRE.ORG> In-Reply-To: <05B0827555CC904EAAF411605F38BF8306676FC3@IMCMBX01.MITRE.ORG> Date: Fri, 14 Dec 2012 11:02:40 -0800 Message-ID: <04b801cdda2d$98316590$c89430b0$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04B9_01CDD9EA.8A10E4B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHRlKs7YuWAK+X+fx67nstxV6bEfQEe1CSNAnL+QMUButfRpQLAVWwGAlKaXS+XvjQgIA== Content-Language: en-us X-Gm-Message-State: ALoCoQm+tEQUTRAx6W7+55MgVS04UUhTM4v8fcveHvNPIzcjORSdnF22NvpCzhuKdwQcWAOui/sL Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 19:02:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04B9_01CDD9EA.8A10E4B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable J You are a mind reader. I guess you can consider it a benefit from certain perspectives. =20 From: Schaen, Samuel I. [mailto:schaen@mitre.org]=20 Sent: Friday, December 14, 2012 10:52 AM To: Piyush Jain; 'Erwann Abalea' Cc: pkix@ietf.org Subject: RE: [pkix] Questioning the benefit of random serials over = sequential ones in x.509 certificates =20 >From a practical perspective, use of random serial numbers precludes the = use of OCSP pre-signed responses that rely on a CRL (rather than direct = connection to a CA) and must produce responses for all possible = certificates within the unexpired issuance range. =20 From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Piyush Jain Sent: Friday, December 14, 2012 1:27 PM To: 'Erwann Abalea' Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over = sequential ones in x.509 certificates =20 May be I am missing something very basic. If the certificate is available to the attacker, how does random serial = help avoid a prefix collision attack. =20 The attacker just forges another certificate with same serial and keeps = on changing an extension with random value to force a hash collision. Whether the serial in the certificate is random or not should not have = any impact on the above process. =20 -Piyush =20 =20 From: Erwann Abalea [mailto:eabalea@gmail.com]=20 Sent: Friday, December 14, 2012 10:17 AM To: Piyush Jain Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over = sequential ones in x.509 certificates =20 =20 2012/12/14 Piyush Jain I=E2=80=99m not sure what value does a root CA gets out of this. =20 When mentioning root programs, I'm talking about root inclusion into = public software (browsers, mainly), not certificates issued by the root = CA. The "random serial" requirement is to be applied to CA software that = issue end-user certificates. =20 Since the intermediate certificates (issued by root) are also publicly = visible, it does not matter if the serial is random or not. =20 This has nothing to do with secretly issued certificates, but with known = prefix collision attacks. =20 Isn=E2=80=99t it true that this works only if the attacker does not have = access to the issued certificate? Assuming the PK certificates are not public is sort of = counter-intuitive. =20 I'm not sure I'm following you. A certificate is a public object, for sure. I can't imagine what could be the use of a CA software accepting = certificate requests but refusing access to the issued certificate. =20 From: Erwann Abalea [mailto:eabalea@gmail.com]=20 Sent: Friday, December 14, 2012 9:26 AM To: Piyush Jain Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over = sequential ones in x.509 certificates =20 Bonjour, 2012/12/14 Piyush Jain It seems that the current best practice is to use non-sequential serial numbers when issuing x.509 certificates. =20 That's not only a "best practice", but also a requirement for several = root programs. =20 I understand that it had some value when weak hashing algorithms were = being used to create the signature. =20 It still has some value, because weak hash functions are still used in a = signature context. SHA1 isn't over. =20 But if you are using a strong hashing algorithm, what is the benefit of issuing certificates with random serial values? =20 I don't see any benefit in such a situation. =20 --=20 Erwann. =20 --=20 Erwann. ------=_NextPart_000_04B9_01CDD9EA.8A10E4B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

J You are a mind reader.

I guess you can consider it a benefit from certain = perspectives.

 

From:= = Schaen, Samuel I. [mailto:schaen@mitre.org]
Sent: Friday, = December 14, 2012 10:52 AM
To: Piyush Jain; 'Erwann = Abalea'
Cc: pkix@ietf.org
Subject: RE: [pkix] = Questioning the benefit of random serials over sequential ones in x.509 = certificates

 

From a practical perspective, use of random serial numbers precludes = the use of OCSP pre-signed responses that rely on a CRL (rather than = direct connection to a CA) and must produce responses for all possible = certificates within the unexpired issuance = range.

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.= org] On Behalf Of Piyush Jain
Sent: Friday, = December 14, 2012 1:27 PM
To: 'Erwann Abalea'
Cc: pkix@ietf.org
Subject: Re: = [pkix] Questioning the benefit of random serials over sequential ones in = x.509 certificates

 

May be I am missing something very basic.

If the certificate is available to the attacker, how does random = serial help avoid a prefix collision attack.

 

The attacker just forges another certificate with same serial and = keeps on changing an extension with random value to force a hash = collision.

Whether the serial in the certificate is random or not should not = have any impact on the above process.

 

-Piyush

 

 

From:= = Erwann Abalea [mailto:eabalea@gmail.com]=
Sent: Friday, December 14, 2012 10:17 AM
To: = Piyush Jain
Cc: pkix@ietf.org
Subject: Re: = [pkix] Questioning the benefit of random serials over sequential ones in = x.509 certificates

 

 

2012/12/14 Piyush Jain = <piyush@ditenity.com>

I=E2=80=99m not sure what value does a root CA gets out of = this.

 

When mentioning root = programs, I'm talking about root inclusion into public software = (browsers, mainly), not certificates issued by the root CA. The = "random serial" requirement is to be applied to CA software = that issue end-user certificates.

 

Since the intermediate certificates (issued by root) are also = publicly visible, it does not matter if the serial is random or = not.

 

This has nothing to do with = secretly issued certificates, but with known prefix collision = attacks.

 

Isn=E2=80=99t it true that this works only if the attacker does not = have access to the issued certificate?

Assuming the PK certificates are not public is sort of = counter-intuitive.

 

I'm not sure I'm following = you.

A certificate is a public object, for = sure.

I can't imagine what could be the use of a CA = software accepting certificate requests but refusing access to the = issued certificate.

 

From:= = Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, = December 14, 2012 9:26 AM
To: Piyush Jain
Cc: pkix@ietf.org
Subject: Re: [pkix] = Questioning the benefit of random serials over sequential ones in x.509 = certificates

 

B= onjour,

2012/12/14 Piyush Jain <piyush@ditenity.com>

It seems that the current best practice is to use non-sequential = serial
numbers when issuing x.509 certificates.

 

That's not only a "best practice", but also a requirement = for several root programs.

 

I understand that it had some value when weak hashing algorithms = were being
used to create the = signature.

 

It still has some value, because weak hash functions are still used = in a signature context. SHA1 isn't over.

 

But if you are using a strong hashing algorithm, what is the = benefit of
issuing certificates with random serial = values?

 

I don't see any benefit in such a = situation.

 

-- =
Erwann.



 

-- =
Erwann.

------=_NextPart_000_04B9_01CDD9EA.8A10E4B0-- From SChokhani@cygnacom.com Fri Dec 14 11:04:25 2012 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 2B5B721F8A8E for ; Fri, 14 Dec 2012 11:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 PGAcOP4lWeBc for ; Fri, 14 Dec 2012 11:04:24 -0800 (PST) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id D1AFB21F8AB6 for ; Fri, 14 Dec 2012 11:04:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,282,1355115600"; d="scan'208,217";a="7195119" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 14 Dec 2012 14:04:22 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 14 Dec 2012 14:04:22 -0500 From: Santosh Chokhani To: Piyush Jain , 'Erwann Abalea' Date: Fri, 14 Dec 2012 14:04:21 -0500 Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: AQHRlKs7YuWAK+X+fx67nstxV6bEfQEe1CSNAnL+QMUButfRpZfmwNLQgAAK1ZA= Message-ID: References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <043901cdda25$78442770$68cc7650$@ditenity.com> <049301cdda28$ad6c8610$08459230$@ditenity.com> In-Reply-To: <049301cdda28$ad6c8610$08459230$@ditenity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF36327652scygexch7cygnac_" MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 19:04:25 -0000 --_000_B83745DA469B7847811819C5005244AF36327652scygexch7cygnac_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGl5dXNoLA0KDQpUaGlzIHJlcXVpcmVzIHVuZGVyc3RhbmRpbmcgd2hhdCBhIGNvbGxpc2lvbiBh dHRhY2sgaXMuICBJbiBsYXlwZXJzb27igJlzIHRlcm1zLCB0aGUgYWR2ZXJzYXJ5IHdobyBpcyBh IGxlZ2l0aW1hdGUgYXBwbGljYW50IGZvciBhIGNlcnRpZmljYXRlLCAgY3JlYXRlcyBuYW1lcyBh bmQga2V5cyBzdWNoIHdoZW4gdGhlIENBIHNpZ25zIGEgY2VydGlmaWNhdGUsIHRoZSBoYXNoIHdp bGwgYmUgdGhlIHNhbWUgYXMgdGhlIGFkdmVyc2FyeSBoYXMgY3JlYXRlZCBjb2xsaXNpb24gZm9y IHdoaWxlIHN1Ym1pdHRpbmcgdGhlIHJlcXVlc3QuICBOb3cgdGhlIGFkdmVyc2FyeSBjYW4gcHJl c2VudCB0aGUgb3RoZXIgY2VydGlmaWNhdGUgd2l0aCBiYXNpYyBjb25zdHJhaW50IGV4dGVuc2lv biwgd2l0aCBkaWZmZXJlbnQgbmFtZSwgb3Igd2l0aCBkaWZmZXJlbnQgcG9saWNpZXMgYXMgaXNz dWVkIGJ5IHRoZSBDQS4gIEluIHRoaXMgcHJvY2VzcywgdGhlIGFkdmVyc2FyeSB3aGlsZSBjb21w dXRpbmcgdGhlIGNvbGxpc2lvbiBuZWVkcyB0byBrbm93IHRoZSBsaWtlbHkgc2VyaWFsIG51bWJl ciB0aGUgQ0Egd2lsbCBhc3NpZ24sIGFtb25nIG90aGVyIHRoaW5ncy4gUmFuZG9taXppbmcgc2Vy aWFsIG51bWJlciBpcyBvbmUgd2F5IG9mIGRlZmVhdGluZyB0aGUgYXR0YWNrLiAgUHV0dGluZyBy YW5kb21uZXNzIGlzIG5vdCBhZnRlciBpcyBhbm90aGVyLiAgUmFuZG9tbmVzcyBuZWVkcyB0byBj b21lIGJlZm9yZSBTdWJqZWN0IEROIHNpbmNlIHRoYXQgaXMgdGhlIG1vc3QgbGlrZWx5IGZpcnN0 IGlucHV0IGZyb20gdGhlIGF0dGFja2VyIHdoZW4geW91IHNjYW4gdGhlIGNlcnRpZmljYXRlLiAg TXkgZmF2b3JpdGUgaXMgdGhlIHBhcmFtZXRlciBmaWVsZCBpbiBzaWduYXR1cmUgZmllbGQgc2lu Y2UgaXQgaXMgbm90IHN1cHBvc2VkIHRvIGJlIHVzZWQuICBCdXQsIEkgYW0gYWZyYWlkIGl0IGlz IG5vdCBwcmFjdGljYWwgc2luY2UgaXQgd2lsbCBmcmVhayBvdXQgbW9zdCBhcHBsaWNhdGlvbnMu DQoNCg0KRnJvbTogcGtpeC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGtpeC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgUGl5dXNoIEphaW4NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIg MTQsIDIwMTIgMToyNyBQTQ0KVG86ICdFcndhbm4gQWJhbGVhJw0KQ2M6IHBraXhAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbcGtpeF0gUXVlc3Rpb25pbmcgdGhlIGJlbmVmaXQgb2YgcmFuZG9tIHNl cmlhbHMgb3ZlciBzZXF1ZW50aWFsIG9uZXMgaW4geC41MDkgY2VydGlmaWNhdGVzDQoNCk1heSBi ZSBJIGFtIG1pc3Npbmcgc29tZXRoaW5nIHZlcnkgYmFzaWMuDQpJZiB0aGUgY2VydGlmaWNhdGUg aXMgYXZhaWxhYmxlIHRvIHRoZSBhdHRhY2tlciwgaG93IGRvZXMgcmFuZG9tIHNlcmlhbCBoZWxw IGF2b2lkIGEgcHJlZml4IGNvbGxpc2lvbiBhdHRhY2suDQoNClRoZSBhdHRhY2tlciBqdXN0IGZv cmdlcyBhbm90aGVyIGNlcnRpZmljYXRlIHdpdGggc2FtZSBzZXJpYWwgYW5kIGtlZXBzIG9uIGNo YW5naW5nIGFuIGV4dGVuc2lvbiB3aXRoIHJhbmRvbSB2YWx1ZSB0byBmb3JjZSBhIGhhc2ggY29s bGlzaW9uLg0KV2hldGhlciB0aGUgc2VyaWFsIGluIHRoZSBjZXJ0aWZpY2F0ZSBpcyByYW5kb20g b3Igbm90IHNob3VsZCBub3QgaGF2ZSBhbnkgaW1wYWN0IG9uIHRoZSBhYm92ZSBwcm9jZXNzLg0K DQotUGl5dXNoDQoNCg0KRnJvbTogRXJ3YW5uIEFiYWxlYSBbbWFpbHRvOmVhYmFsZWFAZ21haWwu Y29tXQ0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAxNCwgMjAxMiAxMDoxNyBBTQ0KVG86IFBpeXVz aCBKYWluDQpDYzogcGtpeEBpZXRmLm9yZzxtYWlsdG86cGtpeEBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbcGtpeF0gUXVlc3Rpb25pbmcgdGhlIGJlbmVmaXQgb2YgcmFuZG9tIHNlcmlhbHMgb3Zl ciBzZXF1ZW50aWFsIG9uZXMgaW4geC41MDkgY2VydGlmaWNhdGVzDQoNCg0KMjAxMi8xMi8xNCBQ aXl1c2ggSmFpbiA8cGl5dXNoQGRpdGVuaXR5LmNvbTxtYWlsdG86cGl5dXNoQGRpdGVuaXR5LmNv bT4+DQpJ4oCZbSBub3Qgc3VyZSB3aGF0IHZhbHVlIGRvZXMgYSByb290IENBIGdldHMgb3V0IG9m IHRoaXMuDQoNCldoZW4gbWVudGlvbmluZyByb290IHByb2dyYW1zLCBJJ20gdGFsa2luZyBhYm91 dCByb290IGluY2x1c2lvbiBpbnRvIHB1YmxpYyBzb2Z0d2FyZSAoYnJvd3NlcnMsIG1haW5seSks IG5vdCBjZXJ0aWZpY2F0ZXMgaXNzdWVkIGJ5IHRoZSByb290IENBLiBUaGUgInJhbmRvbSBzZXJp YWwiIHJlcXVpcmVtZW50IGlzIHRvIGJlIGFwcGxpZWQgdG8gQ0Egc29mdHdhcmUgdGhhdCBpc3N1 ZSBlbmQtdXNlciBjZXJ0aWZpY2F0ZXMuDQoNClNpbmNlIHRoZSBpbnRlcm1lZGlhdGUgY2VydGlm aWNhdGVzIChpc3N1ZWQgYnkgcm9vdCkgYXJlIGFsc28gcHVibGljbHkgdmlzaWJsZSwgaXQgZG9l cyBub3QgbWF0dGVyIGlmIHRoZSBzZXJpYWwgaXMgcmFuZG9tIG9yIG5vdC4NCg0KVGhpcyBoYXMg bm90aGluZyB0byBkbyB3aXRoIHNlY3JldGx5IGlzc3VlZCBjZXJ0aWZpY2F0ZXMsIGJ1dCB3aXRo IGtub3duIHByZWZpeCBjb2xsaXNpb24gYXR0YWNrcy4NCg0KSXNu4oCZdCBpdCB0cnVlIHRoYXQg dGhpcyB3b3JrcyBvbmx5IGlmIHRoZSBhdHRhY2tlciBkb2VzIG5vdCBoYXZlIGFjY2VzcyB0byB0 aGUgaXNzdWVkIGNlcnRpZmljYXRlPw0KQXNzdW1pbmcgdGhlIFBLIGNlcnRpZmljYXRlcyBhcmUg bm90IHB1YmxpYyBpcyBzb3J0IG9mIGNvdW50ZXItaW50dWl0aXZlLg0KDQpJJ20gbm90IHN1cmUg SSdtIGZvbGxvd2luZyB5b3UuDQpBIGNlcnRpZmljYXRlIGlzIGEgcHVibGljIG9iamVjdCwgZm9y IHN1cmUuDQpJIGNhbid0IGltYWdpbmUgd2hhdCBjb3VsZCBiZSB0aGUgdXNlIG9mIGEgQ0Egc29m dHdhcmUgYWNjZXB0aW5nIGNlcnRpZmljYXRlIHJlcXVlc3RzIGJ1dCByZWZ1c2luZyBhY2Nlc3Mg dG8gdGhlIGlzc3VlZCBjZXJ0aWZpY2F0ZS4NCg0KRnJvbTogRXJ3YW5uIEFiYWxlYSBbbWFpbHRv OmVhYmFsZWFAZ21haWwuY29tPG1haWx0bzplYWJhbGVhQGdtYWlsLmNvbT5dDQpTZW50OiBGcmlk YXksIERlY2VtYmVyIDE0LCAyMDEyIDk6MjYgQU0NClRvOiBQaXl1c2ggSmFpbg0KQ2M6IHBraXhA aWV0Zi5vcmc8bWFpbHRvOnBraXhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3BraXhdIFF1ZXN0 aW9uaW5nIHRoZSBiZW5lZml0IG9mIHJhbmRvbSBzZXJpYWxzIG92ZXIgc2VxdWVudGlhbCBvbmVz IGluIHguNTA5IGNlcnRpZmljYXRlcw0KDQpCb25qb3VyLA0KMjAxMi8xMi8xNCBQaXl1c2ggSmFp biA8cGl5dXNoQGRpdGVuaXR5LmNvbTxtYWlsdG86cGl5dXNoQGRpdGVuaXR5LmNvbT4+DQpJdCBz ZWVtcyB0aGF0IHRoZSBjdXJyZW50IGJlc3QgcHJhY3RpY2UgaXMgdG8gdXNlIG5vbi1zZXF1ZW50 aWFsIHNlcmlhbA0KbnVtYmVycyB3aGVuIGlzc3VpbmcgeC41MDkgY2VydGlmaWNhdGVzLg0KDQpU aGF0J3Mgbm90IG9ubHkgYSAiYmVzdCBwcmFjdGljZSIsIGJ1dCBhbHNvIGEgcmVxdWlyZW1lbnQg Zm9yIHNldmVyYWwgcm9vdCBwcm9ncmFtcy4NCg0KSSB1bmRlcnN0YW5kIHRoYXQgaXQgaGFkIHNv bWUgdmFsdWUgd2hlbiB3ZWFrIGhhc2hpbmcgYWxnb3JpdGhtcyB3ZXJlIGJlaW5nDQp1c2VkIHRv IGNyZWF0ZSB0aGUgc2lnbmF0dXJlLg0KDQpJdCBzdGlsbCBoYXMgc29tZSB2YWx1ZSwgYmVjYXVz ZSB3ZWFrIGhhc2ggZnVuY3Rpb25zIGFyZSBzdGlsbCB1c2VkIGluIGEgc2lnbmF0dXJlIGNvbnRl eHQuIFNIQTEgaXNuJ3Qgb3Zlci4NCg0KQnV0IGlmIHlvdSBhcmUgdXNpbmcgYSBzdHJvbmcgaGFz aGluZyBhbGdvcml0aG0sIHdoYXQgaXMgdGhlIGJlbmVmaXQgb2YNCmlzc3VpbmcgY2VydGlmaWNh dGVzIHdpdGggcmFuZG9tIHNlcmlhbCB2YWx1ZXM/DQoNCkkgZG9uJ3Qgc2VlIGFueSBiZW5lZml0 IGluIHN1Y2ggYSBzaXR1YXRpb24uDQoNCi0tDQpFcndhbm4uDQoNCg0KDQotLQ0KRXJ3YW5uLg0K --_000_B83745DA469B7847811819C5005244AF36327652scygexch7cygnac_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpu b3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9o ZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdv cmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QaXl1c2gs PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5UaGlzIHJlcXVpcmVzIHVuZGVyc3RhbmRpbmcgd2hhdCBhIGNvbGxpc2lv biBhdHRhY2sgaXMuwqAgSW4gbGF5cGVyc29u4oCZcyB0ZXJtcywgdGhlIGFkdmVyc2FyeSB3aG8g aXMgYSBsZWdpdGltYXRlIGFwcGxpY2FudCBmb3IgYSBjZXJ0aWZpY2F0ZSwgwqBjcmVhdGVzIG5h bWVzIGFuZCBrZXlzIHN1Y2ggd2hlbiB0aGUgQ0Egc2lnbnMgYSBjZXJ0aWZpY2F0ZSwgdGhlIGhh c2ggd2lsbCBiZSB0aGUgc2FtZSBhcyB0aGUgYWR2ZXJzYXJ5IGhhcyBjcmVhdGVkIGNvbGxpc2lv biBmb3Igd2hpbGUgc3VibWl0dGluZyB0aGUgcmVxdWVzdC7CoCBOb3cgdGhlIGFkdmVyc2FyeSBj YW4gcHJlc2VudCB0aGUgb3RoZXIgY2VydGlmaWNhdGUgd2l0aCBiYXNpYyBjb25zdHJhaW50IGV4 dGVuc2lvbiwgd2l0aCBkaWZmZXJlbnQgbmFtZSwgb3Igd2l0aCBkaWZmZXJlbnQgcG9saWNpZXMg YXMgaXNzdWVkIGJ5IHRoZSBDQS7CoCBJbiB0aGlzIHByb2Nlc3MsIHRoZSBhZHZlcnNhcnkgd2hp bGUgY29tcHV0aW5nIHRoZSBjb2xsaXNpb24gbmVlZHMgdG8ga25vdyB0aGUgbGlrZWx5IHNlcmlh bCBudW1iZXIgdGhlIENBIHdpbGwgYXNzaWduLCBhbW9uZyBvdGhlciB0aGluZ3MuIFJhbmRvbWl6 aW5nIHNlcmlhbCBudW1iZXIgaXMgb25lIHdheSBvZiBkZWZlYXRpbmcgdGhlIGF0dGFjay7CoCBQ dXR0aW5nIHJhbmRvbW5lc3MgaXMgbm90IGFmdGVyIGlzIGFub3RoZXIuwqAgUmFuZG9tbmVzcyBu ZWVkcyB0byBjb21lIGJlZm9yZSBTdWJqZWN0IEROIHNpbmNlIHRoYXQgaXMgdGhlIG1vc3QgbGlr ZWx5IGZpcnN0IGlucHV0IGZyb20gdGhlIGF0dGFja2VyIHdoZW4geW91IHNjYW4gdGhlIGNlcnRp ZmljYXRlLsKgIE15IGZhdm9yaXRlIGlzIHRoZSBwYXJhbWV0ZXIgZmllbGQgaW4gc2lnbmF0dXJl IGZpZWxkIHNpbmNlIGl0IGlzIG5vdCBzdXBwb3NlZCB0byBiZSB1c2VkLsKgIEJ1dCwgSSBhbSBh ZnJhaWQgaXQgaXMgbm90IHByYWN0aWNhbCBzaW5jZSBpdCB3aWxsIGZyZWFrIG91dCBtb3N0IGFw cGxpY2F0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2 PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gcGtpeC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGtp eC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPlBpeXVzaCBKYWluPGJyPjxi PlNlbnQ6PC9iPiBGcmlkYXksIERlY2VtYmVyIDE0LCAyMDEyIDE6MjcgUE08YnI+PGI+VG86PC9i PiAnRXJ3YW5uIEFiYWxlYSc8YnI+PGI+Q2M6PC9iPiBwa2l4QGlldGYub3JnPGJyPjxiPlN1Ympl Y3Q6PC9iPiBSZTogW3BraXhdIFF1ZXN0aW9uaW5nIHRoZSBiZW5lZml0IG9mIHJhbmRvbSBzZXJp YWxzIG92ZXIgc2VxdWVudGlhbCBvbmVzIGluIHguNTA5IGNlcnRpZmljYXRlczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+TWF5IGJlIEkg YW0gbWlzc2luZyBzb21ldGhpbmcgdmVyeSBiYXNpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SWYgdGhlIGNlcnRpZmljYXRl IGlzIGF2YWlsYWJsZSB0byB0aGUgYXR0YWNrZXIsIGhvdyBkb2VzIHJhbmRvbSBzZXJpYWwgaGVs cCBhdm9pZCBhIHByZWZpeCBjb2xsaXNpb24gYXR0YWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhl IGF0dGFja2VyIGp1c3QgZm9yZ2VzIGFub3RoZXIgY2VydGlmaWNhdGUgd2l0aCBzYW1lIHNlcmlh bCBhbmQga2VlcHMgb24gY2hhbmdpbmcgYW4gZXh0ZW5zaW9uIHdpdGggcmFuZG9tIHZhbHVlIHRv IGZvcmNlIGEgaGFzaCBjb2xsaXNpb24uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldoZXRoZXIgdGhlIHNlcmlhbCBpbiB0aGUg Y2VydGlmaWNhdGUgaXMgcmFuZG9tIG9yIG5vdCBzaG91bGQgbm90IGhhdmUgYW55IGltcGFjdCBv biB0aGUgYWJvdmUgcHJvY2Vzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi1QaXl1c2g8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBFcndhbm4gQWJhbGVhIFs8YSBocmVmPSJt YWlsdG86ZWFiYWxlYUBnbWFpbC5jb20iPm1haWx0bzplYWJhbGVhQGdtYWlsLmNvbTwvYT5dIDxi cj48Yj5TZW50OjwvYj4gRnJpZGF5LCBEZWNlbWJlciAxNCwgMjAxMiAxMDoxNyBBTTxicj48Yj5U bzo8L2I+IFBpeXVzaCBKYWluPGJyPjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnBraXhAaWV0 Zi5vcmciPnBraXhAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3BraXhdIFF1 ZXN0aW9uaW5nIHRoZSBiZW5lZml0IG9mIHJhbmRvbSBzZXJpYWxzIG92ZXIgc2VxdWVudGlhbCBv bmVzIGluIHguNTA5IGNlcnRpZmljYXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjIwMTIvMTIv MTQgUGl5dXNoIEphaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwaXl1c2hAZGl0ZW5pdHkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+cGl5dXNoQGRpdGVuaXR5LmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPknigJltIG5v dCBzdXJlIHdoYXQgdmFsdWUgZG9lcyBhIHJvb3QgQ0EgZ2V0cyBvdXQgb2YgdGhpcy48L3NwYW4+ PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+V2hlbiBtZW50aW9uaW5nIHJv b3QgcHJvZ3JhbXMsIEknbSB0YWxraW5nIGFib3V0IHJvb3QgaW5jbHVzaW9uIGludG8gcHVibGlj IHNvZnR3YXJlIChicm93c2VycywgbWFpbmx5KSwgbm90IGNlcnRpZmljYXRlcyBpc3N1ZWQgYnkg dGhlIHJvb3QgQ0EuIFRoZSAmcXVvdDtyYW5kb20gc2VyaWFsJnF1b3Q7IHJlcXVpcmVtZW50IGlz IHRvIGJlIGFwcGxpZWQgdG8gQ0Egc29mdHdhcmUgdGhhdCBpc3N1ZSBlbmQtdXNlciBjZXJ0aWZp Y2F0ZXMuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7 PG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+U2luY2UgdGhlIGludGVybWVkaWF0ZSBjZXJ0aWZpY2F0ZXMgKGlzc3VlZCBieSBy b290KSBhcmUgYWxzbyBwdWJsaWNseSB2aXNpYmxlLCBpdCBkb2VzIG5vdCBtYXR0ZXIgaWYgdGhl IHNlcmlhbCBpcyByYW5kb20gb3Igbm90Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhpcyBoYXMgbm90aGluZyB0byBkbyB3 aXRoIHNlY3JldGx5IGlzc3VlZCBjZXJ0aWZpY2F0ZXMsIGJ1dCB3aXRoIGtub3duIHByZWZpeCBj b2xsaXNpb24gYXR0YWNrcy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+SXNu4oCZdCBpdCB0cnVlIHRoYXQgdGhpcyB3b3JrcyBvbmx5IGlmIHRo ZSBhdHRhY2tlciBkb2VzIG5vdCBoYXZlIGFjY2VzcyB0byB0aGUgaXNzdWVkIGNlcnRpZmljYXRl Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkFzc3VtaW5nIHRoZSBQSyBjZXJ0aWZpY2F0ZXMgYXJlIG5vdCBwdWJsaWMgaXMg c29ydCBvZiBjb3VudGVyLWludHVpdGl2ZS48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9i bG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkknbSBub3Qgc3VyZSBJJ20gZm9sbG93aW5nIHlv dS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5BIGNlcnRpZmlj YXRlIGlzIGEgcHVibGljIG9iamVjdCwgZm9yIHN1cmUuPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBjYW4ndCBpbWFnaW5lIHdoYXQgY291bGQgYmUgdGhlIHVz ZSBvZiBhIENBIHNvZnR3YXJlIGFjY2VwdGluZyBjZXJ0aWZpY2F0ZSByZXF1ZXN0cyBidXQgcmVm dXNpbmcgYWNjZXNzIHRvIHRoZSBpc3N1ZWQgY2VydGlmaWNhdGUuPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGJs b2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2IHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IEVyd2FubiBBYmFs ZWEgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZWFiYWxlYUBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5lYWJhbGVhQGdtYWlsLmNvbTwvYT5dIDxicj48Yj5TZW50OjwvYj4gRnJpZGF5LCBEZWNl bWJlciAxNCwgMjAxMiA5OjI2IEFNPGJyPjxiPlRvOjwvYj4gUGl5dXNoIEphaW48YnI+PGI+Q2M6 PC9iPiA8YSBocmVmPSJtYWlsdG86cGtpeEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBraXhA aWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3BraXhdIFF1ZXN0aW9uaW5nIHRo ZSBiZW5lZml0IG9mIHJhbmRvbSBzZXJpYWxzIG92ZXIgc2VxdWVudGlhbCBvbmVzIGluIHguNTA5 IGNlcnRpZmljYXRlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+ Qm9uam91ciw8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjIwMTIvMTIv MTQgUGl5dXNoIEphaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwaXl1c2hAZGl0ZW5pdHkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+cGl5dXNoQGRpdGVuaXR5LmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+SXQgc2VlbXMgdGhhdCB0aGUgY3VycmVudCBiZXN0IHByYWN0 aWNlIGlzIHRvIHVzZSBub24tc2VxdWVudGlhbCBzZXJpYWw8YnI+bnVtYmVycyB3aGVuIGlzc3Vp bmcgeC41MDkgY2VydGlmaWNhdGVzLjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz5UaGF0J3Mgbm90IG9ubHkgYSAmcXVvdDtiZXN0IHByYWN0aWNlJnF1b3Q7LCBidXQgYWxzbyBh IHJlcXVpcmVtZW50IGZvciBzZXZlcmFsIHJvb3QgcHJvZ3JhbXMuPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48 YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Jz48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz5JIHVuZGVyc3RhbmQgdGhhdCBpdCBoYWQgc29tZSB2YWx1ZSB3aGVuIHdlYWsg aGFzaGluZyBhbGdvcml0aG1zIHdlcmUgYmVpbmc8YnI+dXNlZCB0byBjcmVhdGUgdGhlIHNpZ25h dHVyZS48bzpwPjwvbzpwPjwvcD48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPkl0 IHN0aWxsIGhhcyBzb21lIHZhbHVlLCBiZWNhdXNlIHdlYWsgaGFzaCBmdW5jdGlvbnMgYXJlIHN0 aWxsIHVzZWQgaW4gYSBzaWduYXR1cmUgY29udGV4dC4gU0hBMSBpc24ndCBvdmVyLjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48 L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCc+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+QnV0IGlmIHlvdSBhcmUgdXNpbmcgYSBzdHJvbmcgaGFzaGlu ZyBhbGdvcml0aG0sIHdoYXQgaXMgdGhlIGJlbmVmaXQgb2Y8YnI+aXNzdWluZyBjZXJ0aWZpY2F0 ZXMgd2l0aCByYW5kb20gc2VyaWFsIHZhbHVlcz88bzpwPjwvbzpwPjwvcD48L2Jsb2NrcXVvdGU+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPkkgZG9uJ3Qgc2VlIGFueSBiZW5lZml0IGluIHN1Y2ggYSBz aXR1YXRpb24uPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4m bmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4tLSA8 YnI+RXJ3YW5uLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2tx dW90ZT48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxiciBjbGVhcj1hbGw+PG86cD48L286 cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPi0tIDxicj5Fcndhbm4uPG86cD48L286cD48L3A+PC9kaXY+PC9k aXY+PC9ib2R5PjwvaHRtbD4= --_000_B83745DA469B7847811819C5005244AF36327652scygexch7cygnac_-- From DPKemp@missi.ncsc.mil Fri Dec 14 11:11:17 2012 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 8574C21F8AD8 for ; Fri, 14 Dec 2012 11:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOeZrHWd4sFQ for ; Fri, 14 Dec 2012 11:11:17 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id CE43721F8A90 for ; Fri, 14 Dec 2012 11:11:16 -0800 (PST) Received: from clavin.missi.ncsc.mil (odysseus.missi.ncsc.mil [144.51.60.172]) by stingray.missi.ncsc.mil with ESMTP id qBEJBFqx036526 for ; Fri, 14 Dec 2012 14:11:15 -0500 (EST) Received: from clavin.missi.ncsc.mil ([169.254.1.149]) by odysseus.missi.ncsc.mil ([144.51.60.172]) with mapi id 14.01.0421.002; Fri, 14 Dec 2012 14:11:15 -0500 From: "Kemp, David P." To: "pkix@ietf.org" Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: Ac3aHP2+k1UCZ+fYR0SXQqG7rwstYAAAsvTgAAxXIoAACjLvMA== Date: Fri, 14 Dec 2012 19:11:13 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC850AF8DB1@clavin.missi.ncsc.mil> References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <5B1D7E570380A64989D4C069F7D14BC850AF8D4D@clavin.missi.ncsc.mil> <044601cdda27$3e67eb70$bb37c250$@ditenity.com> In-Reply-To: <044601cdda27$3e67eb70$bb37c250$@ditenity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.54.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 19:11:17 -0000 From: Piyush Jain [mailto:piyush@ditenity.com]=20 > If the only way to retrieve a certificate from a directory > or web repository is to know its name or serial number, > then making valid S/Ns difficult to guess makes trawling > more difficult and easier to detect. =20 [Piyush] Are there such mechanisms in place for securing access to the dire= ctory? Can't you achieve the same by using a combination of serial and some= other cert attribute such as CN? Sure, but why bother. It isn't difficult for a CA to generate random (or "= random-ish", as with AKI/SKI) serial numbers, and doing so mitigates both t= he weak hash security issue and the serial-only privacy issue. IMO it's a = generic good practice just like "don't use a key for more than one purpose"= . Following good practices can head off problems that haven't been thought= of yet. As for Sam's pre-signed OCSP question, I'm not sure how an OCSP responder c= ould pre-sign responses solely from a CRL without also having either a conn= ection to the CA or a list of issued certs. Where do the DN's in the respo= nses come from if the only information available to the signer is a CRL? I= f the issued list isn't updated fast enough, then update it faster :-). From piyush@ditenity.com Fri Dec 14 11:12:00 2012 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 0C12C21F8B38 for ; Fri, 14 Dec 2012 11:12:00 -0800 (PST) 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 F6Y-lUDq2AXf for ; Fri, 14 Dec 2012 11:11:59 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF8E321F8B37 for ; Fri, 14 Dec 2012 11:11:58 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6513273ieb.31 for ; Fri, 14 Dec 2012 11:11:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language:x-gm-message-state; bh=N+QsW7z6j7taCQ7+JryWIYGeAAubZFuin+QMWV8J7VY=; b=SOryzmuT6ytr0uZhs4IBymKZe/ZAR0Qk2vLma992Gvq4yv9DDfJEUSe+XEdJW4RgbH evbKRrRYoFMhU5iDKxVOoePJUOFDnwzwp7YauusVSoWsPchPoUDVip9upTsWQ9BxwwrF Rkk97r56vvx7XFAGYDl3JbeQapVD9H7OxlGYRwKXlmtXcMJBa8bAHul7dYv2CVAdS5pk 5yXq9CYZ8jQ/XqRDDNZsmsJHWu+sQcQ5sSPjBU9UVgDX4W56hrAkz1lzWJ2vdVNqYr8N 1j1h8eS+++/togeLAUYobOf21cAGF6qPiClX5pRV9dsGbqixfV5mjBjSGP6WeeTeEk4J jz1w== X-Received: by 10.50.91.195 with SMTP id cg3mr2616133igb.57.1355512318445; Fri, 14 Dec 2012 11:11:58 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id ez8sm4605103igb.17.2012.12.14.11.11.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 11:11:57 -0800 (PST) From: "Piyush Jain" To: "'Erwann Abalea'" References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <043901cdda25$78442770$68cc7650$@ditenity.com> <049301cdda28$ad6c8610$08459230$@ditenity.com> In-Reply-To: Date: Fri, 14 Dec 2012 11:11:54 -0800 Message-ID: <04c801cdda2e$e1ee8b30$a5cba190$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04C9_01CDD9EB.D3CE0A50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHRlKs7YuWAK+X+fx67nstxV6bEfQEe1CSNAnL+QMUButfRpQLAVWwGAi+u+0yXv0yzIA== Content-Language: en-us X-Gm-Message-State: ALoCoQlOmL94ZJ5oDyQ0FH73CQeyefcoK9Bo51URa5XZdliVN9OVotkn3co2eC2+Y9ZqrsQeKTwm Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 19:12:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04C9_01CDD9EB.D3CE0A50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The goal of the attacker is to get Hash(m1) to be equal to Hash of(m2 + = junk) to ensure that signatures on m1 and (m2+junk) are same If m1 is visible to the attacker (public key certificate in this case), = does the content of m1 really matter? =20 From: Erwann Abalea [mailto:eabalea@gmail.com]=20 Sent: Friday, December 14, 2012 10:59 AM To: Piyush Jain Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over = sequential ones in x.509 certificates =20 =20 2012/12/14 Piyush Jain May be I am missing something very basic. If the certificate is available to the attacker, how does random serial = help avoid a prefix collision attack. =20 The attacker just forges another certificate with same serial and keeps = on changing an extension with random value to force a hash collision. =20 The attacker doesn't choose the serial number. If it's not random, it = can only guess it. The attacker also can't choose the extensions it will have in its = certificate (or he might as well choose to simply get a = basicConstraints:CA=3Dtrue certificate). Maybe you're mistaking this attack with a complete CA compromise? =20 Whether the serial in the certificate is random or not should not have = any impact on the above process. =20 You should read http://www.win.tue.nl/hashclash/rogue-ca/ It's well written. =20 From: Erwann Abalea [mailto:eabalea@gmail.com]=20 Sent: Friday, December 14, 2012 10:17 AM To: Piyush Jain Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over = sequential ones in x.509 certificates =20 =20 2012/12/14 Piyush Jain I=E2=80=99m not sure what value does a root CA gets out of this. =20 When mentioning root programs, I'm talking about root inclusion into = public software (browsers, mainly), not certificates issued by the root = CA. The "random serial" requirement is to be applied to CA software that = issue end-user certificates. =20 Since the intermediate certificates (issued by root) are also publicly = visible, it does not matter if the serial is random or not. =20 This has nothing to do with secretly issued certificates, but with known = prefix collision attacks. =20 Isn=E2=80=99t it true that this works only if the attacker does not have = access to the issued certificate? Assuming the PK certificates are not public is sort of = counter-intuitive. =20 I'm not sure I'm following you. A certificate is a public object, for sure. I can't imagine what could be the use of a CA software accepting = certificate requests but refusing access to the issued certificate. =20 From: Erwann Abalea [mailto:eabalea@gmail.com]=20 Sent: Friday, December 14, 2012 9:26 AM To: Piyush Jain Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over = sequential ones in x.509 certificates =20 Bonjour, 2012/12/14 Piyush Jain It seems that the current best practice is to use non-sequential serial numbers when issuing x.509 certificates. =20 That's not only a "best practice", but also a requirement for several = root programs. =20 I understand that it had some value when weak hashing algorithms were = being used to create the signature. =20 It still has some value, because weak hash functions are still used in a = signature context. SHA1 isn't over. =20 But if you are using a strong hashing algorithm, what is the benefit of issuing certificates with random serial values? =20 I don't see any benefit in such a situation. =20 --=20 Erwann. =20 --=20 Erwann. =20 --=20 Erwann. ------=_NextPart_000_04C9_01CDD9EB.D3CE0A50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The goal of the attacker is to get Hash(m1) to be equal to Hash of(m2 = + junk) to ensure that signatures on m1 and (m2+junk) are = same

If m1 is visible to the attacker (public key certificate in this = case), does the content of m1 really matter?

 

From:= = Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, = December 14, 2012 10:59 AM
To: Piyush Jain
Cc: = pkix@ietf.org
Subject: Re: [pkix] Questioning the benefit of = random serials over sequential ones in x.509 = certificates

 

 

2012/12/14 Piyush Jain <piyush@ditenity.com>

May be I am missing something very basic.

If the certificate is available to the attacker, how does random = serial help avoid a prefix collision attack.

 

The attacker just forges another certificate with same serial and = keeps on changing an extension with random value to force a hash = collision.

 

The attacker doesn't choose the serial number. If it's = not random, it can only guess it.

The attacker also can't choose the extensions it will = have in its certificate (or he might as well choose to simply get a = basicConstraints:CA=3Dtrue certificate).

Maybe you're mistaking this attack with a complete CA = compromise?

 

Whether the serial in the certificate is random or not should not = have any impact on the above = process.

 

It's well written.

  

From:= = Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, = December 14, 2012 10:17 AM


To: Piyush Jain
Cc: pkix@ietf.org
Subject: Re: [pkix] = Questioning the benefit of random serials over sequential ones in x.509 = certificates

 <= /o:p>

 <= /o:p>

2012/12/14 = Piyush Jain <piyush@ditenity.com>

I=E2=80=99m not sure what value does a root CA gets out of = this.

 <= /o:p>

When = mentioning root programs, I'm talking about root inclusion into public = software (browsers, mainly), not certificates issued by the root CA. The = "random serial" requirement is to be applied to CA software = that issue end-user certificates.

 <= /o:p>

Since the intermediate certificates (issued by root) are also = publicly visible, it does not matter if the serial is random or = not.

 <= /o:p>

This has = nothing to do with secretly issued certificates, but with known prefix = collision attacks.

 <= /o:p>

Isn=E2=80=99t it true that this works only if the attacker does not = have access to the issued certificate?

Assuming the PK certificates are not public is sort of = counter-intuitive.

 <= /o:p>

I'm not = sure I'm following you.

A = certificate is a public object, for sure.

I can't = imagine what could be the use of a CA software accepting certificate = requests but refusing access to the issued = certificate.

 <= /o:p>

From:= = Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, = December 14, 2012 9:26 AM
To: Piyush Jain
Cc: pkix@ietf.org
Subject: Re: [pkix] = Questioning the benefit of random serials over sequential ones in x.509 = certificates

 <= /o:p>

Bonjour,

2012/12/14 = Piyush Jain <piyush@ditenity.com>

It seems = that the current best practice is to use non-sequential = serial
numbers when issuing x.509 certificates.

 <= /o:p>

That's not = only a "best practice", but also a requirement for several = root programs.

 <= /o:p>

I = understand that it had some value when weak hashing algorithms were = being
used to create the = signature.

 <= /o:p>

It still = has some value, because weak hash functions are still used in a = signature context. SHA1 isn't over.

 <= /o:p>

But if you = are using a strong hashing algorithm, what is the benefit of
issuing = certificates with random serial = values?

 <= /o:p>

I don't see = any benefit in such a situation.

 <= /o:p>

-- =
Erwann.



 <= /o:p>

-- =
Erwann.



 

-- =
Erwann.

------=_NextPart_000_04C9_01CDD9EB.D3CE0A50-- From SChokhani@cygnacom.com Fri Dec 14 11:18:10 2012 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 CAC7B21F8732 for ; Fri, 14 Dec 2012 11:18:10 -0800 (PST) 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.001, 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 aIYeJ6V8-2-K for ; Fri, 14 Dec 2012 11:18:10 -0800 (PST) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 074F721F8501 for ; Fri, 14 Dec 2012 11:18:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,282,1355115600"; d="scan'208";a="7195293" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 14 Dec 2012 14:18:09 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 14 Dec 2012 14:18:08 -0500 From: Santosh Chokhani To: "Kemp, David P." , "pkix@ietf.org" Date: Fri, 14 Dec 2012 14:18:08 -0500 Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: Ac3aHP2+k1UCZ+fYR0SXQqG7rwstYAAAsvTgAAxXIoAACjLvMAASmViw Message-ID: References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <5B1D7E570380A64989D4C069F7D14BC850AF8D4D@clavin.missi.ncsc.mil> <044601cdda27$3e67eb70$bb37c250$@ditenity.com> <5B1D7E570380A64989D4C069F7D14BC850AF8DB1@clavin.missi.ncsc.mil> In-Reply-To: <5B1D7E570380A64989D4C069F7D14BC850AF8DB1@clavin.missi.ncsc.mil> 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] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 19:18:10 -0000 Dave, What DN are you talking about? If the Responder has the CRL, it has the is= suer DN. It verifies the signature on the CRL using the issuer public key = which it obtains using any proper means (say a certificate). I do not see any other data required for request or response that Responder= needs. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Kem= p, David P. Sent: Friday, December 14, 2012 2:11 PM To: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequenti= al ones in x.509 certificates From: Piyush Jain [mailto:piyush@ditenity.com]=20 > If the only way to retrieve a certificate from a directory or web=20 > repository is to know its name or serial number, then making valid=20 > S/Ns difficult to guess makes trawling more difficult and easier to=20 > detect. =20 [Piyush] Are there such mechanisms in place for securing access to the dire= ctory? Can't you achieve the same by using a combination of serial and some= other cert attribute such as CN? Sure, but why bother. It isn't difficult for a CA to generate random (or "= random-ish", as with AKI/SKI) serial numbers, and doing so mitigates both t= he weak hash security issue and the serial-only privacy issue. IMO it's a = generic good practice just like "don't use a key for more than one purpose"= . Following good practices can head off problems that haven't been thought= of yet. As for Sam's pre-signed OCSP question, I'm not sure how an OCSP responder c= ould pre-sign responses solely from a CRL without also having either a conn= ection to the CA or a list of issued certs. Where do the DN's in the respo= nses come from if the only information available to the signer is a CRL? I= f the issued list isn't updated fast enough, then update it faster :-). _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From piyush@ditenity.com Fri Dec 14 11:46:45 2012 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 89A2121F8A4D for ; Fri, 14 Dec 2012 11:46:45 -0800 (PST) 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 qdnp2PYCP9JU for ; Fri, 14 Dec 2012 11:46:44 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 643D721F8901 for ; Fri, 14 Dec 2012 11:46:44 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6567392ieb.31 for ; Fri, 14 Dec 2012 11:46:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=p+8OCMdJSTQ04i4/CWjyh0LXd/riibcGh7wiThD6+2Q=; b=SQtELhXmDoSzqyZ9tT5zf9N6gpgCcb1kGQIEym8grjUHPU/ypkho2fc6gSPHfZm8qE mW1mESyneG5Ld7R4ettHyisCoRUlvRXCpAmMlKGrw6Q9FseBgtUgyiJ+bZso8guJ/oHV NCeAbGfvDP0tXlzY1n+mzFHsGJ6z+JA3NYN90A8sLUADVECUV3wHi9yMWdADgTTmLXoh TbwNA0biJq/w/2ugeZA6bs/ADc3lby4Z3Z570+9bv/66wCONc5xLzHNZmAKuSvZVXzRP tlGSPpDKZ8Fq/UeiD5bdUoXh9IV6sxJ4CW0SXhJLUCKlnMugmHWq7St+IR1/SbWzeWrB Ph1Q== Received: by 10.50.0.193 with SMTP id 1mr2894323igg.0.1355514403736; Fri, 14 Dec 2012 11:46:43 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id vq4sm7426140igb.10.2012.12.14.11.46.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 11:46:42 -0800 (PST) From: "Piyush Jain" To: "'Santosh Chokhani'" , "'Erwann Abalea'" References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <043901cdda25$78442770$68cc7650$@ditenity.com> <049301cdda28$ad6c8610$08459230$@ditenity.com> In-Reply-To: Date: Fri, 14 Dec 2012 11:46:37 -0800 Message-ID: <04f301cdda33$bbae9320$330bb960$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04F4_01CDD9F0.AD8E6060" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHRlKs7YuWAK+X+fx67nstxV6bEfQEe1CSNAnL+QMUButfRpQLAVWwGAbGamd6Xw0AJkA== Content-Language: en-us X-Gm-Message-State: ALoCoQnSN8336en9Sa/GmRqJODTp3/uRqC+FYjlYZ+L4RFEALDXEE8EOBKvOWtVx0qkMMgkWYCGL Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 19:46:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04F4_01CDD9F0.AD8E6060 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks a lot Santosh. This clarifies things. =20 My assumption was that the attack happens after the certificate is = issued.=20 The attacker looks at the certificate and tries to forge a certificate = with same hash by inserting an irrelevant extension and changing its = contents. =20 So based on what you are saying, Is it correct to say that finding a = prefix p1 such that Hash (m1) =3D Hash(m2+p1) is computationally much = harder than finding prefixes p1 and p2 such that Hash(m1+p1) =3D = Hash(m2+p2). =20 -Piyush =20 =20 =20 From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 Sent: Friday, December 14, 2012 11:04 AM To: Piyush Jain; 'Erwann Abalea' Cc: pkix@ietf.org Subject: RE: [pkix] Questioning the benefit of random serials over = sequential ones in x.509 certificates =20 Piyush, =20 This requires understanding what a collision attack is. In = layperson=E2=80=99s terms, the adversary who is a legitimate applicant = for a certificate, creates names and keys such when the CA signs a = certificate, the hash will be the same as the adversary has created = collision for while submitting the request. Now the adversary can = present the other certificate with basic constraint extension, with = different name, or with different policies as issued by the CA. In this = process, the adversary while computing the collision needs to know the = likely serial number the CA will assign, among other things. Randomizing = serial number is one way of defeating the attack. Putting randomness is = not after is another. Randomness needs to come before Subject DN since = that is the most likely first input from the attacker when you scan the = certificate. My favorite is the parameter field in signature field = since it is not supposed to be used. But, I am afraid it is not = practical since it will freak out most applications. =20 =20 From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Piyush Jain Sent: Friday, December 14, 2012 1:27 PM To: 'Erwann Abalea' Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over = sequential ones in x.509 certificates =20 May be I am missing something very basic. If the certificate is available to the attacker, how does random serial = help avoid a prefix collision attack. =20 The attacker just forges another certificate with same serial and keeps = on changing an extension with random value to force a hash collision. Whether the serial in the certificate is random or not should not have = any impact on the above process. =20 -Piyush =20 =20 From: Erwann Abalea [mailto:eabalea@gmail.com]=20 Sent: Friday, December 14, 2012 10:17 AM To: Piyush Jain Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over = sequential ones in x.509 certificates =20 =20 2012/12/14 Piyush Jain I=E2=80=99m not sure what value does a root CA gets out of this. =20 When mentioning root programs, I'm talking about root inclusion into = public software (browsers, mainly), not certificates issued by the root = CA. The "random serial" requirement is to be applied to CA software that = issue end-user certificates. =20 Since the intermediate certificates (issued by root) are also publicly = visible, it does not matter if the serial is random or not. =20 This has nothing to do with secretly issued certificates, but with known = prefix collision attacks. =20 Isn=E2=80=99t it true that this works only if the attacker does not have = access to the issued certificate? Assuming the PK certificates are not public is sort of = counter-intuitive. =20 I'm not sure I'm following you. A certificate is a public object, for sure. I can't imagine what could be the use of a CA software accepting = certificate requests but refusing access to the issued certificate. =20 From: Erwann Abalea [mailto:eabalea@gmail.com]=20 Sent: Friday, December 14, 2012 9:26 AM To: Piyush Jain Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over = sequential ones in x.509 certificates =20 Bonjour, 2012/12/14 Piyush Jain It seems that the current best practice is to use non-sequential serial numbers when issuing x.509 certificates. =20 That's not only a "best practice", but also a requirement for several = root programs. =20 I understand that it had some value when weak hashing algorithms were = being used to create the signature. =20 It still has some value, because weak hash functions are still used in a = signature context. SHA1 isn't over. =20 But if you are using a strong hashing algorithm, what is the benefit of issuing certificates with random serial values? =20 I don't see any benefit in such a situation. =20 --=20 Erwann. =20 --=20 Erwann. ------=_NextPart_000_04F4_01CDD9F0.AD8E6060 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks a lot Santosh. This clarifies things.

 

My assumption was that the attack happens after the certificate is = issued.

The attacker looks at the certificate and tries to forge a = certificate with same hash by inserting an irrelevant extension and = changing its contents.

 

So based on what you are saying, Is it correct to say that finding a = prefix p1 such that Hash (m1) =3D Hash(m2+p1) is computationally much = harder than finding prefixes p1 and p2 such that Hash(m1+p1) =3D = Hash(m2+p2).

 

-Piyush

 

 

 

From:= = Santosh Chokhani [mailto:SChokhani@cygnacom.com]
Sent: = Friday, December 14, 2012 11:04 AM
To: Piyush Jain; 'Erwann = Abalea'
Cc: pkix@ietf.org
Subject: RE: [pkix] = Questioning the benefit of random serials over sequential ones in x.509 = certificates

 

= Piyush,

=  

= This requires understanding what a collision attack is.  In = layperson=E2=80=99s terms, the adversary who is a legitimate applicant = for a certificate,  creates names and keys such when the CA signs a = certificate, the hash will be the same as the adversary has created = collision for while submitting the request.  Now the adversary can = present the other certificate with basic constraint extension, with = different name, or with different policies as issued by the CA.  In = this process, the adversary while computing the collision needs to know = the likely serial number the CA will assign, among other things. = Randomizing serial number is one way of defeating the attack.  = Putting randomness is not after is another.  Randomness needs to = come before Subject DN since that is the most likely first input from = the attacker when you scan the certificate.  My favorite is the = parameter field in signature field since it is not supposed to be = used.  But, I am afraid it is not practical since it will freak out = most applications.

=  

=  

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.= org] On Behalf Of Piyush Jain
Sent: Friday, = December 14, 2012 1:27 PM
To: 'Erwann Abalea'
Cc: pkix@ietf.org
Subject: Re: = [pkix] Questioning the benefit of random serials over sequential ones in = x.509 certificates

 

May be I am missing something very basic.

If the certificate is available to the attacker, how does random = serial help avoid a prefix collision attack.

 

The attacker just forges another certificate with same serial and = keeps on changing an extension with random value to force a hash = collision.

Whether the serial in the certificate is random or not should not = have any impact on the above process.

 

-Piyush

 

 

From:= = Erwann Abalea [mailto:eabalea@gmail.com] =
Sent: Friday, December 14, 2012 10:17 AM
To: Piyush = Jain
Cc: pkix@ietf.org
Subject: Re: = [pkix] Questioning the benefit of random serials over sequential ones in = x.509 certificates

 

 

2012/12/14 Piyush Jain <piyush@ditenity.com>

I=E2=80=99m not sure what value does a root CA gets out of = this.

 

When mentioning root programs, I'm talking about root = inclusion into public software (browsers, mainly), not certificates = issued by the root CA. The "random serial" requirement is to = be applied to CA software that issue end-user = certificates.

 

Since the intermediate certificates (issued by root) are also = publicly visible, it does not matter if the serial is random or = not.

 

This has nothing to do with secretly issued = certificates, but with known prefix collision = attacks.

 

Isn=E2=80=99t it true that this works only if the attacker does not = have access to the issued certificate?

Assuming the PK certificates are not public is sort of = counter-intuitive.

 

I'm not sure I'm following = you.

A certificate is a = public object, for sure.

I = can't imagine what could be the use of a CA software accepting = certificate requests but refusing access to the issued = certificate.

 

From:= = Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, = December 14, 2012 9:26 AM
To: Piyush Jain
Cc: pkix@ietf.org
Subject: Re: [pkix] = Questioning the benefit of random serials over sequential ones in x.509 = certificates

 <= /o:p>

Bonjour,

2012/12/14 = Piyush Jain <piyush@ditenity.com>

It seems = that the current best practice is to use non-sequential = serial
numbers when issuing x.509 certificates.

 <= /o:p>

That's not = only a "best practice", but also a requirement for several = root programs.

 <= /o:p>

I = understand that it had some value when weak hashing algorithms were = being
used to create the = signature.

 <= /o:p>

It still = has some value, because weak hash functions are still used in a = signature context. SHA1 isn't over.

 <= /o:p>

But if you = are using a strong hashing algorithm, what is the benefit of
issuing = certificates with random serial = values?

 <= /o:p>

I don't see = any benefit in such a situation.

 <= /o:p>

-- =
Erwann.



 

-- =
Erwann.

------=_NextPart_000_04F4_01CDD9F0.AD8E6060-- From eabalea@gmail.com Fri Dec 14 11:52:52 2012 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 10B6421F8B4B for ; Fri, 14 Dec 2012 11:52:52 -0800 (PST) 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 bV3Z1YrWWnvL for ; Fri, 14 Dec 2012 11:52:51 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F03AA21F8B2F for ; Fri, 14 Dec 2012 11:52:44 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3118555lbk.31 for ; Fri, 14 Dec 2012 11:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+XaFqmH5igw+BHp10YAlHPp4eiaiHqovD8etcOP61HA=; b=TbG58KSkyXB/eDUjcDbGglbo3LjOZeZHvgyFNYgT6B1KdQiEwld4LomgaTZwPJiILE Psgd7eWEtOWQG71qtM9zKUV5WR2Tn553y9/QQGkCpV/C6KhTwbKssI/xul26Wb4FNXXj IoWsQZkeh7HiL9lXRaHTWxQEskRq3ZbsTrwXNim76zKJgjzx4reuCosuPA0q0Plyp400 cO1NRbGLwFBxHfW4+I2UA8IwgrBfbDvrFIAtFJaP/EkmA0DGpw/8Cd8KHbMFyMvtzeZR 4us1uZnG/ifYYhFw7/iFkAxKPxEV5hA5m3EgekehfOMAsIWr+At+LgUKDFhPlJh6KsFS LUDg== MIME-Version: 1.0 Received: by 10.152.129.197 with SMTP id ny5mr3705113lab.43.1355514763625; Fri, 14 Dec 2012 11:52:43 -0800 (PST) Received: by 10.114.17.167 with HTTP; Fri, 14 Dec 2012 11:52:43 -0800 (PST) In-Reply-To: <04f301cdda33$bbae9320$330bb960$@ditenity.com> References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <043901cdda25$78442770$68cc7650$@ditenity.com> <049301cdda28$ad6c8610$08459230$@ditenity.com> <04f301cdda33$bbae9320$330bb960$@ditenity.com> Date: Fri, 14 Dec 2012 20:52:43 +0100 Message-ID: From: Erwann Abalea To: Piyush Jain Content-Type: multipart/alternative; boundary=f46d04308570f9454104d0d55f62 Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 19:52:52 -0000 --f46d04308570f9454104d0d55f62 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2012/12/14 Piyush Jain > Thanks a lot Santosh. This clarifies things.**** > > ** ** > > My assumption was that the attack happens after the certificate is issued= . > **** > > The attacker looks at the certificate and tries to forge a certificate > with same hash by inserting an irrelevant extension and changing its > contents. > That's not a collision attack, but a second preimage attack. MD5 is still resistant to this. **** > > So based on what you are saying, Is it correct to say that finding a > prefix p1 such that Hash (m1) =3D Hash(m2+p1) is computationally much har= der > than finding prefixes p1 and p2 such that Hash(m1+p1) =3D Hash(m2+p2). > > ** > p1 is not a prefix but a postfix here. H(m1)=3DH(m1||p1) won't work here because of the structure of a certificate (DER, encoded lengths, etc). It could work for other types of signed objects. H(m1||p1)=3DH(m2||p2) is a collision attack. Just replace it with H(n1)=3DH= (n2). > *From:* Santosh Chokhani [mailto:SChokhani@cygnacom.com] > *Sent:* Friday, December 14, 2012 11:04 AM > *To:* Piyush Jain; 'Erwann Abalea' > *Cc:* pkix@ietf.org > *Subject:* RE: [pkix] Questioning the benefit of random serials over > sequential ones in x.509 certificates**** > > ** ** > > Piyush,**** > > ** ** > > This requires understanding what a collision attack is. In layperson=E2= =80=99s > terms, the adversary who is a legitimate applicant for a certificate, > creates names and keys such when the CA signs a certificate, the hash wi= ll > be the same as the adversary has created collision for while submitting t= he > request. Now the adversary can present the other certificate with basic > constraint extension, with different name, or with different policies as > issued by the CA. In this process, the adversary while computing the > collision needs to know the likely serial number the CA will assign, amon= g > other things. Randomizing serial number is one way of defeating the > attack. Putting randomness is not after is another. Randomness needs to > come before Subject DN since that is the most likely first input from the > attacker when you scan the certificate. My favorite is the parameter fie= ld > in signature field since it is not supposed to be used. But, I am afraid > it is not practical since it will freak out most applications.**** > > ** ** > > ** ** > > *From:* pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] *On Behalf > Of *Piyush Jain > *Sent:* Friday, December 14, 2012 1:27 PM > *To:* 'Erwann Abalea' > *Cc:* pkix@ietf.org > *Subject:* Re: [pkix] Questioning the benefit of random serials over > sequential ones in x.509 certificates**** > > ** ** > > May be I am missing something very basic.**** > > If the certificate is available to the attacker, how does random serial > help avoid a prefix collision attack.**** > > ** ** > > The attacker just forges another certificate with same serial and keeps o= n > changing an extension with random value to force a hash collision.**** > > Whether the serial in the certificate is random or not should not have an= y > impact on the above process.**** > > ** ** > > -Piyush**** > > ** ** > > ** ** > > *From:* Erwann Abalea [mailto:eabalea@gmail.com ] > *Sent:* Friday, December 14, 2012 10:17 AM > *To:* Piyush Jain > *Cc:* pkix@ietf.org > *Subject:* Re: [pkix] Questioning the benefit of random serials over > sequential ones in x.509 certificates**** > > ** ** > > ** ** > > 2012/12/14 Piyush Jain **** > > I=E2=80=99m not sure what value does a root CA gets out of this.**** > > ** ** > > When mentioning root programs, I'm talking about root inclusion into > public software (browsers, mainly), not certificates issued by the root C= A. > The "random serial" requirement is to be applied to CA software that issu= e > end-user certificates.**** > > **** > > Since the intermediate certificates (issued by root) are also publicly > visible, it does not matter if the serial is random or not.**** > > ** ** > > This has nothing to do with secretly issued certificates, but with known > prefix collision attacks.**** > > **** > > Isn=E2=80=99t it true that this works only if the attacker does not have = access to > the issued certificate?**** > > Assuming the PK certificates are not public is sort of counter-intuitive.= * > *** > > ** ** > > I'm not sure I'm following you.**** > > A certificate is a public object, for sure.**** > > I can't imagine what could be the use of a CA software accepting > certificate requests but refusing access to the issued certificate.**** > > ** ** > > *From:* Erwann Abalea [mailto:eabalea@gmail.com] > *Sent:* Friday, December 14, 2012 9:26 AM > *To:* Piyush Jain > *Cc:* pkix@ietf.org > *Subject:* Re: [pkix] Questioning the benefit of random serials over > sequential ones in x.509 certificates**** > > **** > > Bonjour,**** > > 2012/12/14 Piyush Jain **** > > It seems that the current best practice is to use non-sequential serial > numbers when issuing x.509 certificates.**** > > **** > > That's not only a "best practice", but also a requirement for several roo= t > programs.**** > > **** > > I understand that it had some value when weak hashing algorithms were bei= ng > used to create the signature.**** > > **** > > It still has some value, because weak hash functions are still used in a > signature context. SHA1 isn't over.**** > > **** > > But if you are using a strong hashing algorithm, what is the benefit of > issuing certificates with random serial values?**** > > **** > > I don't see any benefit in such a situation.**** > > **** > > -- > Erwann.**** > > > > **** > > ** ** > > -- > Erwann.**** > --=20 Erwann. --f46d04308570f9454104d0d55f62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2012/12/14 Piyush Jain <= ;piyush@ditenity.c= om>

Thanks a lot Santosh. This clarifies things.=

=C2=A0

My assumption was t= hat the attack happens after the certificate is issued.

The attacker looks at the= certificate and tries to forge a certificate with same hash by inserting a= n irrelevant extension and changing its contents.


That's not a collision att= ack, but a second preimage attack. MD5 is still resistant to this.

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">

<= span style=3D"color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size= :11pt">So based on what you are saying, Is it correct to say that finding a= prefix p1 such that Hash (m1) =3D Hash(m2+p1) is computationally much hard= er than finding prefixes p1 and p2 such that Hash(m1+p1) =3D Hash(m2+p2).

<= /blockquote>

p1 is not a prefix but a postfix here.

H(m1)=3DH(m1||p1) won't work here because of the st= ructure of a certificate (DER, encoded lengths, etc). It could work for oth= er types of signed objects.

H(m1||p1)=3DH(m2||p2) = is a collision attack. Just replace it with H(n1)=3DH(n2).
=C2=A0

From:= Santosh Chokhani [mailto:SChokhani@cygnacom.com]
Sent: Friday, December 14, 2012 11:04 AM
To: Piyush Jain; = 'Erwann Abalea'
Cc: pkix@ietf.org
Subject: RE: [pkix] Questioning t= he benefit of random serials over sequential ones in x.509 certificates<= /u>

=C2=A0<= /u>

Piyush,=

=C2=A0<= /p>

This requires understandi= ng what a collision attack is.=C2=A0 In layperson=E2=80=99s terms, the adve= rsary who is a legitimate applicant for a certificate, =C2=A0creates names = and keys such when the CA signs a certificate, the hash will be the same as= the adversary has created collision for while submitting the request.=C2= =A0 Now the adversary can present the other certificate with basic constrai= nt extension, with different name, or with different policies as issued by = the CA.=C2=A0 In this process, the adversary while computing the collision = needs to know the likely serial number the CA will assign, among other thin= gs. Randomizing serial number is one way of defeating the attack.=C2=A0 Put= ting randomness is not after is another.=C2=A0 Randomness needs to come bef= ore Subject DN since that is the most likely first input from the attacker = when you scan the certificate.=C2=A0 My favorite is the parameter field in = signature field since it is not supposed to be used.=C2=A0 But, I am afraid= it is not practical since it will freak out most applications.

=C2=A0<= /p>

=C2=A0

From: pkix-bounc= es@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piyush Jain=
Sent: Friday, December 14, 2012 1:27 PM
To: 'Erwann Ab= alea'
Cc: = pkix@ietf.org
Subject: Re: [pkix] Questioning the benefit of = random serials over sequential ones in x.509 certificates

=C2=A0

May be I am missing something very basic.=

If the certificate is ava= ilable to the attacker, how does random serial help avoid a prefix collisio= n attack.

=C2=A0

The attacker just f= orges another certificate with same serial and keeps on changing an extensi= on with random value to force a hash collision.

Whether the serial in the= certificate is random or not should not have any impact on the above proce= ss.

=C2=A0

-Piyush

=C2=A0

=C2=A0

From:= Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, December 14, 2012 10:17 AM
To: Piyush JainCc: pkix@ietf.o= rg
Subject: Re: [pkix] Questioning the benefit of random seri= als over sequential ones in x.509 certificates

=C2=A0

=C2=A0

2012/12/14 Piyus= h Jain <piyush@= ditenity.com>

I=E2=80=99m not sure= what value does a root CA gets out of this.

=

=C2=A0

When mentioning r= oot programs, I'm talking about root inclusion into public software (br= owsers, mainly), not certificates issued by the root CA. The "random s= erial" requirement is to be applied to CA software that issue end-user= certificates.

=C2=A0

Since the intermedia= te certificates (issued by root) are also publicly visible, it does not mat= ter if the serial is random or not.

=C2=A0

This has nothing to do with secretly is= sued certificates, but with known prefix collision attacks.

=C2=A0

Isn=E2=80=99t it true that this works only if th= e attacker does not have access to the issued certificate?=

Assuming the PK certifica= tes are not public is sort of counter-intuitive.

=C2=A0

I'm not sure I'm following you.

A certificate is a public object, f= or sure.

I can't imagine what could be the use= of a CA software accepting certificate requests but refusing access to the= issued certificate.

= =C2=A0

From: Erwann Abalea [mailto:eabalea@gmail.com]
Sent: Friday, December 14, 2012 9:26 AM
To: Piyush JainCc: pkix@ietf.or= g
Subject: Re: [pkix] Questioning the benefit of random seria= ls over sequential ones in x.509 certificates

=C2=A0

Bonjour,

<= div>

2012/12/14 Piyush Jain <piyush@ditenity.com>

It seems that the current best practice is to use no= n-sequential serial
numbers when issuing x.509 certificates.

=C2=A0

That's not only a "best practice", but also a requirement for= several root programs.

= =C2=A0

I understand that it had some value when weak hashin= g algorithms were being
used to create the signature.

<= /blockquote>

=C2=A0

=

It still has some value, because weak hash functions are still used in a si= gnature context. SHA1 isn't over.

=C2=A0

But if you are using a strong hashing algorithm, wha= t is the benefit of
issuing certificates with random serial values?

=C2=A0<= /p>

I don't see any benefit in such a situation= .

=C2=A0

--
Erwann.

=



=C2=A0

--
Erwann.

=



--
Erwann.
--f46d04308570f9454104d0d55f62-- From DPKemp@missi.ncsc.mil Fri Dec 14 11:54:25 2012 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 CD18521F8B2D for ; Fri, 14 Dec 2012 11:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0B8HVGtXaFa for ; Fri, 14 Dec 2012 11:54:25 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 43BA421F88E7 for ; Fri, 14 Dec 2012 11:54:25 -0800 (PST) Received: from clavin.missi.ncsc.mil (clavin.missi.ncsc.mil [144.51.60.17]) by stingray.missi.ncsc.mil with ESMTP id qBEJsO23037146 for ; Fri, 14 Dec 2012 14:54:24 -0500 (EST) Received: from clavin.missi.ncsc.mil ([169.254.1.149]) by clavin.missi.ncsc.mil ([169.254.1.149]) with mapi id 14.01.0421.002; Fri, 14 Dec 2012 14:54:23 -0500 From: "Kemp, David P." To: "pkix@ietf.org" Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: Ac3aHP2+k1UCZ+fYR0SXQqG7rwstYAAAsvTgAAxXIoAACjLvMAASmViwACUGShA= Date: Fri, 14 Dec 2012 19:53:40 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC850AF8E18@clavin.missi.ncsc.mil> References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <5B1D7E570380A64989D4C069F7D14BC850AF8D4D@clavin.missi.ncsc.mil> <044601cdda27$3e67eb70$bb37c250$@ditenity.com> <5B1D7E570380A64989D4C069F7D14BC850AF8DB1@clavin.missi.ncsc.mil> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.54.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 19:54:25 -0000 Santosh, You are correct. For some reason my old brain got the idea that OCSP reque= sts and responses contained subject DNs. I have no clue where that came fr= om, since: CertID ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key serialNumber CertificateSerialNumber } As Roseanne Rosannadanna said, "never mind". However, a list of issued CertificateSerialNumber's could be distributed to= OCSP responders that don't have a direct CA connection, in addition to CRL= s. That is an added complication, but hardly an engineering challenge. Dave -----Original Message----- From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 Sent: Friday, December 14, 2012 2:18 PM To: Kemp, David P.; pkix@ietf.org Subject: RE: [pkix] Questioning the benefit of random serials over sequenti= al ones in x.509 certificates Dave, What DN are you talking about? If the Responder has the CRL, it has the is= suer DN. It verifies the signature on the CRL using the issuer public key = which it obtains using any proper means (say a certificate). I do not see any other data required for request or response that Responder= needs. From piyush@ditenity.com Fri Dec 14 11:55:10 2012 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 A60F321F8B62 for ; Fri, 14 Dec 2012 11:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 GD6bVXKlaLIA for ; Fri, 14 Dec 2012 11:55:09 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 379EE21F8B5A for ; Fri, 14 Dec 2012 11:55:09 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6580395ieb.31 for ; Fri, 14 Dec 2012 11:55:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=GfdQHPXb2MqvjhhMSrF+8p6ZcvWUPSxm10xV6tGjTAg=; b=FvSUXScnU3LxZD3w60379YG/kIFlfTPDIMAm5qEd21ByJ0LVIWwjj6haSIHgty+hM2 lT2h1NqjhFU3nnPKF40BEo2TavRfruWS1Vo4kqapLxzInAL6RCmey+kKT3NQJy5wveA+ 2yZfwehtvxsiuK402+h38T3eEqS57FcKkLwk4RpAupdqFA5cVmZf9avgozOt80EWE4SK +SX3YgSjZL7omxI+1wjzKFaBdajDwmz7UMJTE8F7sBoYq/ukDp/HHACZtuTikwS4m8MI gusxZfOz19gh30+IVjTY8TblVXeAJMtHcssMnpP2ROCucfscahryhE4x/MYK5q2tMTWQ 8I7Q== X-Received: by 10.50.220.166 with SMTP id px6mr2776964igc.8.1355514908874; Fri, 14 Dec 2012 11:55:08 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id fv6sm7424022igc.17.2012.12.14.11.55.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 11:55:08 -0800 (PST) From: "Piyush Jain" To: "'Kemp, David P.'" , References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <5B1D7E570380A64989D4C069F7D14BC850AF8D4D@clavin.missi.ncsc.mil> <044601cdda27$3e67eb70$bb37c250$@ditenity.com> <5B1D7E570380A64989D4C069F7D14BC850AF8DB1@clavin.missi.ncsc.mil> In-Reply-To: <5B1D7E570380A64989D4C069F7D14BC850AF8DB1@clavin.missi.ncsc.mil> Date: Fri, 14 Dec 2012 11:55:04 -0800 Message-ID: <056f01cdda34$ea18a290$be49e7b0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHRlKs7YuWAK+X+fx67nstxV6bEfQHPydwdAhn5wasCEB4PDpfhb0Gg Content-Language: en-us X-Gm-Message-State: ALoCoQnMIUq7HN6BHLR+3giuRtEepHaqVA/mHvnidJwirgmJb0d7URw5xgew/glhGwX7NMspP2ui Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 19:55:10 -0000 Actually the pre-signing model that Sam referred to is heavily deployed in enterprises. The responder computes the namehash (or keyhash) from the CA certificate. Revoked response is generated for serials in the CRL and good for everything that is not in the CRL. Assumption about the range of issued serials is made by looking at the smallest and the largest serial in the CRL. > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Kemp, David P. > Sent: Friday, December 14, 2012 11:11 AM > To: pkix@ietf.org > Subject: Re: [pkix] Questioning the benefit of random serials over sequential > ones in x.509 certificates > > From: Piyush Jain [mailto:piyush@ditenity.com] > > > If the only way to retrieve a certificate from a directory or web > > repository is to know its name or serial number, then making valid > > S/Ns difficult to guess makes trawling more difficult and easier to > > detect. > > [Piyush] Are there such mechanisms in place for securing access to the > directory? Can't you achieve the same by using a combination of serial and > some other cert attribute such as CN? > > Sure, but why bother. It isn't difficult for a CA to generate random (or > "random-ish", as with AKI/SKI) serial numbers, and doing so mitigates both > the weak hash security issue and the serial-only privacy issue. IMO it's a > generic good practice just like "don't use a key for more than one purpose". > Following good practices can head off problems that haven't been thought of > yet. > > As for Sam's pre-signed OCSP question, I'm not sure how an OCSP responder > could pre-sign responses solely from a CRL without also having either a > connection to the CA or a list of issued certs. Where do the DN's in the > responses come from if the only information available to the signer is a CRL? > If the issued list isn't updated fast enough, then update it faster :-). > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From SChokhani@cygnacom.com Fri Dec 14 12:03:22 2012 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 B850B21F8AA4 for ; Fri, 14 Dec 2012 12:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 O+7+NdrZkEuT for ; Fri, 14 Dec 2012 12:03:21 -0800 (PST) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 296FF21F8A80 for ; Fri, 14 Dec 2012 12:03:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,284,1355115600"; d="scan'208,217";a="2686171" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 14 Dec 2012 15:03:20 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 14 Dec 2012 15:03:19 -0500 From: Santosh Chokhani To: Piyush Jain , 'Erwann Abalea' Date: Fri, 14 Dec 2012 15:03:18 -0500 Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: AQHRlKs7YuWAK+X+fx67nstxV6bEfQEe1CSNAnL+QMUButfRpQLAVWwGAbGamd6Xw0AJkIAADVjA Message-ID: References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <043901cdda25$78442770$68cc7650$@ditenity.com> <049301cdda28$ad6c8610$08459230$@ditenity.com> <04f301cdda33$bbae9320$330bb960$@ditenity.com> In-Reply-To: <04f301cdda33$bbae9320$330bb960$@ditenity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF3632765Fscygexch7cygnac_" MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 20:03:22 -0000 --_000_B83745DA469B7847811819C5005244AF3632765Fscygexch7cygnac_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGl5dXNoLA0KDQpJIGFtIG5vdCBhIGNyeXB0byBtYXRoZW1hdGljaWFuICBTbywgSSBkbyBub3Qg Y29uc2lkZXIgbXlzZWxmIHF1YWxpZmllZCB0byBhbnN3ZXIgdGhlIHF1ZXN0aW9uIHlvdSBwb3Nl Lg0KDQpJIGNhbiBzYXkgdGhhdCB3aGF0IHlvdSBhc3N1bWVkIGlzIGNhbGxlZCBhIHNlY29uZCBw cmUtaW1hZ2UgYW5kIHdvdWxkIGVudGFpbCBhIHdvcmsgZmFjdG9yIG9uIHRoZSBvcmRlciBvZiBo YXNoIHNpemUuDQoNCkZyb206IFBpeXVzaCBKYWluIFttYWlsdG86cGl5dXNoQGRpdGVuaXR5LmNv bV0NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMTQsIDIwMTIgMjo0NyBQTQ0KVG86IFNhbnRvc2gg Q2hva2hhbmk7ICdFcndhbm4gQWJhbGVhJw0KQ2M6IHBraXhAaWV0Zi5vcmcNClN1YmplY3Q6IFJF OiBbcGtpeF0gUXVlc3Rpb25pbmcgdGhlIGJlbmVmaXQgb2YgcmFuZG9tIHNlcmlhbHMgb3ZlciBz ZXF1ZW50aWFsIG9uZXMgaW4geC41MDkgY2VydGlmaWNhdGVzDQoNClRoYW5rcyBhIGxvdCBTYW50 b3NoLiBUaGlzIGNsYXJpZmllcyB0aGluZ3MuDQoNCk15IGFzc3VtcHRpb24gd2FzIHRoYXQgdGhl IGF0dGFjayBoYXBwZW5zIGFmdGVyIHRoZSBjZXJ0aWZpY2F0ZSBpcyBpc3N1ZWQuDQpUaGUgYXR0 YWNrZXIgbG9va3MgYXQgdGhlIGNlcnRpZmljYXRlIGFuZCB0cmllcyB0byBmb3JnZSBhIGNlcnRp ZmljYXRlIHdpdGggc2FtZSBoYXNoIGJ5IGluc2VydGluZyBhbiBpcnJlbGV2YW50IGV4dGVuc2lv biBhbmQgY2hhbmdpbmcgaXRzIGNvbnRlbnRzLg0KDQpTbyBiYXNlZCBvbiB3aGF0IHlvdSBhcmUg c2F5aW5nLCBJcyBpdCBjb3JyZWN0IHRvIHNheSB0aGF0IGZpbmRpbmcgYSBwcmVmaXggcDEgc3Vj aCB0aGF0IEhhc2ggKG0xKSA9IEhhc2gobTIrcDEpIGlzIGNvbXB1dGF0aW9uYWxseSBtdWNoIGhh cmRlciB0aGFuIGZpbmRpbmcgcHJlZml4ZXMgcDEgYW5kIHAyIHN1Y2ggdGhhdCBIYXNoKG0xK3Ax KSA9IEhhc2gobTIrcDIpLg0KDQotUGl5dXNoDQoNCg0KDQpGcm9tOiBTYW50b3NoIENob2toYW5p IFttYWlsdG86U0Nob2toYW5pQGN5Z25hY29tLmNvbV0NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIg MTQsIDIwMTIgMTE6MDQgQU0NClRvOiBQaXl1c2ggSmFpbjsgJ0Vyd2FubiBBYmFsZWEnDQpDYzog cGtpeEBpZXRmLm9yZzxtYWlsdG86cGtpeEBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbcGtpeF0g UXVlc3Rpb25pbmcgdGhlIGJlbmVmaXQgb2YgcmFuZG9tIHNlcmlhbHMgb3ZlciBzZXF1ZW50aWFs IG9uZXMgaW4geC41MDkgY2VydGlmaWNhdGVzDQoNClBpeXVzaCwNCg0KVGhpcyByZXF1aXJlcyB1 bmRlcnN0YW5kaW5nIHdoYXQgYSBjb2xsaXNpb24gYXR0YWNrIGlzLiAgSW4gbGF5cGVyc29u4oCZ cyB0ZXJtcywgdGhlIGFkdmVyc2FyeSB3aG8gaXMgYSBsZWdpdGltYXRlIGFwcGxpY2FudCBmb3Ig YSBjZXJ0aWZpY2F0ZSwgIGNyZWF0ZXMgbmFtZXMgYW5kIGtleXMgc3VjaCB3aGVuIHRoZSBDQSBz aWducyBhIGNlcnRpZmljYXRlLCB0aGUgaGFzaCB3aWxsIGJlIHRoZSBzYW1lIGFzIHRoZSBhZHZl cnNhcnkgaGFzIGNyZWF0ZWQgY29sbGlzaW9uIGZvciB3aGlsZSBzdWJtaXR0aW5nIHRoZSByZXF1 ZXN0LiAgTm93IHRoZSBhZHZlcnNhcnkgY2FuIHByZXNlbnQgdGhlIG90aGVyIGNlcnRpZmljYXRl IHdpdGggYmFzaWMgY29uc3RyYWludCBleHRlbnNpb24sIHdpdGggZGlmZmVyZW50IG5hbWUsIG9y IHdpdGggZGlmZmVyZW50IHBvbGljaWVzIGFzIGlzc3VlZCBieSB0aGUgQ0EuICBJbiB0aGlzIHBy b2Nlc3MsIHRoZSBhZHZlcnNhcnkgd2hpbGUgY29tcHV0aW5nIHRoZSBjb2xsaXNpb24gbmVlZHMg dG8ga25vdyB0aGUgbGlrZWx5IHNlcmlhbCBudW1iZXIgdGhlIENBIHdpbGwgYXNzaWduLCBhbW9u ZyBvdGhlciB0aGluZ3MuIFJhbmRvbWl6aW5nIHNlcmlhbCBudW1iZXIgaXMgb25lIHdheSBvZiBk ZWZlYXRpbmcgdGhlIGF0dGFjay4gIFB1dHRpbmcgcmFuZG9tbmVzcyBpcyBub3QgYWZ0ZXIgaXMg YW5vdGhlci4gIFJhbmRvbW5lc3MgbmVlZHMgdG8gY29tZSBiZWZvcmUgU3ViamVjdCBETiBzaW5j ZSB0aGF0IGlzIHRoZSBtb3N0IGxpa2VseSBmaXJzdCBpbnB1dCBmcm9tIHRoZSBhdHRhY2tlciB3 aGVuIHlvdSBzY2FuIHRoZSBjZXJ0aWZpY2F0ZS4gIE15IGZhdm9yaXRlIGlzIHRoZSBwYXJhbWV0 ZXIgZmllbGQgaW4gc2lnbmF0dXJlIGZpZWxkIHNpbmNlIGl0IGlzIG5vdCBzdXBwb3NlZCB0byBi ZSB1c2VkLiAgQnV0LCBJIGFtIGFmcmFpZCBpdCBpcyBub3QgcHJhY3RpY2FsIHNpbmNlIGl0IHdp bGwgZnJlYWsgb3V0IG1vc3QgYXBwbGljYXRpb25zLg0KDQoNCkZyb206IHBraXgtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnBraXgtYm91bmNl c0BpZXRmLm9yZ108bWFpbHRvOlttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVo YWxmIE9mIFBpeXVzaCBKYWluDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDE0LCAyMDEyIDE6Mjcg UE0NClRvOiAnRXJ3YW5uIEFiYWxlYScNCkNjOiBwa2l4QGlldGYub3JnPG1haWx0bzpwa2l4QGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtwa2l4XSBRdWVzdGlvbmluZyB0aGUgYmVuZWZpdCBvZiBy YW5kb20gc2VyaWFscyBvdmVyIHNlcXVlbnRpYWwgb25lcyBpbiB4LjUwOSBjZXJ0aWZpY2F0ZXMN Cg0KTWF5IGJlIEkgYW0gbWlzc2luZyBzb21ldGhpbmcgdmVyeSBiYXNpYy4NCklmIHRoZSBjZXJ0 aWZpY2F0ZSBpcyBhdmFpbGFibGUgdG8gdGhlIGF0dGFja2VyLCBob3cgZG9lcyByYW5kb20gc2Vy aWFsIGhlbHAgYXZvaWQgYSBwcmVmaXggY29sbGlzaW9uIGF0dGFjay4NCg0KVGhlIGF0dGFja2Vy IGp1c3QgZm9yZ2VzIGFub3RoZXIgY2VydGlmaWNhdGUgd2l0aCBzYW1lIHNlcmlhbCBhbmQga2Vl cHMgb24gY2hhbmdpbmcgYW4gZXh0ZW5zaW9uIHdpdGggcmFuZG9tIHZhbHVlIHRvIGZvcmNlIGEg aGFzaCBjb2xsaXNpb24uDQpXaGV0aGVyIHRoZSBzZXJpYWwgaW4gdGhlIGNlcnRpZmljYXRlIGlz IHJhbmRvbSBvciBub3Qgc2hvdWxkIG5vdCBoYXZlIGFueSBpbXBhY3Qgb24gdGhlIGFib3ZlIHBy b2Nlc3MuDQoNCi1QaXl1c2gNCg0KDQpGcm9tOiBFcndhbm4gQWJhbGVhIFttYWlsdG86ZWFiYWxl YUBnbWFpbC5jb21dDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDE0LCAyMDEyIDEwOjE3IEFNDQpU bzogUGl5dXNoIEphaW4NCkNjOiBwa2l4QGlldGYub3JnPG1haWx0bzpwa2l4QGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtwa2l4XSBRdWVzdGlvbmluZyB0aGUgYmVuZWZpdCBvZiByYW5kb20gc2Vy aWFscyBvdmVyIHNlcXVlbnRpYWwgb25lcyBpbiB4LjUwOSBjZXJ0aWZpY2F0ZXMNCg0KDQoyMDEy LzEyLzE0IFBpeXVzaCBKYWluIDxwaXl1c2hAZGl0ZW5pdHkuY29tPG1haWx0bzpwaXl1c2hAZGl0 ZW5pdHkuY29tPj4NCknigJltIG5vdCBzdXJlIHdoYXQgdmFsdWUgZG9lcyBhIHJvb3QgQ0EgZ2V0 cyBvdXQgb2YgdGhpcy4NCg0KV2hlbiBtZW50aW9uaW5nIHJvb3QgcHJvZ3JhbXMsIEknbSB0YWxr aW5nIGFib3V0IHJvb3QgaW5jbHVzaW9uIGludG8gcHVibGljIHNvZnR3YXJlIChicm93c2Vycywg bWFpbmx5KSwgbm90IGNlcnRpZmljYXRlcyBpc3N1ZWQgYnkgdGhlIHJvb3QgQ0EuIFRoZSAicmFu ZG9tIHNlcmlhbCIgcmVxdWlyZW1lbnQgaXMgdG8gYmUgYXBwbGllZCB0byBDQSBzb2Z0d2FyZSB0 aGF0IGlzc3VlIGVuZC11c2VyIGNlcnRpZmljYXRlcy4NCg0KU2luY2UgdGhlIGludGVybWVkaWF0 ZSBjZXJ0aWZpY2F0ZXMgKGlzc3VlZCBieSByb290KSBhcmUgYWxzbyBwdWJsaWNseSB2aXNpYmxl LCBpdCBkb2VzIG5vdCBtYXR0ZXIgaWYgdGhlIHNlcmlhbCBpcyByYW5kb20gb3Igbm90Lg0KDQpU aGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggc2VjcmV0bHkgaXNzdWVkIGNlcnRpZmljYXRlcywg YnV0IHdpdGgga25vd24gcHJlZml4IGNvbGxpc2lvbiBhdHRhY2tzLg0KDQpJc27igJl0IGl0IHRy dWUgdGhhdCB0aGlzIHdvcmtzIG9ubHkgaWYgdGhlIGF0dGFja2VyIGRvZXMgbm90IGhhdmUgYWNj ZXNzIHRvIHRoZSBpc3N1ZWQgY2VydGlmaWNhdGU/DQpBc3N1bWluZyB0aGUgUEsgY2VydGlmaWNh dGVzIGFyZSBub3QgcHVibGljIGlzIHNvcnQgb2YgY291bnRlci1pbnR1aXRpdmUuDQoNCkknbSBu b3Qgc3VyZSBJJ20gZm9sbG93aW5nIHlvdS4NCkEgY2VydGlmaWNhdGUgaXMgYSBwdWJsaWMgb2Jq ZWN0LCBmb3Igc3VyZS4NCkkgY2FuJ3QgaW1hZ2luZSB3aGF0IGNvdWxkIGJlIHRoZSB1c2Ugb2Yg YSBDQSBzb2Z0d2FyZSBhY2NlcHRpbmcgY2VydGlmaWNhdGUgcmVxdWVzdHMgYnV0IHJlZnVzaW5n IGFjY2VzcyB0byB0aGUgaXNzdWVkIGNlcnRpZmljYXRlLg0KDQpGcm9tOiBFcndhbm4gQWJhbGVh IFttYWlsdG86ZWFiYWxlYUBnbWFpbC5jb208bWFpbHRvOmVhYmFsZWFAZ21haWwuY29tPl0NClNl bnQ6IEZyaWRheSwgRGVjZW1iZXIgMTQsIDIwMTIgOToyNiBBTQ0KVG86IFBpeXVzaCBKYWluDQpD YzogcGtpeEBpZXRmLm9yZzxtYWlsdG86cGtpeEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcGtp eF0gUXVlc3Rpb25pbmcgdGhlIGJlbmVmaXQgb2YgcmFuZG9tIHNlcmlhbHMgb3ZlciBzZXF1ZW50 aWFsIG9uZXMgaW4geC41MDkgY2VydGlmaWNhdGVzDQoNCkJvbmpvdXIsDQoyMDEyLzEyLzE0IFBp eXVzaCBKYWluIDxwaXl1c2hAZGl0ZW5pdHkuY29tPG1haWx0bzpwaXl1c2hAZGl0ZW5pdHkuY29t Pj4NCkl0IHNlZW1zIHRoYXQgdGhlIGN1cnJlbnQgYmVzdCBwcmFjdGljZSBpcyB0byB1c2Ugbm9u LXNlcXVlbnRpYWwgc2VyaWFsDQpudW1iZXJzIHdoZW4gaXNzdWluZyB4LjUwOSBjZXJ0aWZpY2F0 ZXMuDQoNClRoYXQncyBub3Qgb25seSBhICJiZXN0IHByYWN0aWNlIiwgYnV0IGFsc28gYSByZXF1 aXJlbWVudCBmb3Igc2V2ZXJhbCByb290IHByb2dyYW1zLg0KDQpJIHVuZGVyc3RhbmQgdGhhdCBp dCBoYWQgc29tZSB2YWx1ZSB3aGVuIHdlYWsgaGFzaGluZyBhbGdvcml0aG1zIHdlcmUgYmVpbmcN CnVzZWQgdG8gY3JlYXRlIHRoZSBzaWduYXR1cmUuDQoNCkl0IHN0aWxsIGhhcyBzb21lIHZhbHVl LCBiZWNhdXNlIHdlYWsgaGFzaCBmdW5jdGlvbnMgYXJlIHN0aWxsIHVzZWQgaW4gYSBzaWduYXR1 cmUgY29udGV4dC4gU0hBMSBpc24ndCBvdmVyLg0KDQpCdXQgaWYgeW91IGFyZSB1c2luZyBhIHN0 cm9uZyBoYXNoaW5nIGFsZ29yaXRobSwgd2hhdCBpcyB0aGUgYmVuZWZpdCBvZg0KaXNzdWluZyBj ZXJ0aWZpY2F0ZXMgd2l0aCByYW5kb20gc2VyaWFsIHZhbHVlcz8NCg0KSSBkb24ndCBzZWUgYW55 IGJlbmVmaXQgaW4gc3VjaCBhIHNpdHVhdGlvbi4NCg0KLS0NCkVyd2Fubi4NCg0KDQoNCi0tDQpF cndhbm4uDQo= --_000_B83745DA469B7847811819C5005244AF3632765Fscygexch7cygnac_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJ dGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5 IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9u MT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QaXl1c2gsPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5JIGFtIG5vdCBhIGNyeXB0byBtYXRoZW1hdGljaWFuIMKgU28sIEkgZG8gbm90IGNvbnNp ZGVyIG15c2VsZiBxdWFsaWZpZWQgdG8gYW5zd2VyIHRoZSBxdWVzdGlvbiB5b3UgcG9zZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkkgY2FuIHNheSB0aGF0IHdoYXQgeW91IGFzc3VtZWQgaXMgY2FsbGVkIGEgc2Vj b25kIHByZS1pbWFnZSBhbmQgd291bGQgZW50YWlsIGEgd29yayBmYWN0b3Igb24gdGhlIG9yZGVy IG9mIGhhc2ggc2l6ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBz dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPiBQaXl1c2ggSmFpbiBbbWFpbHRvOnBpeXVzaEBkaXRlbml0eS5jb21d IDxicj48Yj5TZW50OjwvYj4gRnJpZGF5LCBEZWNlbWJlciAxNCwgMjAxMiAyOjQ3IFBNPGJyPjxi PlRvOjwvYj4gU2FudG9zaCBDaG9raGFuaTsgJ0Vyd2FubiBBYmFsZWEnPGJyPjxiPkNjOjwvYj4g cGtpeEBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IFtwa2l4XSBRdWVzdGlvbmluZyB0 aGUgYmVuZWZpdCBvZiByYW5kb20gc2VyaWFscyBvdmVyIHNlcXVlbnRpYWwgb25lcyBpbiB4LjUw OSBjZXJ0aWZpY2F0ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPlRoYW5rcyBhIGxvdCBTYW50b3NoLiBUaGlzIGNsYXJpZmllcyB0aGlu Z3MuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5NeSBhc3N1bXB0aW9uIHdhcyB0aGF0IHRoZSBhdHRhY2sg aGFwcGVucyBhZnRlciB0aGUgY2VydGlmaWNhdGUgaXMgaXNzdWVkLiA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIGF0dGFj a2VyIGxvb2tzIGF0IHRoZSBjZXJ0aWZpY2F0ZSBhbmQgdHJpZXMgdG8gZm9yZ2UgYSBjZXJ0aWZp Y2F0ZSB3aXRoIHNhbWUgaGFzaCBieSBpbnNlcnRpbmcgYW4gaXJyZWxldmFudCBleHRlbnNpb24g YW5kIGNoYW5naW5nIGl0cyBjb250ZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNvIGJhc2VkIG9u IHdoYXQgeW91IGFyZSBzYXlpbmcsIElzIGl0IGNvcnJlY3QgdG8gc2F5IHRoYXQgZmluZGluZyBh IHByZWZpeCBwMSBzdWNoIHRoYXQgSGFzaCAobTEpID0gSGFzaChtMitwMSkgaXMgY29tcHV0YXRp b25hbGx5IG11Y2ggaGFyZGVyIHRoYW4gZmluZGluZyBwcmVmaXhlcyBwMSBhbmQgcDIgc3VjaCB0 aGF0IEhhc2gobTErcDEpID0gSGFzaChtMitwMikuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tUGl5dXNo PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+ PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFNh bnRvc2ggQ2hva2hhbmkgWzxhIGhyZWY9Im1haWx0bzpTQ2hva2hhbmlAY3lnbmFjb20uY29tIj5t YWlsdG86U0Nob2toYW5pQGN5Z25hY29tLmNvbTwvYT5dIDxicj48Yj5TZW50OjwvYj4gRnJpZGF5 LCBEZWNlbWJlciAxNCwgMjAxMiAxMTowNCBBTTxicj48Yj5Ubzo8L2I+IFBpeXVzaCBKYWluOyAn RXJ3YW5uIEFiYWxlYSc8YnI+PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cGtpeEBpZXRmLm9y ZyI+cGtpeEBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBbcGtpeF0gUXVlc3Rp b25pbmcgdGhlIGJlbmVmaXQgb2YgcmFuZG9tIHNlcmlhbHMgb3ZlciBzZXF1ZW50aWFsIG9uZXMg aW4geC41MDkgY2VydGlmaWNhdGVzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5QaXl1c2gsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGlzIHJlcXVpcmVzIHVu ZGVyc3RhbmRpbmcgd2hhdCBhIGNvbGxpc2lvbiBhdHRhY2sgaXMuJm5ic3A7IEluIGxheXBlcnNv buKAmXMgdGVybXMsIHRoZSBhZHZlcnNhcnkgd2hvIGlzIGEgbGVnaXRpbWF0ZSBhcHBsaWNhbnQg Zm9yIGEgY2VydGlmaWNhdGUsICZuYnNwO2NyZWF0ZXMgbmFtZXMgYW5kIGtleXMgc3VjaCB3aGVu IHRoZSBDQSBzaWducyBhIGNlcnRpZmljYXRlLCB0aGUgaGFzaCB3aWxsIGJlIHRoZSBzYW1lIGFz IHRoZSBhZHZlcnNhcnkgaGFzIGNyZWF0ZWQgY29sbGlzaW9uIGZvciB3aGlsZSBzdWJtaXR0aW5n IHRoZSByZXF1ZXN0LiZuYnNwOyBOb3cgdGhlIGFkdmVyc2FyeSBjYW4gcHJlc2VudCB0aGUgb3Ro ZXIgY2VydGlmaWNhdGUgd2l0aCBiYXNpYyBjb25zdHJhaW50IGV4dGVuc2lvbiwgd2l0aCBkaWZm ZXJlbnQgbmFtZSwgb3Igd2l0aCBkaWZmZXJlbnQgcG9saWNpZXMgYXMgaXNzdWVkIGJ5IHRoZSBD QS4mbmJzcDsgSW4gdGhpcyBwcm9jZXNzLCB0aGUgYWR2ZXJzYXJ5IHdoaWxlIGNvbXB1dGluZyB0 aGUgY29sbGlzaW9uIG5lZWRzIHRvIGtub3cgdGhlIGxpa2VseSBzZXJpYWwgbnVtYmVyIHRoZSBD QSB3aWxsIGFzc2lnbiwgYW1vbmcgb3RoZXIgdGhpbmdzLiBSYW5kb21pemluZyBzZXJpYWwgbnVt YmVyIGlzIG9uZSB3YXkgb2YgZGVmZWF0aW5nIHRoZSBhdHRhY2suJm5ic3A7IFB1dHRpbmcgcmFu ZG9tbmVzcyBpcyBub3QgYWZ0ZXIgaXMgYW5vdGhlci4mbmJzcDsgUmFuZG9tbmVzcyBuZWVkcyB0 byBjb21lIGJlZm9yZSBTdWJqZWN0IEROIHNpbmNlIHRoYXQgaXMgdGhlIG1vc3QgbGlrZWx5IGZp cnN0IGlucHV0IGZyb20gdGhlIGF0dGFja2VyIHdoZW4geW91IHNjYW4gdGhlIGNlcnRpZmljYXRl LiZuYnNwOyBNeSBmYXZvcml0ZSBpcyB0aGUgcGFyYW1ldGVyIGZpZWxkIGluIHNpZ25hdHVyZSBm aWVsZCBzaW5jZSBpdCBpcyBub3Qgc3VwcG9zZWQgdG8gYmUgdXNlZC4mbmJzcDsgQnV0LCBJIGFt IGFmcmFpZCBpdCBpcyBub3QgcHJhY3RpY2FsIHNpbmNlIGl0IHdpbGwgZnJlYWsgb3V0IG1vc3Qg YXBwbGljYXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPiA8YSBocmVmPSJtYWlsdG86cGtpeC1ib3VuY2VzQGll dGYub3JnIj5wa2l4LWJvdW5jZXNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Im1haWx0bzpbbWFpbHRv OnBraXgtYm91bmNlc0BpZXRmLm9yZ10iPlttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXTwv YT4gPGI+T24gQmVoYWxmIE9mIDwvYj5QaXl1c2ggSmFpbjxicj48Yj5TZW50OjwvYj4gRnJpZGF5 LCBEZWNlbWJlciAxNCwgMjAxMiAxOjI3IFBNPGJyPjxiPlRvOjwvYj4gJ0Vyd2FubiBBYmFsZWEn PGJyPjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnBraXhAaWV0Zi5vcmciPnBraXhAaWV0Zi5v cmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3BraXhdIFF1ZXN0aW9uaW5nIHRoZSBiZW5l Zml0IG9mIHJhbmRvbSBzZXJpYWxzIG92ZXIgc2VxdWVudGlhbCBvbmVzIGluIHguNTA5IGNlcnRp ZmljYXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+TWF5IGJlIEkgYW0gbWlzc2luZyBzb21ldGhpbmcgdmVyeSBiYXNpYy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ SWYgdGhlIGNlcnRpZmljYXRlIGlzIGF2YWlsYWJsZSB0byB0aGUgYXR0YWNrZXIsIGhvdyBkb2Vz IHJhbmRvbSBzZXJpYWwgaGVscCBhdm9pZCBhIHByZWZpeCBjb2xsaXNpb24gYXR0YWNrLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+VGhlIGF0dGFja2VyIGp1c3QgZm9yZ2VzIGFub3RoZXIgY2VydGlmaWNh dGUgd2l0aCBzYW1lIHNlcmlhbCBhbmQga2VlcHMgb24gY2hhbmdpbmcgYW4gZXh0ZW5zaW9uIHdp dGggcmFuZG9tIHZhbHVlIHRvIGZvcmNlIGEgaGFzaCBjb2xsaXNpb24uPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldoZXRoZXIg dGhlIHNlcmlhbCBpbiB0aGUgY2VydGlmaWNhdGUgaXMgcmFuZG9tIG9yIG5vdCBzaG91bGQgbm90 IGhhdmUgYW55IGltcGFjdCBvbiB0aGUgYWJvdmUgcHJvY2Vzcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn Pi1QaXl1c2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNs YXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBFcndhbm4g QWJhbGVhIFs8YSBocmVmPSJtYWlsdG86ZWFiYWxlYUBnbWFpbC5jb20iPm1haWx0bzplYWJhbGVh QGdtYWlsLmNvbTwvYT5dIDxicj48Yj5TZW50OjwvYj4gRnJpZGF5LCBEZWNlbWJlciAxNCwgMjAx MiAxMDoxNyBBTTxicj48Yj5Ubzo8L2I+IFBpeXVzaCBKYWluPGJyPjxiPkNjOjwvYj4gPGEgaHJl Zj0ibWFpbHRvOnBraXhAaWV0Zi5vcmciPnBraXhAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6 PC9iPiBSZTogW3BraXhdIFF1ZXN0aW9uaW5nIHRoZSBiZW5lZml0IG9mIHJhbmRvbSBzZXJpYWxz IG92ZXIgc2VxdWVudGlhbCBvbmVzIGluIHguNTA5IGNlcnRpZmljYXRlczxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjIwMTIvMTIvMTQgUGl5dXNoIEphaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwaXl1 c2hAZGl0ZW5pdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGl5dXNoQGRpdGVuaXR5LmNvbTwvYT4m Z3Q7PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPknigJltIG5vdCBzdXJlIHdoYXQgdmFsdWUgZG9lcyBhIHJvb3QgQ0EgZ2V0cyBv dXQgb2YgdGhpcy48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ V2hlbiBtZW50aW9uaW5nIHJvb3QgcHJvZ3JhbXMsIEknbSB0YWxraW5nIGFib3V0IHJvb3QgaW5j bHVzaW9uIGludG8gcHVibGljIHNvZnR3YXJlIChicm93c2VycywgbWFpbmx5KSwgbm90IGNlcnRp ZmljYXRlcyBpc3N1ZWQgYnkgdGhlIHJvb3QgQ0EuIFRoZSAmcXVvdDtyYW5kb20gc2VyaWFsJnF1 b3Q7IHJlcXVpcmVtZW50IGlzIHRvIGJlIGFwcGxpZWQgdG8gQ0Egc29mdHdhcmUgdGhhdCBpc3N1 ZSBlbmQtdXNlciBjZXJ0aWZpY2F0ZXMuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+U2luY2UgdGhlIGludGVybWVkaWF0ZSBjZXJ0aWZp Y2F0ZXMgKGlzc3VlZCBieSByb290KSBhcmUgYWxzbyBwdWJsaWNseSB2aXNpYmxlLCBpdCBkb2Vz IG5vdCBtYXR0ZXIgaWYgdGhlIHNlcmlhbCBpcyByYW5kb20gb3Igbm90Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhpcyBo YXMgbm90aGluZyB0byBkbyB3aXRoIHNlY3JldGx5IGlzc3VlZCBjZXJ0aWZpY2F0ZXMsIGJ1dCB3 aXRoIGtub3duIHByZWZpeCBjb2xsaXNpb24gYXR0YWNrcy48bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2tx dW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SXNu4oCZdCBpdCB0cnVlIHRoYXQgdGhp cyB3b3JrcyBvbmx5IGlmIHRoZSBhdHRhY2tlciBkb2VzIG5vdCBoYXZlIGFjY2VzcyB0byB0aGUg aXNzdWVkIGNlcnRpZmljYXRlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFzc3VtaW5nIHRoZSBQSyBjZXJ0aWZpY2F0ZXMg YXJlIG5vdCBwdWJsaWMgaXMgc29ydCBvZiBjb3VudGVyLWludHVpdGl2ZS48L3NwYW4+PG86cD48 L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkknbSBub3Qgc3Vy ZSBJJ20gZm9sbG93aW5nIHlvdS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5BIGNlcnRpZmljYXRlIGlzIGEgcHVibGljIG9iamVjdCwgZm9yIHN1cmUuPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBjYW4ndCBpbWFnaW5lIHdo YXQgY291bGQgYmUgdGhlIHVzZSBvZiBhIENBIHNvZnR3YXJlIGFjY2VwdGluZyBjZXJ0aWZpY2F0 ZSByZXF1ZXN0cyBidXQgcmVmdXNpbmcgYWNjZXNzIHRvIHRoZSBpc3N1ZWQgY2VydGlmaWNhdGUu PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+IEVyd2FubiBBYmFsZWEgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZWFiYWxlYUBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5lYWJhbGVhQGdtYWlsLmNvbTwvYT5dIDxicj48Yj5TZW50 OjwvYj4gRnJpZGF5LCBEZWNlbWJlciAxNCwgMjAxMiA5OjI2IEFNPGJyPjxiPlRvOjwvYj4gUGl5 dXNoIEphaW48YnI+PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cGtpeEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnBraXhAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3Br aXhdIFF1ZXN0aW9uaW5nIHRoZSBiZW5lZml0IG9mIHJhbmRvbSBzZXJpYWxzIG92ZXIgc2VxdWVu dGlhbCBvbmVzIGluIHguNTA5IGNlcnRpZmljYXRlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCc+Qm9uam91ciw8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjIwMTIvMTIvMTQgUGl5dXNoIEphaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwaXl1 c2hAZGl0ZW5pdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGl5dXNoQGRpdGVuaXR5LmNvbTwvYT4m Z3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+SXQgc2VlbXMgdGhhdCB0aGUg Y3VycmVudCBiZXN0IHByYWN0aWNlIGlzIHRvIHVzZSBub24tc2VxdWVudGlhbCBzZXJpYWw8YnI+ bnVtYmVycyB3aGVuIGlzc3VpbmcgeC41MDkgY2VydGlmaWNhdGVzLjxvOnA+PC9vOnA+PC9wPjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz5UaGF0J3Mgbm90IG9ubHkgYSAmcXVvdDtiZXN0IHByYWN0aWNl JnF1b3Q7LCBidXQgYWxzbyBhIHJlcXVpcmVtZW50IGZvciBzZXZlcmFsIHJvb3QgcHJvZ3JhbXMu PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpw PjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjUuMHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5JIHVuZGVyc3RhbmQgdGhhdCBpdCBoYWQgc29t ZSB2YWx1ZSB3aGVuIHdlYWsgaGFzaGluZyBhbGdvcml0aG1zIHdlcmUgYmVpbmc8YnI+dXNlZCB0 byBjcmVhdGUgdGhlIHNpZ25hdHVyZS48bzpwPjwvbzpwPjwvcD48L2Jsb2NrcXVvdGU+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPkl0IHN0aWxsIGhhcyBzb21lIHZhbHVlLCBiZWNhdXNlIHdlYWsgaGFz aCBmdW5jdGlvbnMgYXJlIHN0aWxsIHVzZWQgaW4gYSBzaWduYXR1cmUgY29udGV4dC4gU0hBMSBp c24ndCBvdmVyLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+QnV0IGlmIHlvdSBhcmUgdXNp bmcgYSBzdHJvbmcgaGFzaGluZyBhbGdvcml0aG0sIHdoYXQgaXMgdGhlIGJlbmVmaXQgb2Y8YnI+ aXNzdWluZyBjZXJ0aWZpY2F0ZXMgd2l0aCByYW5kb20gc2VyaWFsIHZhbHVlcz88bzpwPjwvbzpw PjwvcD48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPkkgZG9uJ3Qgc2VlIGFueSBi ZW5lZml0IGluIHN1Y2ggYSBzaXR1YXRpb24uPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz4tLSA8YnI+RXJ3YW5uLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2Pjwv ZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxiciBj bGVhcj1hbGw+PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tIDxicj5Fcndhbm4uPG86cD48 L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_B83745DA469B7847811819C5005244AF3632765Fscygexch7cygnac_-- From schaen@mitre.org Fri Dec 14 14:05:29 2012 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 71A8621F892D for ; Fri, 14 Dec 2012 14:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 44xBPbVYoQ72 for ; Fri, 14 Dec 2012 14:05:25 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 706B121F87FA for ; Fri, 14 Dec 2012 14:05:25 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EA2FF1F0501; Fri, 14 Dec 2012 17:05:24 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CE6794350239; Fri, 14 Dec 2012 17:05:24 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Fri, 14 Dec 2012 17:05:24 -0500 From: "Schaen, Samuel I." To: "Kemp, David P." , "pkix@ietf.org" Thread-Topic: [pkix] Random Serials Make OCSP Presigning Hard [WAS: Questioning the benefit of random serials over sequential ones in x.509 certificates] Thread-Index: Ac3aRxzllXROK4IERaW9I4RxIzd0Bg== Date: Fri, 14 Dec 2012 22:05:24 +0000 Message-ID: <05B0827555CC904EAAF411605F38BF830667706D@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pkix] Random Serials Make OCSP Presigning Hard [WAS: Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 22:05:29 -0000 I changed the subject name to keep the threads separate. The CAs would need to update the responders with each new CRL to account fo= r newly issued certificates.=20 A new protocol would be needed to standardize how that list of issued certi= ficates is passed to the provider (assuming you want CAs and Responders fro= m different vendors).=20 Passing the full list each time could be expensive in bandwidth for CAs wit= h a large number of certificates (e.g., the DoD).=20 Supporting deltas would add additional complexity.=20 Not rocket science; but not a cakewalk either. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Kem= p, David P. Sent: Friday, December 14, 2012 2:54 PM To: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequenti= al ones in x.509 certificates Santosh, You are correct. For some reason my old brain got the idea that OCSP reque= sts and responses contained subject DNs. I have no clue where that came fr= om, since: CertID ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key serialNumber CertificateSerialNumber } As Roseanne Rosannadanna said, "never mind". However, a list of issued CertificateSerialNumber's could be distributed to= OCSP responders that don't have a direct CA connection, in addition to CRL= s. That is an added complication, but hardly an engineering challenge. Dave -----Original Message----- From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]=20 Sent: Friday, December 14, 2012 2:18 PM To: Kemp, David P.; pkix@ietf.org Subject: RE: [pkix] Questioning the benefit of random serials over sequenti= al ones in x.509 certificates Dave, What DN are you talking about? If the Responder has the CRL, it has the is= suer DN. It verifies the signature on the CRL using the issuer public key = which it obtains using any proper means (say a certificate). I do not see any other data required for request or response that Responder= needs. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From pgut001@cs.auckland.ac.nz Fri Dec 14 14:11:17 2012 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 893FC21F8A0A for ; Fri, 14 Dec 2012 14:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NmD7fF-LsWe8 for ; Fri, 14 Dec 2012 14:11:11 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC11B21F89E6 for ; Fri, 14 Dec 2012 14:11:10 -0800 (PST) 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=1355523071; x=1387059071; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=8mBs6sM9tTrlXpNFZuOPXUQCTqMQARcTKYvXrZkzdtU=; b=ZiDtnqjOA5IZeGdjpoqG78XvMOUbeDsGMNWrV3RbDo51diC2v/M6f4nW bOvI685MKi+Ahca9+xji7F+45YThOl/gs+yAcRsf8icIJl+X9nHI+t0Ch b02VGur7OZwW45uttlgBDQvUEgkjNcALAobKreDF1TEbGNvy/MlMCEfGE I=; X-IronPort-AV: E=Sophos;i="4.84,284,1355050800"; d="scan'208";a="162141587" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 15 Dec 2012 11:11:10 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.67]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Sat, 15 Dec 2012 11:11:09 +1300 From: Peter Gutmann To: "pkix@ietf.org" Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: Ac3aR+sD9xfiIfdTSUuEQ7mt4lIWyw== Date: Fri, 14 Dec 2012 22:11:08 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7331D3F2A9@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 22:11:18 -0000 Piyush Jain writes:=0A= =0A= >But if you are using a strong hashing algorithm, what is the benefit of=0A= >issuing certificates with random serial values?=0A= =0A= It doesn't allow third parties to track how many (or few) certs your CA has= =0A= issued. Making the serial number sequential gives your competition a day-b= y-=0A= day breakdown of how many certs you're selling.=0A= =0A= Peter.=0A= From piyush@ditenity.com Fri Dec 14 14:26:40 2012 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 3A00B21F8A91 for ; Fri, 14 Dec 2012 14:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, 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 IpnC33GDVxrW for ; Fri, 14 Dec 2012 14:26:36 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E52321F8927 for ; Fri, 14 Dec 2012 14:26:36 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so3642019iaz.31 for ; Fri, 14 Dec 2012 14:26:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=iwoe7XC3/1P5YfchApbOMVrTkeIw+OtowpRUZ+VZkHE=; b=A0MR3gnxLHxGteUm0922NTQESOI82b/lf8QEE7eB1MVL3i7rPrc1XjEUqGJFauFm+0 Zb7M7XfuJbhaof6quVxbeZhnwRz2sO85Ml37nQ0ToTKL2AJ3oYvBUmN9FmICM6Ux1QqE CRGUbKeoDtyR/wq2r2o163oszlj/76ezsFSOO2DWuqQf5livQlEj+wUCYbtO7qVQb735 z6YGuzVylYO5geVfwBmbXGG3VPPUDv085yDoLxbtQsLKGTGlJhWb4G0zYAalSpmdbyrE HoI1LlksVi0CxrrIxjn5VHT34GeptVhZZKkkXjBoDOPn4v8mTxFe2x++88RTtL+7meG5 c0hA== X-Received: by 10.50.40.225 with SMTP id a1mr3162410igl.7.1355523995570; Fri, 14 Dec 2012 14:26:35 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id eu3sm7742663igc.7.2012.12.14.14.26.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 14:26:35 -0800 (PST) From: "Piyush Jain" To: "'Schaen, Samuel I.'" , "'Kemp, David P.'" , References: <05B0827555CC904EAAF411605F38BF830667706D@IMCMBX01.MITRE.ORG> In-Reply-To: <05B0827555CC904EAAF411605F38BF830667706D@IMCMBX01.MITRE.ORG> Date: Fri, 14 Dec 2012 14:26:31 -0800 Message-ID: <05e101cdda4a$120c1830$36244890$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFLigT0ZxaSbZkcM7o4e0OVM151G5kdfNTA Content-Language: en-us X-Gm-Message-State: ALoCoQnAnKIETKmDHFIdNNsWWTUBDp8FkBSxvA1gnzdnDliaCWUoRDQ7gRpJ3fo9pOMJeyH8X99M Subject: Re: [pkix] Random Serials Make OCSP Presigning Hard [WAS: Questioning the benefit of random serials over sequential ones in x.509 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: Fri, 14 Dec 2012 22:26:40 -0000 Comments inline. > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Schaen, Samuel I. > Sent: Friday, December 14, 2012 2:05 PM > To: Kemp, David P.; pkix@ietf.org > Subject: [pkix] Random Serials Make OCSP Presigning Hard [WAS: > Questioning the benefit of random serials over sequential ones in x.509 > certificates] > > I changed the subject name to keep the threads separate. > > The CAs would need to update the responders with each new CRL to account > for newly issued certificates. [Piyush] Agreed. I would assume it's a big problem in enterprise PKI, not so much in web pki. The update would be needed not only with each CRL but with every new cert that is issued. > > A new protocol would be needed to standardize how that list of issued > certificates is passed to the provider (assuming you want CAs and > Responders from different vendors). > [Piyush] Don't think that is happening. Public CAs are happy with the proprietary method as they own the CA and the responder. Some large enterprise PKI deployments though,have refused to adopt random serials precisely because of this reason. > Passing the full list each time could be expensive in bandwidth for CAs with a > large number of certificates (e.g., the DoD). > > Supporting deltas would add additional complexity. [Piyush] Do you mean deltas of pre-signed response collection? Not sure if I understand this one. > > Not rocket science; but not a cakewalk either. > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Kemp, David P. > Sent: Friday, December 14, 2012 2:54 PM > To: pkix@ietf.org > Subject: Re: [pkix] Questioning the benefit of random serials over sequential > ones in x.509 certificates > > Santosh, > > You are correct. For some reason my old brain got the idea that OCSP > requests and responses contained subject DNs. I have no clue where that > came from, since: > > CertID ::= SEQUENCE { > hashAlgorithm AlgorithmIdentifier, > issuerNameHash OCTET STRING, -- Hash of Issuer's DN > issuerKeyHash OCTET STRING, -- Hash of Issuers public key > serialNumber CertificateSerialNumber } > > > As Roseanne Rosannadanna said, "never mind". > > However, a list of issued CertificateSerialNumber's could be distributed to > OCSP responders that don't have a direct CA connection, in addition to CRLs. > That is an added complication, but hardly an engineering challenge. > > Dave > > > > -----Original Message----- > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > Sent: Friday, December 14, 2012 2:18 PM > To: Kemp, David P.; pkix@ietf.org > Subject: RE: [pkix] Questioning the benefit of random serials over sequential > ones in x.509 certificates > > Dave, > > What DN are you talking about? If the Responder has the CRL, it has the > issuer DN. It verifies the signature on the CRL using the issuer public key > which it obtains using any proper means (say a certificate). > > I do not see any other data required for request or response that Responder > needs. > _______________________________________________ > 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 bruce.stephens@isode.com Mon Dec 17 02:32:03 2012 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 328D121F8A70 for ; Mon, 17 Dec 2012 02:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, 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 T7usWpppYMRV for ; Mon, 17 Dec 2012 02:31:59 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 93E1221F8A82 for ; Mon, 17 Dec 2012 02:31:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1355740314; d=isode.com; s=selector; i=@isode.com; bh=rt85fAuvlTW51JlEdHftHO7rpOrKdEguMiRpW8D07DE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=LC93SefHyWCRT6HXk76AddC7WZyg/lKjNAu+KCGGIqs8eOasJWFhuOr44CbBSWTs77WWh8 54Xn8/BZJcg2+ea59Wc2iMZMxu5BrFW7JS3N+FPawakKo4j/03d+nyP0efLWzOdO3u+Pe1 VOYBjv0ziqXpzilYlICX8pomFAZ58Nk=; Received: from tinier.isode.net (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id for ; Mon, 17 Dec 2012 10:31:53 +0000 Received: by tinier.isode.net (sSMTP sendmail emulation); Mon, 17 Dec 2012 10:31:52 +0000 From: Bruce Stephens To: pkix@ietf.org X-Hashcash: 1:20:121217:pkix@ietf.org::HNVR7NRq6DmwK5qj:00001ZqX Date: Mon, 17 Dec 2012 10:31:52 +0000 Message-ID: <80vcc1ufzb.fsf@tinier.isode.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [pkix] Advice on (small amounts of) clock skew? 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, 17 Dec 2012 10:32:03 -0000 Specifically, the NIST PIV infrastructure has CRLs (and presigned OCSP responses) issued hourly (though the CRLs at least last for a day), and that caused unexpected problems when testing: a non-trivial amount of the time, the CRLs were not yet valid. If it was that the nextUpdate time had passed, then there's advice in RFC 5280 (one should try and get a new CRL or delta CRL, but (depending on local situations) continuing to use the CRL may well be appropriate), but I don't see any suggestions on what to do if it appears that the CRL isn't yet valid. (I suppose waiting is one option...) (SDN.705 gives guidance for X.500, but only for bind tokens and the like. I imagine SDN.706 offers something for certificates and CRLs, but I haven't seen that.) From tmiller@mitre.org Mon Dec 17 05:28:02 2012 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 86F3121F8ACB for ; Mon, 17 Dec 2012 05:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+gzwSQVnZGU for ; Mon, 17 Dec 2012 05:28:02 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EA44621F8AC7 for ; Mon, 17 Dec 2012 05:28:01 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2ACF91F0356; Mon, 17 Dec 2012 08:28:01 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 15EDC1F0249; Mon, 17 Dec 2012 08:28:01 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 08:28:00 -0500 From: "Miller, Timothy J." To: "'Kemp, David P.'" , "pkix@ietf.org" Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: Ac3aHP2+k1UCZ+fYR0SXQqG7rwstYAAAsvTgAI6cqEA= Date: Mon, 17 Dec 2012 13:27:59 +0000 Message-ID: <195DB2510AAA004391F58E28FCE21200066FCAEA@IMCMBX01.MITRE.ORG> References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <5B1D7E570380A64989D4C069F7D14BC850AF8D4D@clavin.missi.ncsc.mil> In-Reply-To: <5B1D7E570380A64989D4C069F7D14BC850AF8D4D@clavin.missi.ncsc.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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, 17 Dec 2012 13:28:02 -0000 Theoretically, we could dispense with SNs altogether, given a robust SKID. -- T >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Kemp, David P. >Sent: Friday, December 14, 2012 12:34 PM >To: pkix@ietf.org >Subject: Re: [pkix] Questioning the benefit of random serials over sequent= ial >ones in x.509 certificates > >Sparse namespaces are generic good security hygiene. Data mining, like >telemarketer robocalling, is enabled by compact namespaces, and the large >random-looking URLs employed by, e.g., photo sharing websites are an >attempt to make mining more difficult. > >If the only way to retrieve a certificate from a directory or web reposito= ry is to >know its name or serial number, then making valid S/Ns difficult to guess >makes trawling more difficult and easier to detect. > >Dave > > >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Piyush Jain >Sent: Friday, December 14, 2012 12:09 PM >To: pkix@ietf.org >Subject: [pkix] Questioning the benefit of random serials over sequential = ones >in x.509 certificates > >Hi All, > >It seems that the current best practice is to use non-sequential serial nu= mbers >when issuing x.509 certificates. > >I understand that it had some value when weak hashing algorithms were >being used to create the signature. >But if you are using a strong hashing algorithm, what is the benefit of is= suing >certificates with random serial values? > >Thanks a lot in advance for any insights. > >-Piyush > >_______________________________________________ >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 tmiller@mitre.org Mon Dec 17 05:32:20 2012 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 9FEA821F8AB0 for ; Mon, 17 Dec 2012 05:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoRvWRGUq8x5 for ; Mon, 17 Dec 2012 05:32:14 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3C40721F8A5A for ; Mon, 17 Dec 2012 05:32:14 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B191E1F0833; Mon, 17 Dec 2012 08:32:13 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 97B5B1F0829; Mon, 17 Dec 2012 08:32:13 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 08:32:13 -0500 From: "Miller, Timothy J." To: 'Santosh Chokhani' , Piyush Jain , 'Erwann Abalea' Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: AQHN2i3XYdn1AikjCk6+DSYWRRLFj5gdAOBw Date: Mon, 17 Dec 2012 13:32:12 +0000 Message-ID: <195DB2510AAA004391F58E28FCE21200066FCB20@IMCMBX01.MITRE.ORG> References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <043901cdda25$78442770$68cc7650$@ditenity.com> <049301cdda28$ad6c8610$08459230$@ditenity.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.54] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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, 17 Dec 2012 13:32:20 -0000 UmFuZG9taXppbmcgdGhlIGxvdy1vcmRlciBiaXRzIG9mIHRoZSB2YWxpZGl0eSBkYXRlcyBpcyBt eSBmYXZvcml0ZS4gIE5vLW9uZSB3b3VsZCBub3RpY2UuDQoNCi0tIFQNCg0KPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogcGtpeC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGtp eC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj5TYW50b3NoIENob2toYW5pDQo+U2Vu dDogRnJpZGF5LCBEZWNlbWJlciAxNCwgMjAxMiAyOjA0IFBNDQo+VG86IFBpeXVzaCBKYWluOyAn RXJ3YW5uIEFiYWxlYScNCj5DYzogcGtpeEBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbcGtpeF0g UXVlc3Rpb25pbmcgdGhlIGJlbmVmaXQgb2YgcmFuZG9tIHNlcmlhbHMgb3ZlciBzZXF1ZW50aWFs DQo+b25lcyBpbiB4LjUwOSBjZXJ0aWZpY2F0ZXMNCj4NCj5QaXl1c2gsDQo+DQo+DQo+DQo+VGhp cyByZXF1aXJlcyB1bmRlcnN0YW5kaW5nIHdoYXQgYSBjb2xsaXNpb24gYXR0YWNrIGlzLiAgSW4g bGF5cGVyc29u4oCZcyB0ZXJtcywNCj50aGUgYWR2ZXJzYXJ5IHdobyBpcyBhIGxlZ2l0aW1hdGUg YXBwbGljYW50IGZvciBhIGNlcnRpZmljYXRlLCAgY3JlYXRlcyBuYW1lcw0KPmFuZCBrZXlzIHN1 Y2ggd2hlbiB0aGUgQ0Egc2lnbnMgYSBjZXJ0aWZpY2F0ZSwgdGhlIGhhc2ggd2lsbCBiZSB0aGUg c2FtZSBhcyB0aGUNCj5hZHZlcnNhcnkgaGFzIGNyZWF0ZWQgY29sbGlzaW9uIGZvciB3aGlsZSBz dWJtaXR0aW5nIHRoZSByZXF1ZXN0LiAgTm93IHRoZQ0KPmFkdmVyc2FyeSBjYW4gcHJlc2VudCB0 aGUgb3RoZXIgY2VydGlmaWNhdGUgd2l0aCBiYXNpYyBjb25zdHJhaW50IGV4dGVuc2lvbiwNCj53 aXRoIGRpZmZlcmVudCBuYW1lLCBvciB3aXRoIGRpZmZlcmVudCBwb2xpY2llcyBhcyBpc3N1ZWQg YnkgdGhlIENBLiAgSW4gdGhpcw0KPnByb2Nlc3MsIHRoZSBhZHZlcnNhcnkgd2hpbGUgY29tcHV0 aW5nIHRoZSBjb2xsaXNpb24gbmVlZHMgdG8ga25vdyB0aGUgbGlrZWx5DQo+c2VyaWFsIG51bWJl ciB0aGUgQ0Egd2lsbCBhc3NpZ24sIGFtb25nIG90aGVyIHRoaW5ncy4gUmFuZG9taXppbmcgc2Vy aWFsDQo+bnVtYmVyIGlzIG9uZSB3YXkgb2YgZGVmZWF0aW5nIHRoZSBhdHRhY2suICBQdXR0aW5n IHJhbmRvbW5lc3MgaXMgbm90IGFmdGVyIGlzDQo+YW5vdGhlci4gIFJhbmRvbW5lc3MgbmVlZHMg dG8gY29tZSBiZWZvcmUgU3ViamVjdCBETiBzaW5jZSB0aGF0IGlzIHRoZQ0KPm1vc3QgbGlrZWx5 IGZpcnN0IGlucHV0IGZyb20gdGhlIGF0dGFja2VyIHdoZW4geW91IHNjYW4gdGhlIGNlcnRpZmlj YXRlLiAgTXkNCj5mYXZvcml0ZSBpcyB0aGUgcGFyYW1ldGVyIGZpZWxkIGluIHNpZ25hdHVyZSBm aWVsZCBzaW5jZSBpdCBpcyBub3Qgc3VwcG9zZWQgdG8gYmUNCj51c2VkLiAgQnV0LCBJIGFtIGFm cmFpZCBpdCBpcyBub3QgcHJhY3RpY2FsIHNpbmNlIGl0IHdpbGwgZnJlYWsgb3V0IG1vc3QgYXBw bGljYXRpb25zLg0KPg0KPg0KPg0KPg0KPg0KPkZyb206IHBraXgtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+UGl5dXNoIEphaW4N Cj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDE0LCAyMDEyIDE6MjcgUE0NCj5UbzogJ0Vyd2FubiBB YmFsZWEnDQo+Q2M6IHBraXhAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3BraXhdIFF1ZXN0aW9u aW5nIHRoZSBiZW5lZml0IG9mIHJhbmRvbSBzZXJpYWxzIG92ZXIgc2VxdWVudGlhbA0KPm9uZXMg aW4geC41MDkgY2VydGlmaWNhdGVzDQo+DQo+DQo+DQo+TWF5IGJlIEkgYW0gbWlzc2luZyBzb21l dGhpbmcgdmVyeSBiYXNpYy4NCj4NCj5JZiB0aGUgY2VydGlmaWNhdGUgaXMgYXZhaWxhYmxlIHRv IHRoZSBhdHRhY2tlciwgaG93IGRvZXMgcmFuZG9tIHNlcmlhbCBoZWxwDQo+YXZvaWQgYSBwcmVm aXggY29sbGlzaW9uIGF0dGFjay4NCj4NCj4NCj4NCj5UaGUgYXR0YWNrZXIganVzdCBmb3JnZXMg YW5vdGhlciBjZXJ0aWZpY2F0ZSB3aXRoIHNhbWUgc2VyaWFsIGFuZCBrZWVwcyBvbg0KPmNoYW5n aW5nIGFuIGV4dGVuc2lvbiB3aXRoIHJhbmRvbSB2YWx1ZSB0byBmb3JjZSBhIGhhc2ggY29sbGlz aW9uLg0KPg0KPldoZXRoZXIgdGhlIHNlcmlhbCBpbiB0aGUgY2VydGlmaWNhdGUgaXMgcmFuZG9t IG9yIG5vdCBzaG91bGQgbm90IGhhdmUgYW55DQo+aW1wYWN0IG9uIHRoZSBhYm92ZSBwcm9jZXNz Lg0KPg0KPg0KPg0KPi1QaXl1c2gNCj4NCj4NCj4NCj4NCj4NCj5Gcm9tOiBFcndhbm4gQWJhbGVh IFttYWlsdG86ZWFiYWxlYUBnbWFpbC5jb21dDQo+U2VudDogRnJpZGF5LCBEZWNlbWJlciAxNCwg MjAxMiAxMDoxNyBBTQ0KPlRvOiBQaXl1c2ggSmFpbg0KPkNjOiBwa2l4QGlldGYub3JnDQo+U3Vi amVjdDogUmU6IFtwa2l4XSBRdWVzdGlvbmluZyB0aGUgYmVuZWZpdCBvZiByYW5kb20gc2VyaWFs cyBvdmVyIHNlcXVlbnRpYWwNCj5vbmVzIGluIHguNTA5IGNlcnRpZmljYXRlcw0KPg0KPg0KPg0K Pg0KPg0KPjIwMTIvMTIvMTQgUGl5dXNoIEphaW4gPHBpeXVzaEBkaXRlbml0eS5jb20+DQo+DQo+ SeKAmW0gbm90IHN1cmUgd2hhdCB2YWx1ZSBkb2VzIGEgcm9vdCBDQSBnZXRzIG91dCBvZiB0aGlz Lg0KPg0KPg0KPg0KPldoZW4gbWVudGlvbmluZyByb290IHByb2dyYW1zLCBJJ20gdGFsa2luZyBh Ym91dCByb290IGluY2x1c2lvbiBpbnRvIHB1YmxpYw0KPnNvZnR3YXJlIChicm93c2VycywgbWFp bmx5KSwgbm90IGNlcnRpZmljYXRlcyBpc3N1ZWQgYnkgdGhlIHJvb3QgQ0EuIFRoZQ0KPiJyYW5k b20gc2VyaWFsIiByZXF1aXJlbWVudCBpcyB0byBiZSBhcHBsaWVkIHRvIENBIHNvZnR3YXJlIHRo YXQgaXNzdWUgZW5kLQ0KPnVzZXIgY2VydGlmaWNhdGVzLg0KPg0KPg0KPg0KPglTaW5jZSB0aGUg aW50ZXJtZWRpYXRlIGNlcnRpZmljYXRlcyAoaXNzdWVkIGJ5IHJvb3QpIGFyZSBhbHNvIHB1Ymxp Y2x5DQo+dmlzaWJsZSwgaXQgZG9lcyBub3QgbWF0dGVyIGlmIHRoZSBzZXJpYWwgaXMgcmFuZG9t IG9yIG5vdC4NCj4NCj4NCj4NCj5UaGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggc2VjcmV0bHkg aXNzdWVkIGNlcnRpZmljYXRlcywgYnV0IHdpdGgga25vd24gcHJlZml4DQo+Y29sbGlzaW9uIGF0 dGFja3MuDQo+DQo+DQo+DQo+CUlzbuKAmXQgaXQgdHJ1ZSB0aGF0IHRoaXMgd29ya3Mgb25seSBp ZiB0aGUgYXR0YWNrZXIgZG9lcyBub3QgaGF2ZSBhY2Nlc3MgdG8NCj50aGUgaXNzdWVkIGNlcnRp ZmljYXRlPw0KPg0KPglBc3N1bWluZyB0aGUgUEsgY2VydGlmaWNhdGVzIGFyZSBub3QgcHVibGlj IGlzIHNvcnQgb2YgY291bnRlci1pbnR1aXRpdmUuDQo+DQo+DQo+DQo+SSdtIG5vdCBzdXJlIEkn bSBmb2xsb3dpbmcgeW91Lg0KPg0KPkEgY2VydGlmaWNhdGUgaXMgYSBwdWJsaWMgb2JqZWN0LCBm b3Igc3VyZS4NCj4NCj5JIGNhbid0IGltYWdpbmUgd2hhdCBjb3VsZCBiZSB0aGUgdXNlIG9mIGEg Q0Egc29mdHdhcmUgYWNjZXB0aW5nIGNlcnRpZmljYXRlDQo+cmVxdWVzdHMgYnV0IHJlZnVzaW5n IGFjY2VzcyB0byB0aGUgaXNzdWVkIGNlcnRpZmljYXRlLg0KPg0KPg0KPg0KPglGcm9tOiBFcndh bm4gQWJhbGVhIFttYWlsdG86ZWFiYWxlYUBnbWFpbC5jb21dDQo+CVNlbnQ6IEZyaWRheSwgRGVj ZW1iZXIgMTQsIDIwMTIgOToyNiBBTQ0KPglUbzogUGl5dXNoIEphaW4NCj4JQ2M6IHBraXhAaWV0 Zi5vcmcNCj4JU3ViamVjdDogUmU6IFtwa2l4XSBRdWVzdGlvbmluZyB0aGUgYmVuZWZpdCBvZiBy YW5kb20gc2VyaWFscyBvdmVyDQo+c2VxdWVudGlhbCBvbmVzIGluIHguNTA5IGNlcnRpZmljYXRl cw0KPg0KPg0KPg0KPglCb25qb3VyLA0KPg0KPgkyMDEyLzEyLzE0IFBpeXVzaCBKYWluIDxwaXl1 c2hAZGl0ZW5pdHkuY29tPg0KPg0KPglJdCBzZWVtcyB0aGF0IHRoZSBjdXJyZW50IGJlc3QgcHJh Y3RpY2UgaXMgdG8gdXNlIG5vbi1zZXF1ZW50aWFsIHNlcmlhbA0KPgludW1iZXJzIHdoZW4gaXNz dWluZyB4LjUwOSBjZXJ0aWZpY2F0ZXMuDQo+DQo+DQo+DQo+CVRoYXQncyBub3Qgb25seSBhICJi ZXN0IHByYWN0aWNlIiwgYnV0IGFsc28gYSByZXF1aXJlbWVudCBmb3Igc2V2ZXJhbA0KPnJvb3Qg cHJvZ3JhbXMuDQo+DQo+DQo+DQo+CQlJIHVuZGVyc3RhbmQgdGhhdCBpdCBoYWQgc29tZSB2YWx1 ZSB3aGVuIHdlYWsgaGFzaGluZw0KPmFsZ29yaXRobXMgd2VyZSBiZWluZw0KPgkJdXNlZCB0byBj cmVhdGUgdGhlIHNpZ25hdHVyZS4NCj4NCj4NCj4NCj4JSXQgc3RpbGwgaGFzIHNvbWUgdmFsdWUs IGJlY2F1c2Ugd2VhayBoYXNoIGZ1bmN0aW9ucyBhcmUgc3RpbGwgdXNlZCBpbiBhDQo+c2lnbmF0 dXJlIGNvbnRleHQuIFNIQTEgaXNuJ3Qgb3Zlci4NCj4NCj4NCj4NCj4JCUJ1dCBpZiB5b3UgYXJl IHVzaW5nIGEgc3Ryb25nIGhhc2hpbmcgYWxnb3JpdGhtLCB3aGF0IGlzIHRoZQ0KPmJlbmVmaXQg b2YNCj4JCWlzc3VpbmcgY2VydGlmaWNhdGVzIHdpdGggcmFuZG9tIHNlcmlhbCB2YWx1ZXM/DQo+ DQo+DQo+DQo+CUkgZG9uJ3Qgc2VlIGFueSBiZW5lZml0IGluIHN1Y2ggYSBzaXR1YXRpb24uDQo+ DQo+DQo+DQo+CS0tDQo+CUVyd2Fubi4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4tLQ0KPkVyd2Fu bi4NCg0K From tmiller@mitre.org Mon Dec 17 05:43:38 2012 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 AA5C421F8A92 for ; Mon, 17 Dec 2012 05:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 QWRE0eQyW4dF for ; Mon, 17 Dec 2012 05:43:37 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BA05721F8A6A for ; Mon, 17 Dec 2012 05:43:37 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 32014433003D; Mon, 17 Dec 2012 08:43:37 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0E9A81F07F0; Mon, 17 Dec 2012 08:43:37 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 08:43:36 -0500 From: "Miller, Timothy J." To: 'Piyush Jain' , 'Santosh Chokhani' , 'Erwann Abalea' Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: AQHN2jPC0/5kCErok0K70+C9x63T4ZgdAzPw Date: Mon, 17 Dec 2012 13:43:35 +0000 Message-ID: <195DB2510AAA004391F58E28FCE21200066FCB61@IMCMBX01.MITRE.ORG> References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <043901cdda25$78442770$68cc7650$@ditenity.com> <049301cdda28$ad6c8610$08459230$@ditenity.com> <04f301cdda33$bbae9320$330bb960$@ditenity.com> In-Reply-To: <04f301cdda33$bbae9320$330bb960$@ditenity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.54] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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, 17 Dec 2012 13:43:38 -0000 VGhhdCdzIGEgcHJlaW1hZ2UgYXR0YWNrLCB3aGljaCBoYXZlIGFuIGF2ZXJhZ2UgY2FzZSBvZiAy XihoYXNobGVuLTEpLiAgQ29sbGlzaW9uIGF0dGFja3MgaGF2ZSBhbiBhdmVyYWdlIGNhc2Ugb2Yg Ml4oaGFzaGxlbi8yKS4NCg0KUmVmLiB0aGUgSGFzaGNsYXNoIHByb2plY3QsIE1hcmMgU3RldmVu cywgQXJqZW4gTGVuc3RyYSwgZXQuYWwuICBBbHNvIE1hcmMncyBhbmFseXNpcyBvZiB0aGUgRmxh bWUgY2VydGlmaWNhdGVzLiAgR3JlYXQgd29yay4NCg0KLS0gVA0KDQo+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj5Gcm9tOiBwa2l4LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwa2l4LWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPlBpeXVzaCBKYWluDQo+U2VudDogRnJpZGF5 LCBEZWNlbWJlciAxNCwgMjAxMiAyOjQ3IFBNDQo+VG86ICdTYW50b3NoIENob2toYW5pJzsgJ0Vy d2FubiBBYmFsZWEnDQo+Q2M6IHBraXhAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3BraXhdIFF1 ZXN0aW9uaW5nIHRoZSBiZW5lZml0IG9mIHJhbmRvbSBzZXJpYWxzIG92ZXIgc2VxdWVudGlhbA0K Pm9uZXMgaW4geC41MDkgY2VydGlmaWNhdGVzDQo+DQo+VGhhbmtzIGEgbG90IFNhbnRvc2guIFRo aXMgY2xhcmlmaWVzIHRoaW5ncy4NCj4NCj4NCj4NCj5NeSBhc3N1bXB0aW9uIHdhcyB0aGF0IHRo ZSBhdHRhY2sgaGFwcGVucyBhZnRlciB0aGUgY2VydGlmaWNhdGUgaXMgaXNzdWVkLg0KPg0KPlRo ZSBhdHRhY2tlciBsb29rcyBhdCB0aGUgY2VydGlmaWNhdGUgYW5kIHRyaWVzIHRvIGZvcmdlIGEg Y2VydGlmaWNhdGUgd2l0aCBzYW1lDQo+aGFzaCBieSBpbnNlcnRpbmcgYW4gaXJyZWxldmFudCBl eHRlbnNpb24gYW5kIGNoYW5naW5nIGl0cyBjb250ZW50cy4NCj4NCj4NCj4NCj5TbyBiYXNlZCBv biB3aGF0IHlvdSBhcmUgc2F5aW5nLCBJcyBpdCBjb3JyZWN0IHRvIHNheSB0aGF0IGZpbmRpbmcg YSBwcmVmaXggcDENCj5zdWNoIHRoYXQgSGFzaCAobTEpID0gSGFzaChtMitwMSkgaXMgY29tcHV0 YXRpb25hbGx5IG11Y2ggaGFyZGVyIHRoYW4NCj5maW5kaW5nIHByZWZpeGVzIHAxIGFuZCBwMiBz dWNoIHRoYXQgSGFzaChtMStwMSkgPSBIYXNoKG0yK3AyKS4NCj4NCj4NCj4NCj4tUGl5dXNoDQo+ DQo+DQo+DQo+DQo+DQo+DQo+DQo+RnJvbTogU2FudG9zaCBDaG9raGFuaSBbbWFpbHRvOlNDaG9r aGFuaUBjeWduYWNvbS5jb21dDQo+U2VudDogRnJpZGF5LCBEZWNlbWJlciAxNCwgMjAxMiAxMTow NCBBTQ0KPlRvOiBQaXl1c2ggSmFpbjsgJ0Vyd2FubiBBYmFsZWEnDQo+Q2M6IHBraXhAaWV0Zi5v cmcNCj5TdWJqZWN0OiBSRTogW3BraXhdIFF1ZXN0aW9uaW5nIHRoZSBiZW5lZml0IG9mIHJhbmRv bSBzZXJpYWxzIG92ZXIgc2VxdWVudGlhbA0KPm9uZXMgaW4geC41MDkgY2VydGlmaWNhdGVzDQo+ DQo+DQo+DQo+UGl5dXNoLA0KPg0KPg0KPg0KPlRoaXMgcmVxdWlyZXMgdW5kZXJzdGFuZGluZyB3 aGF0IGEgY29sbGlzaW9uIGF0dGFjayBpcy4gIEluIGxheXBlcnNvbuKAmXMgdGVybXMsDQo+dGhl IGFkdmVyc2FyeSB3aG8gaXMgYSBsZWdpdGltYXRlIGFwcGxpY2FudCBmb3IgYSBjZXJ0aWZpY2F0 ZSwgIGNyZWF0ZXMgbmFtZXMNCj5hbmQga2V5cyBzdWNoIHdoZW4gdGhlIENBIHNpZ25zIGEgY2Vy dGlmaWNhdGUsIHRoZSBoYXNoIHdpbGwgYmUgdGhlIHNhbWUgYXMgdGhlDQo+YWR2ZXJzYXJ5IGhh cyBjcmVhdGVkIGNvbGxpc2lvbiBmb3Igd2hpbGUgc3VibWl0dGluZyB0aGUgcmVxdWVzdC4gIE5v dyB0aGUNCj5hZHZlcnNhcnkgY2FuIHByZXNlbnQgdGhlIG90aGVyIGNlcnRpZmljYXRlIHdpdGgg YmFzaWMgY29uc3RyYWludCBleHRlbnNpb24sDQo+d2l0aCBkaWZmZXJlbnQgbmFtZSwgb3Igd2l0 aCBkaWZmZXJlbnQgcG9saWNpZXMgYXMgaXNzdWVkIGJ5IHRoZSBDQS4gIEluIHRoaXMNCj5wcm9j ZXNzLCB0aGUgYWR2ZXJzYXJ5IHdoaWxlIGNvbXB1dGluZyB0aGUgY29sbGlzaW9uIG5lZWRzIHRv IGtub3cgdGhlIGxpa2VseQ0KPnNlcmlhbCBudW1iZXIgdGhlIENBIHdpbGwgYXNzaWduLCBhbW9u ZyBvdGhlciB0aGluZ3MuIFJhbmRvbWl6aW5nIHNlcmlhbA0KPm51bWJlciBpcyBvbmUgd2F5IG9m IGRlZmVhdGluZyB0aGUgYXR0YWNrLiAgUHV0dGluZyByYW5kb21uZXNzIGlzIG5vdCBhZnRlciBp cw0KPmFub3RoZXIuICBSYW5kb21uZXNzIG5lZWRzIHRvIGNvbWUgYmVmb3JlIFN1YmplY3QgRE4g c2luY2UgdGhhdCBpcyB0aGUNCj5tb3N0IGxpa2VseSBmaXJzdCBpbnB1dCBmcm9tIHRoZSBhdHRh Y2tlciB3aGVuIHlvdSBzY2FuIHRoZSBjZXJ0aWZpY2F0ZS4gIE15DQo+ZmF2b3JpdGUgaXMgdGhl IHBhcmFtZXRlciBmaWVsZCBpbiBzaWduYXR1cmUgZmllbGQgc2luY2UgaXQgaXMgbm90IHN1cHBv c2VkIHRvIGJlDQo+dXNlZC4gIEJ1dCwgSSBhbSBhZnJhaWQgaXQgaXMgbm90IHByYWN0aWNhbCBz aW5jZSBpdCB3aWxsIGZyZWFrIG91dCBtb3N0IGFwcGxpY2F0aW9ucy4NCj4NCj4NCj4NCj4NCj4N Cj5Gcm9tOiBwa2l4LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwa2l4LWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZg0KPlBpeXVzaCBKYWluDQo+U2VudDogRnJpZGF5LCBEZWNlbWJlciAx NCwgMjAxMiAxOjI3IFBNDQo+VG86ICdFcndhbm4gQWJhbGVhJw0KPkNjOiBwa2l4QGlldGYub3Jn DQo+U3ViamVjdDogUmU6IFtwa2l4XSBRdWVzdGlvbmluZyB0aGUgYmVuZWZpdCBvZiByYW5kb20g c2VyaWFscyBvdmVyIHNlcXVlbnRpYWwNCj5vbmVzIGluIHguNTA5IGNlcnRpZmljYXRlcw0KPg0K Pg0KPg0KPk1heSBiZSBJIGFtIG1pc3Npbmcgc29tZXRoaW5nIHZlcnkgYmFzaWMuDQo+DQo+SWYg dGhlIGNlcnRpZmljYXRlIGlzIGF2YWlsYWJsZSB0byB0aGUgYXR0YWNrZXIsIGhvdyBkb2VzIHJh bmRvbSBzZXJpYWwgaGVscA0KPmF2b2lkIGEgcHJlZml4IGNvbGxpc2lvbiBhdHRhY2suDQo+DQo+ DQo+DQo+VGhlIGF0dGFja2VyIGp1c3QgZm9yZ2VzIGFub3RoZXIgY2VydGlmaWNhdGUgd2l0aCBz YW1lIHNlcmlhbCBhbmQga2VlcHMgb24NCj5jaGFuZ2luZyBhbiBleHRlbnNpb24gd2l0aCByYW5k b20gdmFsdWUgdG8gZm9yY2UgYSBoYXNoIGNvbGxpc2lvbi4NCj4NCj5XaGV0aGVyIHRoZSBzZXJp YWwgaW4gdGhlIGNlcnRpZmljYXRlIGlzIHJhbmRvbSBvciBub3Qgc2hvdWxkIG5vdCBoYXZlIGFu eQ0KPmltcGFjdCBvbiB0aGUgYWJvdmUgcHJvY2Vzcy4NCj4NCj4NCj4NCj4tUGl5dXNoDQo+DQo+ DQo+DQo+DQo+DQo+RnJvbTogRXJ3YW5uIEFiYWxlYSBbbWFpbHRvOmVhYmFsZWFAZ21haWwuY29t XQ0KPlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMTQsIDIwMTIgMTA6MTcgQU0NCj5UbzogUGl5dXNo IEphaW4NCj5DYzogcGtpeEBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbcGtpeF0gUXVlc3Rpb25p bmcgdGhlIGJlbmVmaXQgb2YgcmFuZG9tIHNlcmlhbHMgb3ZlciBzZXF1ZW50aWFsDQo+b25lcyBp biB4LjUwOSBjZXJ0aWZpY2F0ZXMNCj4NCj4NCj4NCj4NCj4NCj4yMDEyLzEyLzE0IFBpeXVzaCBK YWluIDxwaXl1c2hAZGl0ZW5pdHkuY29tPg0KPg0KPknigJltIG5vdCBzdXJlIHdoYXQgdmFsdWUg ZG9lcyBhIHJvb3QgQ0EgZ2V0cyBvdXQgb2YgdGhpcy4NCj4NCj4NCj4NCj5XaGVuIG1lbnRpb25p bmcgcm9vdCBwcm9ncmFtcywgSSdtIHRhbGtpbmcgYWJvdXQgcm9vdCBpbmNsdXNpb24gaW50byBw dWJsaWMNCj5zb2Z0d2FyZSAoYnJvd3NlcnMsIG1haW5seSksIG5vdCBjZXJ0aWZpY2F0ZXMgaXNz dWVkIGJ5IHRoZSByb290IENBLiBUaGUNCj4icmFuZG9tIHNlcmlhbCIgcmVxdWlyZW1lbnQgaXMg dG8gYmUgYXBwbGllZCB0byBDQSBzb2Z0d2FyZSB0aGF0IGlzc3VlIGVuZC0NCj51c2VyIGNlcnRp ZmljYXRlcy4NCj4NCj4NCj4NCj4JU2luY2UgdGhlIGludGVybWVkaWF0ZSBjZXJ0aWZpY2F0ZXMg KGlzc3VlZCBieSByb290KSBhcmUgYWxzbyBwdWJsaWNseQ0KPnZpc2libGUsIGl0IGRvZXMgbm90 IG1hdHRlciBpZiB0aGUgc2VyaWFsIGlzIHJhbmRvbSBvciBub3QuDQo+DQo+DQo+DQo+VGhpcyBo YXMgbm90aGluZyB0byBkbyB3aXRoIHNlY3JldGx5IGlzc3VlZCBjZXJ0aWZpY2F0ZXMsIGJ1dCB3 aXRoIGtub3duIHByZWZpeA0KPmNvbGxpc2lvbiBhdHRhY2tzLg0KPg0KPg0KPg0KPglJc27igJl0 IGl0IHRydWUgdGhhdCB0aGlzIHdvcmtzIG9ubHkgaWYgdGhlIGF0dGFja2VyIGRvZXMgbm90IGhh dmUgYWNjZXNzIHRvDQo+dGhlIGlzc3VlZCBjZXJ0aWZpY2F0ZT8NCj4NCj4JQXNzdW1pbmcgdGhl IFBLIGNlcnRpZmljYXRlcyBhcmUgbm90IHB1YmxpYyBpcyBzb3J0IG9mIGNvdW50ZXItaW50dWl0 aXZlLg0KPg0KPg0KPg0KPkknbSBub3Qgc3VyZSBJJ20gZm9sbG93aW5nIHlvdS4NCj4NCj5BIGNl cnRpZmljYXRlIGlzIGEgcHVibGljIG9iamVjdCwgZm9yIHN1cmUuDQo+DQo+SSBjYW4ndCBpbWFn aW5lIHdoYXQgY291bGQgYmUgdGhlIHVzZSBvZiBhIENBIHNvZnR3YXJlIGFjY2VwdGluZyBjZXJ0 aWZpY2F0ZQ0KPnJlcXVlc3RzIGJ1dCByZWZ1c2luZyBhY2Nlc3MgdG8gdGhlIGlzc3VlZCBjZXJ0 aWZpY2F0ZS4NCj4NCj4NCj4NCj4JRnJvbTogRXJ3YW5uIEFiYWxlYSBbbWFpbHRvOmVhYmFsZWFA Z21haWwuY29tXQ0KPglTZW50OiBGcmlkYXksIERlY2VtYmVyIDE0LCAyMDEyIDk6MjYgQU0NCj4J VG86IFBpeXVzaCBKYWluDQo+CUNjOiBwa2l4QGlldGYub3JnDQo+CVN1YmplY3Q6IFJlOiBbcGtp eF0gUXVlc3Rpb25pbmcgdGhlIGJlbmVmaXQgb2YgcmFuZG9tIHNlcmlhbHMgb3Zlcg0KPnNlcXVl bnRpYWwgb25lcyBpbiB4LjUwOSBjZXJ0aWZpY2F0ZXMNCj4NCj4NCj4NCj4JQm9uam91ciwNCj4N Cj4JMjAxMi8xMi8xNCBQaXl1c2ggSmFpbiA8cGl5dXNoQGRpdGVuaXR5LmNvbT4NCj4NCj4JSXQg c2VlbXMgdGhhdCB0aGUgY3VycmVudCBiZXN0IHByYWN0aWNlIGlzIHRvIHVzZSBub24tc2VxdWVu dGlhbCBzZXJpYWwNCj4JbnVtYmVycyB3aGVuIGlzc3VpbmcgeC41MDkgY2VydGlmaWNhdGVzLg0K Pg0KPg0KPg0KPglUaGF0J3Mgbm90IG9ubHkgYSAiYmVzdCBwcmFjdGljZSIsIGJ1dCBhbHNvIGEg cmVxdWlyZW1lbnQgZm9yIHNldmVyYWwNCj5yb290IHByb2dyYW1zLg0KPg0KPg0KPg0KPgkJSSB1 bmRlcnN0YW5kIHRoYXQgaXQgaGFkIHNvbWUgdmFsdWUgd2hlbiB3ZWFrIGhhc2hpbmcNCj5hbGdv cml0aG1zIHdlcmUgYmVpbmcNCj4JCXVzZWQgdG8gY3JlYXRlIHRoZSBzaWduYXR1cmUuDQo+DQo+ DQo+DQo+CUl0IHN0aWxsIGhhcyBzb21lIHZhbHVlLCBiZWNhdXNlIHdlYWsgaGFzaCBmdW5jdGlv bnMgYXJlIHN0aWxsIHVzZWQgaW4gYQ0KPnNpZ25hdHVyZSBjb250ZXh0LiBTSEExIGlzbid0IG92 ZXIuDQo+DQo+DQo+DQo+CQlCdXQgaWYgeW91IGFyZSB1c2luZyBhIHN0cm9uZyBoYXNoaW5nIGFs Z29yaXRobSwgd2hhdCBpcyB0aGUNCj5iZW5lZml0IG9mDQo+CQlpc3N1aW5nIGNlcnRpZmljYXRl cyB3aXRoIHJhbmRvbSBzZXJpYWwgdmFsdWVzPw0KPg0KPg0KPg0KPglJIGRvbid0IHNlZSBhbnkg YmVuZWZpdCBpbiBzdWNoIGEgc2l0dWF0aW9uLg0KPg0KPg0KPg0KPgktLQ0KPglFcndhbm4uDQo+ DQo+DQo+DQo+DQo+DQo+DQo+DQo+LS0NCj5Fcndhbm4uDQoNCg== From SChokhani@cygnacom.com Mon Dec 17 06:28:41 2012 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 34E7621F8AA3 for ; Mon, 17 Dec 2012 06:28:41 -0800 (PST) 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 l5+dj2Ydv55B for ; Mon, 17 Dec 2012 06:28:40 -0800 (PST) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 917DB21F86D6 for ; Mon, 17 Dec 2012 06:28:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,300,1355115600"; d="scan'208";a="7217196" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 17 Dec 2012 09:28:37 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 17 Dec 2012 09:28:38 -0500 From: Santosh Chokhani To: "Miller, Timothy J." , "'Kemp, David P.'" , "pkix@ietf.org" Date: Mon, 17 Dec 2012 09:28:33 -0500 Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: Ac3aHP2+k1UCZ+fYR0SXQqG7rwstYAAAsvTgAI6cqEAAAh+c4A== Message-ID: References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <5B1D7E570380A64989D4C069F7D14BC850AF8D4D@clavin.missi.ncsc.mil> <195DB2510AAA004391F58E28FCE21200066FCAEA@IMCMBX01.MITRE.ORG> In-Reply-To: <195DB2510AAA004391F58E28FCE21200066FCAEA@IMCMBX01.MITRE.ORG> 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] Questioning the benefit of random serials over sequential ones in x.509 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, 17 Dec 2012 14:28:41 -0000 No. There is no requirement for SKID in the Standards. It is simply an ad= visory thing. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mil= ler, Timothy J. Sent: Monday, December 17, 2012 8:28 AM To: 'Kemp, David P.'; pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequenti= al ones in x.509 certificates Theoretically, we could dispense with SNs altogether, given a robust SKID. -- T >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of=20 >Kemp, David P. >Sent: Friday, December 14, 2012 12:34 PM >To: pkix@ietf.org >Subject: Re: [pkix] Questioning the benefit of random serials over=20 >sequential ones in x.509 certificates > >Sparse namespaces are generic good security hygiene. Data mining, like=20 >telemarketer robocalling, is enabled by compact namespaces, and the=20 >large random-looking URLs employed by, e.g., photo sharing websites are=20 >an attempt to make mining more difficult. > >If the only way to retrieve a certificate from a directory or web=20 >repository is to know its name or serial number, then making valid S/Ns=20 >difficult to guess makes trawling more difficult and easier to detect. > >Dave > > >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of=20 >Piyush Jain >Sent: Friday, December 14, 2012 12:09 PM >To: pkix@ietf.org >Subject: [pkix] Questioning the benefit of random serials over=20 >sequential ones in x.509 certificates > >Hi All, > >It seems that the current best practice is to use non-sequential serial=20 >numbers when issuing x.509 certificates. > >I understand that it had some value when weak hashing algorithms were=20 >being used to create the signature. >But if you are using a strong hashing algorithm, what is the benefit of=20 >issuing certificates with random serial values? > >Thanks a lot in advance for any insights. > >-Piyush > >_______________________________________________ >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 piyush@ditenity.com Mon Dec 17 06:39:02 2012 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 CCD3C21F8AF8 for ; Mon, 17 Dec 2012 06:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 rRx6Ap4ygaSV for ; Mon, 17 Dec 2012 06:39:02 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B27621F8AE5 for ; Mon, 17 Dec 2012 06:39:01 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so5957407oag.31 for ; Mon, 17 Dec 2012 06:39:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=DOtMj4KY/H2sgqMATMl2PfHPDn6LP+Z+cPOF8Yq3vQ8=; b=FVLz05fG9uPanNtZapVVtLxwsIOduFMwxiKn5iJZ1oWIRCZtnRhhBcpiuXP1NNCaON cmjBJrxIOwlRwXS9lzUfUaHpg04s9k2QDbmlGZylBAsWrlr4DkTckhuOiLqVNCE9W6lb hqwdIdPTja1VTYMFX3/WZt58BVRvwbmAt5hnqdVNeREgA1ZU4N7r3VkfHw/fc0pCZpXP zBRsyEeEP3Y85e2E/qCo4WJmYJcCwVI/3Lc0VOAew3+GtImpL1z1q3P83D11gGSs0P+m oGw5UNUyhdoD5wcVCArWhbwGX34z4MMeMW+PH/mGSXeK6JUbgrbsw9EhNRfPBYJvCBks KPAw== Received: by 10.60.31.39 with SMTP id x7mr12023795oeh.45.1355755141468; Mon, 17 Dec 2012 06:39:01 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id q4sm9776752obz.3.2012.12.17.06.39.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Dec 2012 06:39:00 -0800 (PST) From: "Piyush Jain" To: "'Bruce Stephens'" , References: <80vcc1ufzb.fsf@tinier.isode.net> In-Reply-To: <80vcc1ufzb.fsf@tinier.isode.net> Date: Mon, 17 Dec 2012 06:38:57 -0800 Message-ID: <038a01cddc64$3fe1b7d0$bfa52770$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGQjvjkwZnJqwMxEY68Ai+iTCk4G5iXqWgw Content-Language: en-us X-Gm-Message-State: ALoCoQlmKkUvd/s+kDgXVNpZJSHcMpLI7ED1sw3f/DEa6tImeRNyBgRiia/boYxxblzla1LWY7+S Subject: Re: [pkix] Advice on (small amounts of) clock skew? 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, 17 Dec 2012 14:39:02 -0000 A few products that I have worked with had the option to configure a value for clock skew. If the time difference between the current time and thisUpdate on the CRL was less than this configured value, CRL was considered valid. -Piyush > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Bruce Stephens > Sent: Monday, December 17, 2012 2:32 AM > To: pkix@ietf.org > Subject: [pkix] Advice on (small amounts of) clock skew? > > Specifically, the NIST PIV infrastructure has CRLs (and presigned OCSP > responses) issued hourly (though the CRLs at least last for a day), and that > caused unexpected problems when testing: a non-trivial amount of the time, > the CRLs were not yet valid. > > If it was that the nextUpdate time had passed, then there's advice in RFC > 5280 (one should try and get a new CRL or delta CRL, but (depending on local > situations) continuing to use the CRL may well be appropriate), but I don't > see any suggestions on what to do if it appears that the CRL isn't yet valid. (I > suppose waiting is one option...) > > (SDN.705 gives guidance for X.500, but only for bind tokens and the like. I > imagine SDN.706 offers something for certificates and CRLs, but I haven't > seen that.) _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From turners@ieca.com Mon Dec 17 07:03:54 2012 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 2DCF521F8B15 for ; Mon, 17 Dec 2012 07:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.942 X-Spam-Level: X-Spam-Status: No, score=-101.942 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVw0eHYwU-jm for ; Mon, 17 Dec 2012 07:03:53 -0800 (PST) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.93.82.3]) by ietfa.amsl.com (Postfix) with ESMTP id 6E44B21F8B12 for ; Mon, 17 Dec 2012 07:03:53 -0800 (PST) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 74C0AC061DBFB; Mon, 17 Dec 2012 09:03:16 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 5ADE0C061DB54 for ; Mon, 17 Dec 2012 09:03:16 -0600 (CST) Received: from [108.45.19.185] (port=57477 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TkcDu-0005UB-GN for pkix@ietf.org; Mon, 17 Dec 2012 09:03:18 -0600 Message-ID: <50CF3435.9020403@ieca.com> Date: Mon, 17 Dec 2012 10:03:17 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: pkix@ietf.org References: <20121205220801.25486.73072.idtracker@ietfa.amsl.com> In-Reply-To: <20121205220801.25486.73072.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121205220801.25486.73072.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:57477 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [pkix] Fwd: Last Call: (Diffie-Hellman Proof-of-Possession Algorithms) to Proposed Standard 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, 17 Dec 2012 15:03:54 -0000 Some on this list might be interested about this draft. Please send any comments to ietf@ietf.org. spt -------- Original Message -------- Subject: Last Call: (Diffie-Hellman Proof-of-Possession Algorithms) to Proposed Standard Date: Wed, 05 Dec 2012 14:08:01 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'Diffie-Hellman Proof-of-Possession Algorithms' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a PKCS #10 certification request. These algorithms are designed to provide a proof-of-possession rather than general purpose signing. This document obsoletes RFC 2875. The file can be obtained via http://datatracker.ietf.org/doc/draft-schaad-pkix-rfc2875-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-schaad-pkix-rfc2875-bis/ballot/ No IPR declarations have been submitted directly on this I-D. From tmiller@mitre.org Mon Dec 17 08:38:19 2012 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 D88C421F8509 for ; Mon, 17 Dec 2012 08:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 GYL45TJsr28w for ; Mon, 17 Dec 2012 08:38:19 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD3C21F8505 for ; Mon, 17 Dec 2012 08:38:19 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5DDFF1F037B; Mon, 17 Dec 2012 11:38:18 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 508141F08A4; Mon, 17 Dec 2012 11:38:18 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 11:38:17 -0500 From: "Miller, Timothy J." To: 'Santosh Chokhani' , "'Kemp, David P.'" , "pkix@ietf.org" Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: Ac3aHP2+k1UCZ+fYR0SXQqG7rwstYAAAsvTgAI6cqEAAAh+c4AAEiFjA Date: Mon, 17 Dec 2012 16:38:17 +0000 Message-ID: <195DB2510AAA004391F58E28FCE21200066FCCD8@IMCMBX01.MITRE.ORG> References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <5B1D7E570380A64989D4C069F7D14BC850AF8D4D@clavin.missi.ncsc.mil> <195DB2510AAA004391F58E28FCE21200066FCAEA@IMCMBX01.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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, 17 Dec 2012 16:38:20 -0000 There comes a time when even standards should change. I'm not advocating, = I'm just pointing it out. -- T >-----Original Message----- >From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] >Sent: Monday, December 17, 2012 9:29 AM >To: Miller, Timothy J.; 'Kemp, David P.'; pkix@ietf.org >Subject: RE: [pkix] Questioning the benefit of random serials over sequent= ial >ones in x.509 certificates > >No. There is no requirement for SKID in the Standards. It is simply an a= dvisory >thing. > >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Miller, Timothy J. >Sent: Monday, December 17, 2012 8:28 AM >To: 'Kemp, David P.'; pkix@ietf.org >Subject: Re: [pkix] Questioning the benefit of random serials over sequent= ial >ones in x.509 certificates > >Theoretically, we could dispense with SNs altogether, given a robust SKID. > >-- T > >>-----Original Message----- >>From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>Kemp, David P. >>Sent: Friday, December 14, 2012 12:34 PM >>To: pkix@ietf.org >>Subject: Re: [pkix] Questioning the benefit of random serials over >>sequential ones in x.509 certificates >> >>Sparse namespaces are generic good security hygiene. Data mining, like >>telemarketer robocalling, is enabled by compact namespaces, and the >>large random-looking URLs employed by, e.g., photo sharing websites are >>an attempt to make mining more difficult. >> >>If the only way to retrieve a certificate from a directory or web >>repository is to know its name or serial number, then making valid S/Ns >>difficult to guess makes trawling more difficult and easier to detect. >> >>Dave >> >> >>-----Original Message----- >>From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>Piyush Jain >>Sent: Friday, December 14, 2012 12:09 PM >>To: pkix@ietf.org >>Subject: [pkix] Questioning the benefit of random serials over >>sequential ones in x.509 certificates >> >>Hi All, >> >>It seems that the current best practice is to use non-sequential serial >>numbers when issuing x.509 certificates. >> >>I understand that it had some value when weak hashing algorithms were >>being used to create the signature. >>But if you are using a strong hashing algorithm, what is the benefit of >>issuing certificates with random serial values? >> >>Thanks a lot in advance for any insights. >> >>-Piyush >> >>_______________________________________________ >>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 piyush@ditenity.com Mon Dec 17 09:05:26 2012 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 78DDC21F8B6C for ; Mon, 17 Dec 2012 09:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 4jniD3OTbc6H for ; Mon, 17 Dec 2012 09:05:25 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C246C21F8B66 for ; Mon, 17 Dec 2012 09:05:25 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so5944464obc.31 for ; Mon, 17 Dec 2012 09:05:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=BETdhTRQ0V/KmJv9P3a9lQtj3J3UMQZTULyvu+82ghk=; b=NgOw11izqRT8U3oVKb7X9mSPlEffbNsN6OuyxQXh9dpnn5vcQK0AytzcfVrUo6XSGq IMsMBtoNpo9/3OzCfl+0y/tf0JongWJZcVb4YyOes5rCAv8REjm6OOSTD3aIYZCgNTmH p1CyXcw/8+iPzRsAOPLS0N3FDsd0eTpXZmSpcl8wlBUcQV8CEAKM3vPjiFHZQAUI5fym GsA5+dEQwru4A4ZQcjtxdG0v3Aiw1ypJhS3t6sk/w74LEViksyQadzvsuL79T3nC5Wqi fnjky8C2KYJGk+IguJDJ3DymtJRTLJ8O5sDyO4XMv0nCzRD5LtRo2f8Qhp7sLJEl3cw2 Nkyg== Received: by 10.60.31.8 with SMTP id w8mr12430701oeh.55.1355763925261; Mon, 17 Dec 2012 09:05:25 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id ag15sm10227097oec.11.2012.12.17.09.05.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Dec 2012 09:05:24 -0800 (PST) From: "Piyush Jain" To: "'Miller, Timothy J.'" , "'Santosh Chokhani'" , "'Kemp, David P.'" , References: <041f01cdda1d$c3a5eb70$4af1c250$@ditenity.com> <5B1D7E570380A64989D4C069F7D14BC850AF8D4D@clavin.missi.ncsc.mil> <195DB2510AAA004391F58E28FCE21200066FCAEA@IMCMBX01.MITRE.ORG> <195DB2510AAA004391F58E28FCE21200066FCCD8@IMCMBX01.MITRE.ORG> In-Reply-To: <195DB2510AAA004391F58E28FCE21200066FCCD8@IMCMBX01.MITRE.ORG> Date: Mon, 17 Dec 2012 09:05:19 -0800 Message-ID: <00c101cddc78$b2899640$179cc2c0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHRlKs7YuWAK+X+fx67nstxV6bEfQHPydwdAq+uRF4CD46BOQIyE/e5l8++WzA= Content-Language: en-us X-Gm-Message-State: ALoCoQlObHSnzKonMjrk+XdOLNe6cD0XbVKQ0JiH+yK0prRcYvdsT6+hooF8GlwJRSTS1T4A+Awt Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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, 17 Dec 2012 17:05:26 -0000 I think the problem with using SKID is that key life is different from cert life. So using keyed as a way to identify a cert could be problematic in cert rollover scenarios or in situation where you have multiple certificates associated with same key. > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Miller, Timothy J. > Sent: Monday, December 17, 2012 8:38 AM > To: 'Santosh Chokhani'; 'Kemp, David P.'; pkix@ietf.org > Subject: Re: [pkix] Questioning the benefit of random serials over sequential > ones in x.509 certificates > > There comes a time when even standards should change. I'm not > advocating, I'm just pointing it out. > > -- T > > >-----Original Message----- > >From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > >Sent: Monday, December 17, 2012 9:29 AM > >To: Miller, Timothy J.; 'Kemp, David P.'; pkix@ietf.org > >Subject: RE: [pkix] Questioning the benefit of random serials over > >sequential ones in x.509 certificates > > > >No. There is no requirement for SKID in the Standards. It is simply > >an advisory thing. > > > >-----Original Message----- > >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > >Miller, Timothy J. > >Sent: Monday, December 17, 2012 8:28 AM > >To: 'Kemp, David P.'; pkix@ietf.org > >Subject: Re: [pkix] Questioning the benefit of random serials over > >sequential ones in x.509 certificates > > > >Theoretically, we could dispense with SNs altogether, given a robust SKID. > > > >-- T > > > >>-----Original Message----- > >>From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf > >>Of Kemp, David P. > >>Sent: Friday, December 14, 2012 12:34 PM > >>To: pkix@ietf.org > >>Subject: Re: [pkix] Questioning the benefit of random serials over > >>sequential ones in x.509 certificates > >> > >>Sparse namespaces are generic good security hygiene. Data mining, > >>like telemarketer robocalling, is enabled by compact namespaces, and > >>the large random-looking URLs employed by, e.g., photo sharing > >>websites are an attempt to make mining more difficult. > >> > >>If the only way to retrieve a certificate from a directory or web > >>repository is to know its name or serial number, then making valid > >>S/Ns difficult to guess makes trawling more difficult and easier to detect. > >> > >>Dave > >> > >> > >>-----Original Message----- > >>From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf > >>Of Piyush Jain > >>Sent: Friday, December 14, 2012 12:09 PM > >>To: pkix@ietf.org > >>Subject: [pkix] Questioning the benefit of random serials over > >>sequential ones in x.509 certificates > >> > >>Hi All, > >> > >>It seems that the current best practice is to use non-sequential > >>serial numbers when issuing x.509 certificates. > >> > >>I understand that it had some value when weak hashing algorithms were > >>being used to create the signature. > >>But if you are using a strong hashing algorithm, what is the benefit > >>of issuing certificates with random serial values? > >> > >>Thanks a lot in advance for any insights. > >> > >>-Piyush > >> > >>_______________________________________________ > >>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 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Mon Dec 17 11:34:20 2012 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 0851621F8848 for ; Mon, 17 Dec 2012 11:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.032 X-Spam-Level: X-Spam-Status: No, score=-10.032 tagged_above=-999 required=5 tests=[AWL=0.217, 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 c8e7Ywb-WN+p for ; Mon, 17 Dec 2012 11:34:19 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DA06821F8661 for ; Mon, 17 Dec 2012 11:34:18 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qBHJYEok013438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Dec 2012 20:34:14 +0100 (MET) In-Reply-To: To: Erwann Abalea Date: Mon, 17 Dec 2012 20:34:14 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121217193414.A5EAC1A402@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates 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: Mon, 17 Dec 2012 19:34:20 -0000 Erwann Abalea wrote: > > >> >> Whether the serial in the certificate is random or not should not have any >> impact on the above process. > > You should read http://www.win.tue.nl/hashclash/rogue-ca/ > It's well written. +1 > >> May be I am missing something very basic.**** I believe you do (about the type of attack, collision vs. pre-image). >> >> If the certificate is available to the attacker, how does random serial >> help avoid a prefix collision attack.**** I increases the work-factor for the attacker for pre-computing collisions, but does not quite prevent the attack. I believe that having the CA insert a dummy non-critical extension with a strong random 128+ bit random OctetString would achieve better protection without abusing/spoiling the serial numbers. >> >> The attacker just forges another certificate with same serial and keeps on >> changing an extension with random value to force a hash collision. The key point in understanding the "rogue CA" attack is, that under the special conditions of CA cert issuance, creating a pair of [validly issued cert, rogue cert] can be made to succeed for a hash collision with a chosen internal hash state, it is _unnecessary_ to succeed a preimage attack. If all of what the CA adds when issuing a cert is static and pre-known, then it is up to the attacker to make a part of the key (such as the RSA public modulus) collide with a part of an adequately tailored rogue cert, and submit a certification request with the hash-colliding key parameter. -Martin From SChokhani@cygnacom.com Mon Dec 17 11:39:48 2012 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 7EFFE21F8897 for ; Mon, 17 Dec 2012 11:39:48 -0800 (PST) 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 5iGFEDPTP5vm for ; Mon, 17 Dec 2012 11:39:47 -0800 (PST) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id D0CA621F8555 for ; Mon, 17 Dec 2012 11:39:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,304,1355115600"; d="scan'208";a="2705158" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 17 Dec 2012 14:39:46 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 17 Dec 2012 14:39:45 -0500 From: Santosh Chokhani To: "mrex@sap.com" , Erwann Abalea Date: Mon, 17 Dec 2012 14:39:45 -0500 Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: Ac3cjYWVSQSjNDjeSpCAQ047ZWvF8AAAEfug Message-ID: References: <20121217193414.A5EAC1A402@ld9781.wdf.sap.corp> In-Reply-To: <20121217193414.A5EAC1A402@ld9781.wdf.sap.corp> 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" Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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, 17 Dec 2012 19:39:48 -0000 Others have suggested adding an extension to defeat the collision attack. It shows lack of understanding of the attack. You can put as many extensions as you like and put as many random number as= you wish in them, they WILL NOT defeat the prefix attack as long as the si= ze of those extension is known. All of that junk will go in the so called = tumor. If the size of the extension itself and hence the size of the certificate i= tself changes, that mitigates the threat somewhat, but that is a silly loga= rithmic benefit.=20 -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mar= tin Rex Sent: Monday, December 17, 2012 2:34 PM To: Erwann Abalea Cc: pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequenti= al ones in x.509 certificates Erwann Abalea wrote: >=20 > >> >> Whether the serial in the certificate is random or not should not=20 >> have any impact on the above process. >=20 > You should read http://www.win.tue.nl/hashclash/rogue-ca/ > It's well written. +1 > >> May be I am missing something very basic.**** I believe you do (about the type of attack, collision vs. pre-image). >> >> If the certificate is available to the attacker, how does random=20 >> serial help avoid a prefix collision attack.**** I increases the work-factor for the attacker for pre-computing collisions, = but does not quite prevent the attack. I believe that having the CA insert a dummy non-critical extension with a s= trong random 128+ bit random OctetString would achieve better protection wi= thout abusing/spoiling the serial numbers. >> >> The attacker just forges another certificate with same serial and=20 >> keeps on changing an extension with random value to force a hash collisi= on. The key point in understanding the "rogue CA" attack is, that under the spe= cial conditions of CA cert issuance, creating a pair of [validly issued ce= rt, rogue cert] can be made to succeed for a hash collision with a chosen i= nternal hash state, it is _unnecessary_ to succeed a preimage attack. If all of what the CA adds when issuing a cert is static and pre-known, the= n it is up to the attacker to make a part of the key (such as the RSA publi= c modulus) collide with a part of an adequately tailored rogue cert, and su= bmit a certification request with the hash-colliding key parameter. -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Mon Dec 17 12:10:09 2012 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 A0C5421F885E for ; Mon, 17 Dec 2012 12:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.063 X-Spam-Level: X-Spam-Status: No, score=-10.063 tagged_above=-999 required=5 tests=[AWL=0.186, 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 TWLAYMzHX7Jm for ; Mon, 17 Dec 2012 12:10:07 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9A721F885C for ; Mon, 17 Dec 2012 12:10:07 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id qBHKA0Jd019926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Dec 2012 21:10:00 +0100 (MET) In-Reply-To: To: Santosh Chokhani Date: Mon, 17 Dec 2012 21:10:00 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121217201000.587C71A402@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates 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: Mon, 17 Dec 2012 20:10:09 -0000 Santosh Chokhani wrote: > > Others have suggested adding an extension to defeat the collision attack. > > It shows lack of understanding of the attack. I believe that is incorrect. > > You can put as many extensions as you like and put as many random number > as you wish in them, they WILL NOT defeat the prefix attack as long as > the size of those extension is known. All of that junk will go in the > so called tumor. There is no "tumor" in the *REAL* (validly issued) certificate. That blob only exists in the rogue cert of the pair. (Looking at the picture in Section 5.3 of this page: http://www.win.tue.nl/hashclash/rogue-ca/ ) The reason is, that everything that the real CA puts into the ToBeSigned part of a cert is covered by the hash of the CA-created digital signature. -Martin From SChokhani@cygnacom.com Mon Dec 17 12:15:01 2012 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 F1AB321F88A9 for ; Mon, 17 Dec 2012 12:15:00 -0800 (PST) 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 MtlbmVNinBb3 for ; Mon, 17 Dec 2012 12:15:00 -0800 (PST) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id ECCF821F88A3 for ; Mon, 17 Dec 2012 12:14:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,304,1355115600"; d="scan'208";a="2705532" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 17 Dec 2012 15:14:59 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 17 Dec 2012 15:14:59 -0500 From: Santosh Chokhani To: "mrex@sap.com" Date: Mon, 17 Dec 2012 15:14:58 -0500 Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: Ac3ckn9SI7KYE7/nT3Wni8SOXMhhzQAAGfQQ Message-ID: References: <20121217201000.587C71A402@ld9781.wdf.sap.corp> In-Reply-To: <20121217201000.587C71A402@ld9781.wdf.sap.corp> 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" Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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, 17 Dec 2012 20:15:01 -0000 The tumor in the rogue certificate is why the collision attack is not defea= ted by adding an extension whose size is known. The actual certificate and= the rogue certificate hashes will continue to match. Have you read Lenstra paper? Do you get it? -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Monday, December 17, 2012 3:10 PM To: Santosh Chokhani Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequenti= al ones in x.509 certificates Santosh Chokhani wrote: > > Others have suggested adding an extension to defeat the collision attack. >=20 > It shows lack of understanding of the attack. I believe that is incorrect. >=20 > You can put as many extensions as you like and put as many random=20 > number as you wish in them, they WILL NOT defeat the prefix attack as=20 > long as the size of those extension is known. All of that junk will=20 > go in the so called tumor. There is no "tumor" in the *REAL* (validly issued) certificate. That blob only exists in the rogue cert of the pair. (Looking at the picture in Section 5.3 of this page: http://www.win.tue.nl/hashclash/rogue-ca/ ) The reason is, that everything that the real CA puts into the ToBeSigned pa= rt of a cert is covered by the hash of the CA-created digital signature. -Martin From mrex@sap.com Mon Dec 17 12:21:52 2012 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 E757621F88B6 for ; Mon, 17 Dec 2012 12:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.086 X-Spam-Level: X-Spam-Status: No, score=-10.086 tagged_above=-999 required=5 tests=[AWL=0.163, 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 KBZSohC1B0iu for ; Mon, 17 Dec 2012 12:21:52 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8ED21F88A9 for ; Mon, 17 Dec 2012 12:21:51 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id qBHKLnPx021057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Dec 2012 21:21:49 +0100 (MET) In-Reply-To: <20121217201000.587C71A402@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Mon, 17 Dec 2012 21:21:49 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121217202149.274021A402@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates 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: Mon, 17 Dec 2012 20:21:53 -0000 OK, you were correct. What your probably meant (but I didn't understand) is that the octets representing the extensions which the CA includes in the cert, are still present 1:1 in the rogue cert, but due to how ASN.1 DER encoding works, these attributes are no longer active since they're inside the body part of an unrecognized extension (the "tumor") in the rogue cert. So the part of the rogue cert, that contains the CA-supplied extensions and the actual CA signature, becomes known when the CA issues the cert, and its contents do otherwise not impair the creation of the rogue cert. I'm sorry for the confusion. -Martin Martin Rex wrote: > Santosh Chokhani wrote: > > > > Others have suggested adding an extension to defeat the collision attack. > > > > It shows lack of understanding of the attack. > > I believe that is incorrect. > > > > > > You can put as many extensions as you like and put as many random number > > as you wish in them, they WILL NOT defeat the prefix attack as long as > > the size of those extension is known. All of that junk will go in the > > so called tumor. > > There is no "tumor" in the *REAL* (validly issued) certificate. > That blob only exists in the rogue cert of the pair. > > (Looking at the picture in Section 5.3 of this page: > http://www.win.tue.nl/hashclash/rogue-ca/ ) > > > The reason is, that everything that the real CA puts into the ToBeSigned > part of a cert is covered by the hash of the CA-created digital signature. > > > -Martin From SChokhani@cygnacom.com Mon Dec 17 12:26:09 2012 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 1709D21F88B6 for ; Mon, 17 Dec 2012 12:26:09 -0800 (PST) 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 8k8WD4RJMEX5 for ; Mon, 17 Dec 2012 12:26:08 -0800 (PST) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4903B21F87D2 for ; Mon, 17 Dec 2012 12:26:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,304,1355115600"; d="scan'208";a="7223163" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 17 Dec 2012 15:26:07 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 17 Dec 2012 15:26:07 -0500 From: Santosh Chokhani To: "mrex@sap.com" Date: Mon, 17 Dec 2012 15:26:06 -0500 Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: Ac3clCWeQujWX7AWRhyEJJPmtw3zgAAAEC6g Message-ID: References: <20121217201000.587C71A402@ld9781.wdf.sap.corp> <20121217202149.274021A402@ld9781.wdf.sap.corp> In-Reply-To: <20121217202149.274021A402@ld9781.wdf.sap.corp> 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" Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 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, 17 Dec 2012 20:26:09 -0000 Yes, except "active" is a red herring again. If you are throwing in random= meaningless extensions, RP is not going to check them and hence active and= passive is not a meaningless distinction. The basic thing to understand is that the subject DN is the first input fro= m the user and it has potential for sufficient fidelity that unless you put= randomness before the subject DN, you are inviting trouble. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Monday, December 17, 2012 3:22 PM To: mrex@sap.com Cc: Santosh Chokhani; Erwann Abalea; pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequenti= al ones in x.509 certificates OK, you were correct. What your probably meant (but I didn't understand) is that the octets repre= senting the extensions which the CA includes in the cert, are still present= 1:1 in the rogue cert, but due to how ASN.1 DER encoding works, these attr= ibutes are no longer active since they're inside the body part of an unreco= gnized extension (the "tumor") in the rogue cert. So the part of the rogue cert, that contains the CA-supplied extensions and= the actual CA signature, becomes known when the CA issues the cert, and it= s contents do otherwise not impair the creation of the rogue cert. I'm sorry for the confusion. -Martin Martin Rex wrote: > Santosh Chokhani wrote: > > > > Others have suggested adding an extension to defeat the collision attac= k. > >=20 > > It shows lack of understanding of the attack. >=20 > I believe that is incorrect. >=20 >=20 > >=20 > > You can put as many extensions as you like and put as many random=20 > > number as you wish in them, they WILL NOT defeat the prefix attack=20 > > as long as the size of those extension is known. All of that junk=20 > > will go in the so called tumor. >=20 > There is no "tumor" in the *REAL* (validly issued) certificate. > That blob only exists in the rogue cert of the pair. >=20 > (Looking at the picture in Section 5.3 of this page: > http://www.win.tue.nl/hashclash/rogue-ca/ ) >=20 >=20 > The reason is, that everything that the real CA puts into the=20 > ToBeSigned part of a cert is covered by the hash of the CA-created digita= l signature. >=20 >=20 > -Martin From mrex@sap.com Mon Dec 17 18:59:23 2012 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 9147D21E8040 for ; Mon, 17 Dec 2012 18:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.105 X-Spam-Level: X-Spam-Status: No, score=-10.105 tagged_above=-999 required=5 tests=[AWL=0.144, 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 3hO6oAo6KRpQ for ; Mon, 17 Dec 2012 18:59:23 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id BAF5321E8037 for ; Mon, 17 Dec 2012 18:59:22 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id qBI2xIqO011540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Dec 2012 03:59:18 +0100 (MET) In-Reply-To: To: Santosh Chokhani Date: Tue, 18 Dec 2012 03:59:18 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121218025918.18FC91A402@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates 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: Tue, 18 Dec 2012 02:59:23 -0000 Santosh Chokhani wrote: > > Yes, except "active" is a red herring again. > If you are throwing in random meaningless extensions, RP is not going to > check them and hence active and passive is not a meaningless distinction. > > The basic thing to understand is that the subject DN is the first input > from the user and it has potential for sufficient fidelity that unless > you put randomness before the subject DN, you are inviting trouble. IMHO the thing to understand is that the composition, field ordering and fairly unlimited extensibility of X.509v3 is what enables a mere collision attack (with two distinct internal states) to achieve what would normally require a 2nd preimage attack. Looking at TBSCertificate: TBSCertificate ::= SEQUENCE { version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 extensions [3] Extensions OPTIONAL -- If present, version MUST be v3 -- } maybe the AlgorithmIdententifier is finally not as useless as I thought. If there was more support for RSA-PSS (aka PKCS#1 v2.1) signatures in the installed base, the CA would be able to sign the EE-Cert with a RSA-PSS AlgId that has a random, hash-sized salt in the signature AlgorithmIdentifier parameters field... -Martin From hotz@jpl.nasa.gov Tue Dec 18 17:34:26 2012 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 CE8D021F857D for ; Tue, 18 Dec 2012 17:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRI3qNKNBhyK for ; Tue, 18 Dec 2012 17:34:26 -0800 (PST) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 4B00921F8473 for ; Tue, 18 Dec 2012 17:34:26 -0800 (PST) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBJ1YNpW018061 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 18 Dec 2012 17:34:24 -0800 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <038a01cddc64$3fe1b7d0$bfa52770$@ditenity.com> Date: Tue, 18 Dec 2012 17:34:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <275AFE3E-1B1D-4EA4-A90E-047110F4AFFF@jpl.nasa.gov> References: <80vcc1ufzb.fsf@tinier.isode.net> <038a01cddc64$3fe1b7d0$bfa52770$@ditenity.com> To: Piyush Jain X-Mailer: Apple Mail (2.1085) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: pkix@ietf.org Subject: Re: [pkix] Advice on (small amounts of) clock skew? 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, 19 Dec 2012 01:34:26 -0000 If the service consuming certs is actually critical, then would you = *ever* shut it down just because you couldn't get a fresh CRL? That = makes for a pretty easy DOS, and if it's critical, then protection from = DOS is important. =20 In fact I now even have operational statistics that say network outages = are way, way more likely than use of a revoked credential with one = service I run. (Admittedly, it's not in full production yet.) On Dec 17, 2012, at 6:38 AM, Piyush Jain wrote: > A few products that I have worked with had the option to configure a = value > for clock skew. > If the time difference between the current time and thisUpdate on the = CRL > was less than this configured value, CRL was considered valid. >=20 > -Piyush >=20 >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of >> Bruce Stephens >> Sent: Monday, December 17, 2012 2:32 AM >> To: pkix@ietf.org >> Subject: [pkix] Advice on (small amounts of) clock skew? >>=20 >> Specifically, the NIST PIV infrastructure has CRLs (and presigned = OCSP >> responses) issued hourly (though the CRLs at least last for a day), = and > that >> caused unexpected problems when testing: a non-trivial amount of the = time, >> the CRLs were not yet valid. >>=20 >> If it was that the nextUpdate time had passed, then there's advice in = RFC >> 5280 (one should try and get a new CRL or delta CRL, but (depending = on > local >> situations) continuing to use the CRL may well be appropriate), but I > don't >> see any suggestions on what to do if it appears that the CRL isn't = yet > valid. (I >> suppose waiting is one option...) >>=20 >> (SDN.705 gives guidance for X.500, but only for bind tokens and the = like. > I >> imagine SDN.706 offers something for certificates and CRLs, but I = haven't >> seen that.) _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From egerck@nma.com Tue Dec 18 18:01:23 2012 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 26AC621F869E for ; Tue, 18 Dec 2012 18:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYOEw7X1-whr for ; Tue, 18 Dec 2012 18:01:22 -0800 (PST) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id 245BB21F8667 for ; Tue, 18 Dec 2012 18:01:21 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id ro12so838025pbb.38 for ; Tue, 18 Dec 2012 18:01:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=8wtqY/KNKBUeHkh3YkqZExdDRYEQkGBEFfut7su3jiI=; b=JTJN81h2IL6IbJvPIR/+xnDgjjsmXX3mC3ZGacXJbLxLN2ov+KFZXw/d6Lvd2fMTKo zRkr+Yn1CzJXnxjU2s3tEYJrujtRSxyrvIoKG+FjGSXdI8DgkhmGBxlvf1cUuCrA4N2N ZZNx78VU1SnYhKmuBSf1JwOTqmmFAI4TrQ16nZ9Tdmy4vgbZnjt1NV7euebpPu7cTjD6 DrwuwcVPUiLx7sG4tQbheDZzLJJkVLVP8GRmZFnf/kJiSAoQqnWGELAuBGFSOLpp5hXy +gRAl/IIV7UMbmiSmAFlt9Qaq3f3pZQ4Wx1QQ/IF0lK1l7rFJhpD97RkI6FWyGZRIkDl ai7g== X-Received: by 10.68.143.162 with SMTP id sf2mr12795774pbb.137.1355882481752; Tue, 18 Dec 2012 18:01:21 -0800 (PST) Received: from [172.16.1.100] ([99.145.106.177]) by mx.google.com with ESMTPS id wh8sm2109351pbc.75.2012.12.18.18.01.20 (version=SSLv3 cipher=OTHER); Tue, 18 Dec 2012 18:01:20 -0800 (PST) Message-ID: <50D11FEC.7020607@nma.com> Date: Tue, 18 Dec 2012 18:01:16 -0800 From: "Ed Gerck, Ph.D." User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: pkix@ietf.org References: <80vcc1ufzb.fsf@tinier.isode.net> <038a01cddc64$3fe1b7d0$bfa52770$@ditenity.com> <275AFE3E-1B1D-4EA4-A90E-047110F4AFFF@jpl.nasa.gov> In-Reply-To: <275AFE3E-1B1D-4EA4-A90E-047110F4AFFF@jpl.nasa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQltllQ269gEU4VNVonz/cphBaA9ZsQtgM8/BZU4JkCkjGi6HTlxsLgfb79xhf6v9M/nMi7u Subject: Re: [pkix] Advice on (small amounts of) clock skew? 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, 19 Dec 2012 02:01:23 -0000 Henry B. Hotz wrote: > If the service consuming certs is actually critical, then would you *ever* shut it down just because you couldn't get a fresh CRL? That makes for a pretty easy DOS, and if it's critical, then protection from DOS is important. I suggest that a clock variance (skew) that the RP can accept, and taking into account the issuer's and validator's operational conditions, is to be preferred over declaring it to be exactly zero -- which is *certainly* the least-likely answer. If you can't get a fresh CRL and there is no clock variance that is acceptable, then shutdown may be mandatory although not needed because, as we know, DoS can be effective to compromise information when users cannot be trusted (as they should not be, as a rule). For example, as seen in an unfortunate sport news recently, when the police dispatcher over the radio asks the officer in a patrol car if the "digital is on" before sending the suspect's private information, the officer responds something like: "at this point, forget about encryption and just send me information using voice". The recording is available online. > In fact I now even have operational statistics that say network outages are way, way more likely than use of a revoked credential with one service I run. (Admittedly, it's not in full production yet.) Those are different risks, as apples and speedboats. The risk of a network outage is "no signal" whereas the risk of an incorrect CRL can be a false approval. A higher risk of the former can be easily reduced by adequate redundancy. Best regards, Ed Gerck From pgut001@cs.auckland.ac.nz Tue Dec 18 18:05:40 2012 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 87E4B21E8034 for ; Tue, 18 Dec 2012 18:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzePTB2phRf0 for ; Tue, 18 Dec 2012 18:05:39 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDE021E8030 for ; Tue, 18 Dec 2012 18:05:39 -0800 (PST) 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=1355882739; x=1387418739; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BQvf7zs/neybzYRfvCiZdJAr8pcfoPKCrGny7KXrCkQ=; b=Z4jMN2xN6kPFb2Y81KdSXoi56rn2w93kU5vE3/uCE3BBUeRVSZNOS+ob 4F2nUzuof/eNxKGId38JnmkSDIC5e+e56c7CfjWweChn2ARM6GqR7jRQP kppxlQsWwvQs14peqvMDajI93CvkPVG3X8P3HDFaihv9dvCniFsgbw5FH U=; X-IronPort-AV: E=Sophos;i="4.84,313,1355050800"; d="scan'208";a="162900826" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 Dec 2012 15:05:38 +1300 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe2.UoA.auckland.ac.nz (130.216.4.106) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 19 Dec 2012 15:05:38 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.118]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 15:05:38 +1300 From: Peter Gutmann To: "pkix@ietf.org" Thread-Topic: [pkix] Advice on (small amounts of) clock skew? Thread-Index: Ac3djVaAyBza2nFIRU6Z/70yGscHWg== Date: Wed, 19 Dec 2012 02:05:37 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73333AC7DD@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Advice on (small amounts of) clock skew? 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, 19 Dec 2012 02:05:40 -0000 "Henry B. Hotz" writes:=0A= =0A= >If the service consuming certs is actually critical, then would you *ever*= =0A= >shut it down just because you couldn't get a fresh CRL? That makes for a= =0A= >pretty easy DOS, and if it's critical, then protection from DOS is importa= nt.=0A= =0A= Exactly. Once you get into the real world, where certificates are (for=0A= example) used with financial transactions where you lose money, potentially= =0A= lots of it, for each failed transaction, revocation checking is typically t= he=0A= second thing that's turned off after checking for expired certs (quite=0A= possibly the most pointless check in all of PKI, "we're going to shut down = all=0A= electronic trading because the certificate that was perfectly valid for=0A= million-dollar trades five seconds ago is now regarded as invalid without= =0A= anything about it having changed"). This is why I have in the past sometim= es=0A= referred to certs as "bit-bagging mechanisms for public keys", because when= =0A= things are critical most of PKI gets thrown away because of the large amoun= t=0A= of brittleness it adds to anything it's used with. So all the fields in th= e=0A= cert are nicely decorated, but everyone carefully looks the other way when= =0A= they're processing it.=0A= =0A= Peter.=0A= From mrex@sap.com Wed Dec 19 07:17:41 2012 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 40DB921F878A for ; Wed, 19 Dec 2012 07:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.131 X-Spam-Level: X-Spam-Status: No, score=-10.131 tagged_above=-999 required=5 tests=[AWL=0.118, 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 s86b01KxJX06 for ; Wed, 19 Dec 2012 07:17:40 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 587A321F86DA for ; Wed, 19 Dec 2012 07:17:40 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qBJFHVMO017850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Dec 2012 16:17:31 +0100 (MET) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73333AC7DD@uxcn10-2.UoA.auckland.ac.nz> To: Peter Gutmann Date: Wed, 19 Dec 2012 16:17:31 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121219151731.297CB1A40B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" Subject: Re: [pkix] Advice on (small amounts of) clock skew? 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: Wed, 19 Dec 2012 15:17:41 -0000 Peter Gutmann wrote: > > "Henry B. Hotz" writes: > > > >If the service consuming certs is actually critical, then would you *ever* > >shut it down just because you couldn't get a fresh CRL? That makes for a > >pretty easy DOS, and if it's critical, then protection from DOS is important. > > Exactly. Once you get into the real world, where certificates are (for > example) used with financial transactions where you lose money, potentially > lots of it, for each failed transaction, revocation checking is typically the > second thing that's turned off after checking for expired certs (quite > possibly the most pointless check in all of PKI, "we're going to shut down all > electronic trading because the certificate that was perfectly valid for > million-dollar trades five seconds ago is now regarded as invalid without > anything about it having changed"). This is why I have in the past sometimes > referred to certs as "bit-bagging mechanisms for public keys", because when > things are critical most of PKI gets thrown away because of the large amount > of brittleness it adds to anything it's used with. So all the fields in the > cert are nicely decorated, but everyone carefully looks the other way when > they're processing it. When I first implemented code to create certs (and later also to sign/issue), I decided to create certs with notBefore 24h into the past from current time, so that I will _never_ encounter problems with clock skew about notBefore, no matter how the code that validates it is actually implemented. A CA that issues Certs with a notBefore sharp on the current time is IMHO acting silly and didn't think about the consequences. For CRLs, there is no "notBefore" validity date. CRLs have a "thisUpdate" field, but the way it is defined, it does _NOT_ limit validity. http://tools.ietf.org/html/rfc5280#section-5.1.2.4 -Martin From bruce.stephens@isode.com Wed Dec 19 07:34:24 2012 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 B1FAA21F8777 for ; Wed, 19 Dec 2012 07:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 Hrs08lyy-AFn for ; Wed, 19 Dec 2012 07:34:24 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB0D21F8775 for ; Wed, 19 Dec 2012 07:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1355931263; d=isode.com; s=selector; i=@isode.com; bh=lb80eoSXbPOr1Qls/7fG8UDpqSWJg8BHVQNJxF+0bOc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ZTLFYfri9cK227ePOVEOUdE8CDJWLaiFF3o8hvWqCl7fvx3PWygJ0yKKg8TgWOwBPX4i5I axK0E9jf1vO5/xfQ7Ll+31qhPNLC5ECXA/m4aW2pRjoMdrREmhY67CuNNlHhv0miVF8WYE wCxQaln5k6BahceJ3op/cpIsmsIEwVk=; Received: from tinier.isode.net (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id for ; Wed, 19 Dec 2012 15:34:21 +0000 Received: by tinier.isode.net (sSMTP sendmail emulation); Wed, 19 Dec 2012 15:34:21 +0000 From: Bruce Stephens To: "pkix\@ietf.org" References: <20121219151731.297CB1A40B@ld9781.wdf.sap.corp> X-Hashcash: 1:20:121219:pkix@ietf.org::cYDlROsFncwI8j5c:00007VGj Date: Wed, 19 Dec 2012 15:34:21 +0000 In-Reply-To: <20121219151731.297CB1A40B@ld9781.wdf.sap.corp> (Martin Rex's message of "Wed, 19 Dec 2012 16:17:31 +0100 (CET)") Message-ID: <8038z26ooy.fsf@tinier.isode.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [pkix] Advice on (small amounts of) clock skew? 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, 19 Dec 2012 15:34:24 -0000 mrex@sap.com (Martin Rex) writes: [...] > For CRLs, there is no "notBefore" validity date. CRLs have a "thisUpdate" > field, but the way it is defined, it does _NOT_ limit validity. > > http://tools.ietf.org/html/rfc5280#section-5.1.2.4 Good point. Nothing in 6.3 (or the relevant X.509 descriptions) contradicts that, so I think my check (which may come from OpenSSL, actually) is erroneous. Hmm, yes, I think it is in OpenSSL. (It's probably relatively harmless for the typical internet usage of OpenSSL.) From tmiller@mitre.org Wed Dec 19 08:00:42 2012 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 DB20921F8B35 for ; Wed, 19 Dec 2012 08:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 kfoYUJehj4gT for ; Wed, 19 Dec 2012 08:00:42 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E2F3E21F8B30 for ; Wed, 19 Dec 2012 08:00:35 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B70A96150109; Wed, 19 Dec 2012 11:00:32 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9EEA26150105; Wed, 19 Dec 2012 11:00:32 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 11:00:32 -0500 From: "Miller, Timothy J." To: "'mrex@sap.com'" , Peter Gutmann Thread-Topic: [pkix] Advice on (small amounts of) clock skew? Thread-Index: Ac3djVaAAsJMg6IuREiFBF3A+gdKnwAmIkWAAAkFHtA= Date: Wed, 19 Dec 2012 16:00:31 +0000 Message-ID: <195DB2510AAA004391F58E28FCE21200066FD4DE@IMCMBX01.MITRE.ORG> References: <9A043F3CF02CD34C8E74AC1594475C73333AC7DD@uxcn10-2.UoA.auckland.ac.nz> <20121219151731.297CB1A40B@ld9781.wdf.sap.corp> In-Reply-To: <20121219151731.297CB1A40B@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Advice on (small amounts of) clock skew? 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, 19 Dec 2012 16:00:43 -0000 IIRC, DoD issues with notBefore set to 0000Z of the day of issue. Same rea= soning. -- T >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Martin Rex >Sent: Wednesday, December 19, 2012 10:18 AM >To: Peter Gutmann >Cc: pkix@ietf.org >Subject: Re: [pkix] Advice on (small amounts of) clock skew? > >Peter Gutmann wrote: >> >> "Henry B. Hotz" writes: >> > >> >If the service consuming certs is actually critical, then would you *ev= er* >> >shut it down just because you couldn't get a fresh CRL? That makes for= a >> >pretty easy DOS, and if it's critical, then protection from DOS is impo= rtant. >> >> Exactly. Once you get into the real world, where certificates are (for >> example) used with financial transactions where you lose money, >potentially >> lots of it, for each failed transaction, revocation checking is typicall= y the >> second thing that's turned off after checking for expired certs (quite >> possibly the most pointless check in all of PKI, "we're going to shut do= wn all >> electronic trading because the certificate that was perfectly valid for >> million-dollar trades five seconds ago is now regarded as invalid withou= t >> anything about it having changed"). This is why I have in the past some= times >> referred to certs as "bit-bagging mechanisms for public keys", because >when >> things are critical most of PKI gets thrown away because of the large am= ount >> of brittleness it adds to anything it's used with. So all the fields in= the >> cert are nicely decorated, but everyone carefully looks the other way wh= en >> they're processing it. > >When I first implemented code to create certs (and later also to sign/issu= e), >I decided to create certs with notBefore 24h into the past from current ti= me, >so that I will _never_ encounter problems with clock skew about notBefore, >no matter how the code that validates it is actually implemented. > >A CA that issues Certs with a notBefore sharp on the current >time is IMHO acting silly and didn't think about the consequences. > >For CRLs, there is no "notBefore" validity date. CRLs have a "thisUpdate" >field, but the way it is defined, it does _NOT_ limit validity. > > http://tools.ietf.org/html/rfc5280#section-5.1.2.4 > > > >-Martin >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From pgut001@cs.auckland.ac.nz Thu Dec 20 20:10:48 2012 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 6AAA421F88E1 for ; Thu, 20 Dec 2012 20:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Jz4kdGB7MEBS for ; Thu, 20 Dec 2012 20:10:47 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B27621E8041 for ; Thu, 20 Dec 2012 20:10:43 -0800 (PST) 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=1356063046; x=1387599046; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=4XbTyVVeOravp38jN5ZdIzaoiAsaYhHR/QfTlSIbXSk=; b=a+xfGaG+k4u0ZrxjnfMEkdixDvryNArnos3BzgF933Av68dQGApMKfRW ChfZGLLb8bj1LloOgPMKA4fgetfj2K1P5TNJc+7ALrP11PXqCIFLqNGTD 8eIoLIze4xuh4nTNbrNxPBg44t7OO6NpUrCyyU6P2C3p+5j84OCxFUPQT o=; X-IronPort-AV: E=Sophos;i="4.84,328,1355050800"; d="scan'208";a="163269282" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Dec 2012 17:10:42 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.249]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Fri, 21 Dec 2012 17:10:42 +1300 From: Peter Gutmann To: "pkix@ietf.org" , Martin Rex Thread-Topic: [pkix] Advice on (small amounts of) clock skew? Thread-Index: Ac3fMSRdvA970zCxRqqcyxX2nxkn9A== Date: Fri, 21 Dec 2012 04:10:42 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73333B470D@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Advice on (small amounts of) clock skew? 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, 21 Dec 2012 04:10:48 -0000 Martin Rex writes:=0A= =0A= >When I first implemented code to create certs (and later also to sign/issu= e),=0A= >I decided to create certs with notBefore 24h into the past from current ti= me,=0A= >so that I will _never_ encounter problems with clock skew about notBefore,= no=0A= >matter how the code that validates it is actually implemented.=0A= =0A= My code does that too. Another vendor calls it "the 86400 kludge", because= =0A= they always subtract 86400 seconds from the issue time to avoid problems li= ke=0A= this.=0A= =0A= Peter.=0A= From ynir@checkpoint.com Thu Dec 20 21:06:43 2012 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 E191321F8689 for ; Thu, 20 Dec 2012 21:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.496 X-Spam-Level: X-Spam-Status: No, score=-10.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 aKUYr6LH7+DL for ; Thu, 20 Dec 2012 21:06:40 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4A09A21F8626 for ; Thu, 20 Dec 2012 21:06:35 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qBL5602l019346; Fri, 21 Dec 2012 07:06:05 +0200 X-CheckPoint: {50D3ED35-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.238]) by IL-EX10.ad.checkpoint.com ([169.254.2.238]) with mapi id 14.02.0318.004; Fri, 21 Dec 2012 07:06:01 +0200 From: Yoav Nir To: Peter Gutmann Thread-Topic: [pkix] Advice on (small amounts of) clock skew? Thread-Index: Ac3fMSRdqyng0pbT/0SkyjJG+2F8FP//7ewA Date: Fri, 21 Dec 2012 05:06:00 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277210EE05893@IL-EX10.ad.checkpoint.com> References: <9A043F3CF02CD34C8E74AC1594475C73333B470D@uxcn10-2.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73333B470D@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.166] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Advice on (small amounts of) clock skew? 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, 21 Dec 2012 05:06:43 -0000 On Dec 21, 2012, at 6:10 AM, Peter Gutmann wrot= e: > Martin Rex writes: >=20 >> When I first implemented code to create certs (and later also to sign/is= sue), >> I decided to create certs with notBefore 24h into the past from current = time, >> so that I will _never_ encounter problems with clock skew about notBefor= e, no >> matter how the code that validates it is actually implemented. >=20 > My code does that too. Another vendor calls it "the 86400 kludge", becau= se > they always subtract 86400 seconds from the issue time to avoid problems = like > this. 24h gets you around people who have their clock set correctly to local time= , but have the wrong time zone, so the UTC time is really wrong. You don't = see it much on PCs these days, but it's still common on servers. Yoav From pkix@inbox.lv Thu Dec 27 12:05:49 2012 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 14E2121F8DD4 for ; Thu, 27 Dec 2012 12:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.556 X-Spam-Level: X-Spam-Status: No, score=0.556 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, 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 OWvK5DMkGVJo for ; Thu, 27 Dec 2012 12:05:48 -0800 (PST) Received: from shark2.inbox.lv (shark2.inbox.lv [89.111.3.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB6F21F8DD0 for ; Thu, 27 Dec 2012 12:05:47 -0800 (PST) Received: by shark2.inbox.lv (Postfix, from userid 1000) id ED04DD5A3; Thu, 27 Dec 2012 22:05:40 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark2-plain-b64d2.inbox.lv (Postfix) with ESMTP id BEBEBD5AD for ; Thu, 27 Dec 2012 22:05:40 +0200 (EET) Received: from localhost ([10.0.1.13]) by localhost (shark2.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id ZoSWpNj+ZQKV for ; Thu, 27 Dec 2012 22:05:40 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Thu, 27 Dec 2012 22:05:40 +0200 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w3.inbox.lv, l=en, compose=HTML X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Ubuntu/12.10 Chromium/22.0.1229.94 Chrome/22.0.1229.94 Safari/537.4 Message-ID: <1356638740.50dcaa146653b@mail.inbox.lv> Date: Thu, 27 Dec 2012 22:05:40 +0200 From: "Andris Berzins" To: pkix@ietf.org User-Agent: Inbox.lv Webmail Subject: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period 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, 27 Dec 2012 20:05:49 -0000
rfc5280 states:
 
"An entry MUST NOT be remov= ed
from the CRL until it appears on one regularly scheduled CRL i= ssued
beyond the revoked certificate's validity period."
 
and
 
"If a certificate revocat= ion notice first appears on a delta CRL, then
it is possible for = the certificate validity period to expire before
the next complet= e CRL for the same scope is issued.  In this case,
the revoc= ation notice MUST be included in all subsequent delta CRLs
until = the revocation notice is included on at least one explicitly
issu= ed complete CRL for this scope."
 
Why is that req= uired?
 
 =
From denis.pinkas@bull.net Fri Dec 28 03:00:41 2012 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 423BF21F8CE9 for ; Fri, 28 Dec 2012 03:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 AnavfwYbwmJG for ; Fri, 28 Dec 2012 03:00:40 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4DB21F8ABA for ; Fri, 28 Dec 2012 03:00:40 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 039EA1CCFC for ; Fri, 28 Dec 2012 12:00:38 +0100 (CET) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012122812003683-43476 ; Fri, 28 Dec 2012 12:00:36 +0100 Message-ID: <50DD7BCF.2010800@bull.net> Date: Fri, 28 Dec 2012 12:00:31 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: pkix@ietf.org References: <1356638740.50dcaa146653b@mail.inbox.lv> In-Reply-To: <1356638740.50dcaa146653b@mail.inbox.lv> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 28/12/2012 12:00:36, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 28/12/2012 12:00:38, Serialize complete at 28/12/2012 12:00:38 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------080305010108080505010005" Subject: Re: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period 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, 28 Dec 2012 11:00:41 -0000 This is a multi-part message in MIME format. --------------080305010108080505010005 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed RFC 5280 states: 4.1.2.5.Validity The certificate validity period is the time interval during which the CA warrants that it will maintain information about the status of the certificate. Since this CRL is the first one issued beyond the end of the validity period, this guarantees that the CA maintains the revocation status really up to the end of the validity period. Denis > rfc5280 states: > "An entry MUST NOT be removed > from the CRL until it appears on one regularly scheduled CRL issued > beyond the revoked certificate's validity period." > and > "If a certificate revocation notice first appears on a delta CRL, then > it is possible for the certificate validity period to expire before > the next complete CRL for the same scope is issued. In this case, > the revocation notice MUST be included in all subsequent delta CRLs > until the revocation notice is included on at least one explicitly > issued complete CRL for this scope." > Why is that required? > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------080305010108080505010005 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
RFC 5280 states:

4.1.2.5.  Validity

 

   The certificate validity period is the time interval during which the

   CA warrants that it will maintain information about the status of the
   certificate. 


Since this CRL is the first one issued beyond the end of the validity period, this guarantees that
the CA maintains the revocation status really up to the end of the validity period.

Denis

rfc5280 states:
 
"An entry MUST NOT be removed
from the CRL until it appears on one regularly scheduled CRL issued
beyond the revoked certificate's validity period."
 
and
 
"If a certificate revocation notice first appears on a delta CRL, then
it is possible for the certificate validity period to expire before
the next complete CRL for the same scope is issued.  In this case,
the revocation notice MUST be included in all subsequent delta CRLs
until the revocation notice is included on at least one explicitly
issued complete CRL for this scope."
 
Why is that required?
 
 


_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--------------080305010108080505010005-- From mrex@sap.com Fri Dec 28 07:09:36 2012 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 4F79421F8CA0 for ; Fri, 28 Dec 2012 07:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.141 X-Spam-Level: X-Spam-Status: No, score=-10.141 tagged_above=-999 required=5 tests=[AWL=0.108, 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 hltYmutxQblO for ; Fri, 28 Dec 2012 07:09:35 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1697521F8C7E for ; Fri, 28 Dec 2012 07:09:34 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id qBSF9WFW004370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Dec 2012 16:09:32 +0100 (MET) In-Reply-To: <50DD7BCF.2010800@bull.net> To: Denis Pinkas Date: Fri, 28 Dec 2012 16:09:32 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121228150932.C89E71A425@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period 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: Fri, 28 Dec 2012 15:09:36 -0000 I would say that the reason for this requirement is the last sentence of rfc5280 section 5, page 55: http://tools.ietf.org/html/rfc5280#page-55 Conforming applications are not required to support processing of delta CRLs, indirect CRLs, or CRLs with a scope other than all certificates issued by one CA. If a CA revokes a cert, it must issue at least one CRL that *ALL* conforming applications will be able to see. In the border case, when a cert is revoked very close to the end of its validity, it may require the CA to list the revoked cert on a complete regular CRL with a "thisUpdate" that is after the "notAfter" of such a cert that is revoked just before then end of its validity period. -Martin Denis Pinkas wrote: > RFC 5280 states: > > 4.1.2.5.Validity > > The certificate validity period is the time interval during which the > > CA warrants that it will maintain information about the status of the > certificate. > > > Since this CRL is the first one issued beyond the end of the validity > period, this guarantees that > the CA maintains the revocation status really up to the end of the > validity period. > > Denis > > > rfc5280 states: > > "An entry MUST NOT be removed > > from the CRL until it appears on one regularly scheduled CRL issued > > beyond the revoked certificate's validity period." > > and > > "If a certificate revocation notice first appears on a delta CRL, then > > it is possible for the certificate validity period to expire before > > the next complete CRL for the same scope is issued. In this case, > > the revocation notice MUST be included in all subsequent delta CRLs > > until the revocation notice is included on at least one explicitly > > issued complete CRL for this scope." > > Why is that required? > > > > > > _______________________________________________ > > 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 SChokhani@cygnacom.com Fri Dec 28 07:26:25 2012 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 A233B21F8BF1 for ; Fri, 28 Dec 2012 07:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 L8aeeyLMwAom for ; Fri, 28 Dec 2012 07:26:25 -0800 (PST) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9E621F8BEA for ; Fri, 28 Dec 2012 07:26:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,370,1355115600"; d="scan'208,217";a="2787445" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 28 Dec 2012 10:26:23 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 28 Dec 2012 10:26:23 -0500 From: Santosh Chokhani To: Andris Berzins , "pkix@ietf.org" Date: Fri, 28 Dec 2012 10:26:22 -0500 Thread-Topic: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period Thread-Index: Ac3kbZXZ7Hnu3JT8T+CTqbc6BJBhnwAmk8RQ Message-ID: References: <1356638740.50dcaa146653b@mail.inbox.lv> In-Reply-To: <1356638740.50dcaa146653b@mail.inbox.lv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AFF3D68AE7scygexch7cygnac_" MIME-Version: 1.0 Subject: Re: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period 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, 28 Dec 2012 15:26:25 -0000 --_000_B83745DA469B7847811819C5005244AFF3D68AE7scygexch7cygnac_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kcmlzLA0KDQpUaGUgcmF0aW9uYWxlIGJlaGluZCB0aGlzIGlzIHRvIHByb3ZpZGUgZm9yIGFy Y2hpdmUgYW5kIGZ1dHVyZSB2ZXJpZmljYXRpb24gKGUuZy4sIGZvciBub24tcmVwdWRpYXRpb24g cHVycG9zZXMpIGZvciAuDQoNCkxldCB1cyBtYWtlIHRoZSBmb2xsb3dpbmcgYXNzdW1wdGlvbnM6 DQoNCg0KMS4gICAgIFRoZSBDUkxzIGFyZSB0aGUgb2ZmaWNpYWwgYXJjaGl2ZS4NCg0KMi4gICAg IERlbHRhIENSTHMgYXJlIG5vdCB0aGUgb2ZmaWNpYWwgYXJjaGl2ZQ0KDQozLiAgICAgQSBuZXcg Q1JMIFkgY2FuIGJlIGJ1aWx0IHVzaW5nIHRoZSBwcmV2aW91cyBDUkwgWCBhbmQgYSBkZWx0YSBp c3N1ZWQgd2hlbiBZIGlzIGlzc3VlZC4NCg0KSW4gdGhhdCBjYXNlLCB5b3Ugd2FudCBhIGNlcnRp ZmljYXRlIG9uIGF0IGxlYXN0IG9uZSBDUkwgYW5kIG1haW50YWluIG9uIGRlbHRhIHVudGlsIGl0 IGlzIHJlY29yZGVkIGluIGEgQ1JMIHRoYXQgaXMgYXJjaGl2ZWQuDQoNCjUyODAgbGFuZ3VhZ2Ug aXMgdW5uZWNlc3NhcmlseSBjb25zdHJhaW5pbmcuICBJdCBzaG91bGQgc3RhdGUsIOKAnGV4cGly ZWQgY2VydGlmaWNhdGVzIHNoYWxsIGJlIHJlbW92ZWQgZnJvbSB0aGUgQ1JMLCBleGNlcHQgYSBy ZXZva2VkIGNlcnRpZmljYXRlIHNoYWxsIGFwcGVhciBvbiBhdCBsZWFzdCBvbmUgQ1JMLg0KDQpG cm9tOiBwa2l4LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwa2l4LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBBbmRyaXMgQmVyemlucw0KU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDI3 LCAyMDEyIDM6MDYgUE0NClRvOiBwa2l4QGlldGYub3JnDQpTdWJqZWN0OiBbcGtpeF0gd2h5IHJl dm9rZWQgY2VydGlmaWNhdGUgZW50cnkgaGFzIHRvIGJlIGluY2x1ZGVkIGluIG9uZSBDUkwgaXNz dWVkIGJleW9uZCBjZXJ0aWZpY2F0ZSB2YWxpZGl0eSBwZXJpb2QNCg0KcmZjNTI4MCBzdGF0ZXM6 DQoNCiJBbiBlbnRyeSBNVVNUIE5PVCBiZSByZW1vdmVkDQpmcm9tIHRoZSBDUkwgdW50aWwgaXQg YXBwZWFycyBvbiBvbmUgcmVndWxhcmx5IHNjaGVkdWxlZCBDUkwgaXNzdWVkDQpiZXlvbmQgdGhl IHJldm9rZWQgY2VydGlmaWNhdGUncyB2YWxpZGl0eSBwZXJpb2QuIg0KDQphbmQNCg0KIklmIGEg Y2VydGlmaWNhdGUgcmV2b2NhdGlvbiBub3RpY2UgZmlyc3QgYXBwZWFycyBvbiBhIGRlbHRhIENS TCwgdGhlbg0KaXQgaXMgcG9zc2libGUgZm9yIHRoZSBjZXJ0aWZpY2F0ZSB2YWxpZGl0eSBwZXJp b2QgdG8gZXhwaXJlIGJlZm9yZQ0KdGhlIG5leHQgY29tcGxldGUgQ1JMIGZvciB0aGUgc2FtZSBz Y29wZSBpcyBpc3N1ZWQuICBJbiB0aGlzIGNhc2UsDQp0aGUgcmV2b2NhdGlvbiBub3RpY2UgTVVT VCBiZSBpbmNsdWRlZCBpbiBhbGwgc3Vic2VxdWVudCBkZWx0YSBDUkxzDQp1bnRpbCB0aGUgcmV2 b2NhdGlvbiBub3RpY2UgaXMgaW5jbHVkZWQgb24gYXQgbGVhc3Qgb25lIGV4cGxpY2l0bHkNCmlz c3VlZCBjb21wbGV0ZSBDUkwgZm9yIHRoaXMgc2NvcGUuIg0KDQpXaHkgaXMgdGhhdCByZXF1aXJl ZD8NCg0KDQo= --_000_B83745DA469B7847811819C5005244AFF3D68AE7scygexch7cygnac_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFy Z2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCglt YXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpub3Jt YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNjY5MDk0NTkwOw0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzk1MjY0MDc2IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxp bms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPkFuZHJpcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSByYXRpb25hbGUgYmVoaW5k IHRoaXMgaXMgdG8gcHJvdmlkZSBmb3IgYXJjaGl2ZSBhbmQgZnV0dXJlIHZlcmlmaWNhdGlvbiAo ZS5nLiwgZm9yIG5vbi1yZXB1ZGlhdGlvbiBwdXJwb3NlcykgZm9yIC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkxl dCB1cyBtYWtlIHRoZSBmb2xsb3dpbmcgYXNzdW1wdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+MS48c3BhbiBzdHls ZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBD UkxzIGFyZSB0aGUgb2ZmaWNpYWwgYXJjaGl2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxz cGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjIuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRp bWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5EZWx0YSBDUkxzIGFyZSBub3QgdGhl IG9mZmljaWFsIGFyY2hpdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBh cmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8x Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdt c28tbGlzdDpJZ25vcmUnPjMuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21h biInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BIG5ldyBDUkwgWSBjYW4gYmUgYnVpbHQgdXNpbmcgdGhl IHByZXZpb3VzIENSTCBYIGFuZCBhIGRlbHRhIGlzc3VlZCB3aGVuIFkgaXMgaXNzdWVkLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+SW4gdGhhdCBjYXNlLCB5b3Ugd2FudCBhIGNlcnRpZmljYXRlIG9uIGF0IGxlYXN0 IG9uZSBDUkwgYW5kIG1haW50YWluIG9uIGRlbHRhIHVudGlsIGl0IGlzIHJlY29yZGVkIGluIGEg Q1JMIHRoYXQgaXMgYXJjaGl2ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz41MjgwIGxhbmd1YWdlIGlzIHVubmVj ZXNzYXJpbHkgY29uc3RyYWluaW5nLsKgIEl0IHNob3VsZCBzdGF0ZSwg4oCcZXhwaXJlZCBjZXJ0 aWZpY2F0ZXMgc2hhbGwgYmUgcmVtb3ZlZCBmcm9tIHRoZSBDUkwsIGV4Y2VwdCBhIHJldm9rZWQg Y2VydGlmaWNhdGUgc2hhbGwgYXBwZWFyIG9uIGF0IGxlYXN0IG9uZSBDUkwuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiJz4gcGtpeC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGtpeC1ib3Vu Y2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHJpcyBCZXJ6aW5zPGJyPjxiPlNl bnQ6PC9iPiBUaHVyc2RheSwgRGVjZW1iZXIgMjcsIDIwMTIgMzowNiBQTTxicj48Yj5Ubzo8L2I+ IHBraXhAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFtwa2l4XSB3aHkgcmV2b2tlZCBjZXJ0 aWZpY2F0ZSBlbnRyeSBoYXMgdG8gYmUgaW5jbHVkZWQgaW4gb25lIENSTCBpc3N1ZWQgYmV5b25k IGNlcnRpZmljYXRlIHZhbGlkaXR5IHBlcmlvZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ cmZjNTI4MCBzdGF0ZXM6PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+JnF1 b3Q7QW4gZW50cnkgTVVTVCBOT1QgYmUgcmVtb3ZlZDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPmZyb20gdGhlIENSTCB1bnRpbCBpdCBhcHBlYXJzIG9uIG9uZSBy ZWd1bGFybHkgc2NoZWR1bGVkIENSTCBpc3N1ZWQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5iZXlvbmQgdGhlIHJldm9rZWQgY2VydGlmaWNhdGUncyB2YWxpZGl0 eSBwZXJpb2QuJnF1b3Q7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+YW5k PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+JnF1b3Q7SWYgYSBjZXJ0aWZp Y2F0ZSByZXZvY2F0aW9uIG5vdGljZSBmaXJzdCBhcHBlYXJzIG9uIGEgZGVsdGEgQ1JMLCB0aGVu PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aXQgaXMgcG9zc2li bGUgZm9yIHRoZSBjZXJ0aWZpY2F0ZSB2YWxpZGl0eSBwZXJpb2QgdG8gZXhwaXJlIGJlZm9yZTxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoZSBuZXh0IGNvbXBs ZXRlIENSTCBmb3IgdGhlIHNhbWUgc2NvcGUgaXMgaXNzdWVkLiAmbmJzcDtJbiB0aGlzIGNhc2Us PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+dGhlIHJldm9jYXRp b24gbm90aWNlIE1VU1QgYmUgaW5jbHVkZWQgaW4gYWxsIHN1YnNlcXVlbnQgZGVsdGEgQ1JMczxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnVudGlsIHRoZSByZXZv Y2F0aW9uIG5vdGljZSBpcyBpbmNsdWRlZCBvbiBhdCBsZWFzdCBvbmUgZXhwbGljaXRseTxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmlzc3VlZCBjb21wbGV0ZSBD UkwgZm9yIHRoaXMgc2NvcGUuJnF1b3Q7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+V2h5IGlzIHRoYXQgcmVxdWlyZWQ/PG86cD48L286cD48L3A+PC9kaXY+PGRpdiBpZD0i c2lnX3VwcGVyIj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+ PGRpdiBpZD0ic2lnX2xvd2VyIj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48 L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_B83745DA469B7847811819C5005244AFF3D68AE7scygexch7cygnac_-- From mrex@sap.com Fri Dec 28 08:30:32 2012 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 2085721F86C9 for ; Fri, 28 Dec 2012 08:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 qySw0TLpHlvZ for ; Fri, 28 Dec 2012 08:30:31 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0F921F866E for ; Fri, 28 Dec 2012 08:30:30 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qBSGUQos023064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Dec 2012 17:30:26 +0100 (MET) In-Reply-To: To: Santosh Chokhani Date: Fri, 28 Dec 2012 17:30:26 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121228163026.BF0561A425@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" Subject: Re: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period 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: Fri, 28 Dec 2012 16:30:32 -0000 Santosh Chokhani wrote: > > The rationale behind this is to provide for archive and future > verification (e.g., for non-repudiation purposes) for. > > Let us make the following assumptions: > > > 1. The CRLs are the official archive. > > 2. Delta CRLs are not the official archive > > 3. A new CRL Y can be built using the previous CRL X and a delta issued when Y is issued. > > In that case, you want a certificate on at least one CRL and maintain > on delta until it is recorded in a CRL that is archived. > > 5280 language is unnecessarily constraining. It should state, > ?expired certificates shall be removed from the CRL, > except a revoked certificate shall appear on at least one CRL. Except for the special case of _pure_ online authentication, one really wants to be able to publish key compromise on CRLs _forever_. For digital signatures on Emails, Code, Documents, etc. it seems unreasonable to _not_ be able to revoke a cert after it has expired. The revocation date is the point in time when the revocation was requested or published (and may happen after expiration of the cert). The more interesting revocation information for archived digitally signed data is the invalidity date asserted by the revocation. -Martin From SChokhani@cygnacom.com Sat Dec 29 17:47:49 2012 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 6899721F8888 for ; Sat, 29 Dec 2012 17:47:49 -0800 (PST) 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 45exkEUDTllZ for ; Sat, 29 Dec 2012 17:47:48 -0800 (PST) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id BAF0C21F8886 for ; Sat, 29 Dec 2012 17:47:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,379,1355115600"; d="scan'208";a="2793432" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 29 Dec 2012 20:47:47 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sat, 29 Dec 2012 20:47:47 -0500 From: Santosh Chokhani To: "mrex@sap.com" Date: Sat, 29 Dec 2012 20:47:46 -0500 Thread-Topic: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period Thread-Index: Ac3lGKeJ1HdpOF/FTWK2cJ1kxw1vmwBFleqg Message-ID: References: <20121228163026.BF0561A425@ld9781.wdf.sap.corp> In-Reply-To: <20121228163026.BF0561A425@ld9781.wdf.sap.corp> 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" Subject: Re: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period 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, 30 Dec 2012 01:47:49 -0000 While not explicit, 5280 and my post permit you to revoke an expired certif= icate if you wish to and it will be on one CRL and then be removed. In terms of keeping certificates on CRL forever, these are relying party is= sues that can be solved for non-repudiation purposes using time stamps, LTA= NS trusted archive, or using historical CRL as associated issuance, revocat= ion and invalidity dates to create a time-line and resolve disputes, Do not forget, PKI is not the non-repudiation decision maker. It is just o= ne of the inputs (albeit a strong one) to help the judicial system to make = a determination. There are other IT and non-IT inputs one uses to resolve = such disputes. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Friday, December 28, 2012 11:30 AM To: Santosh Chokhani Cc: Andris Berzins; pkix@ietf.org Subject: Re: [pkix] why revoked certificate entry has to be included in one= CRL issued beyond certificate validity period Santosh Chokhani wrote: >=20 > The rationale behind this is to provide for archive and future=20 > verification (e.g., for non-repudiation purposes) for. >=20 > Let us make the following assumptions: >=20 >=20 > 1. The CRLs are the official archive. >=20 > 2. Delta CRLs are not the official archive >=20 > 3. A new CRL Y can be built using the previous CRL X and a delta issu= ed when Y is issued. >=20 > In that case, you want a certificate on at least one CRL and maintain=20 > on delta until it is recorded in a CRL that is archived. >=20 > 5280 language is unnecessarily constraining. It should state,=20 > ?expired certificates shall be removed from the CRL, except a revoked=20 > certificate shall appear on at least one CRL. Except for the special case of _pure_ online authentication, one really wan= ts to be able to publish key compromise on CRLs _forever_. For digital signatures on Emails, Code, Documents, etc. it seems unreasonab= le to _not_ be able to revoke a cert after it has expired. The revocation date is the point in time when the revocation was requested = or published (and may happen after expiration of the cert). The more interesting revocation information for archived digitally signed d= ata is the invalidity date asserted by the revocation. -Martin