From pgut001@login01.cs.auckland.ac.nz Fri Jul 1 01:44:35 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570BB21F869A for ; Fri, 1 Jul 2011 01:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVD3gaTKjVCz for ; Fri, 1 Jul 2011 01:44:31 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 31F0E21F888A for ; Fri, 1 Jul 2011 01:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1309509871; x=1341045871; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[pkix]=20rfc3161=20T imeStamps=20and=20sha1-based=20sigs/imprints=20in=20pkcs7 /cms|Cc:=20pkix@ietf.org|In-Reply-To:=20<201106301746.p5U HkXYV014149@fs4113.wdf.sap.corp>|Message-Id:=20|Date:=20Fri,=2001=20 Jul=202011=2020:44:27=20+1200; bh=8+i1aSde4MNaLU71jdedtw+MucmFEh7JYjRGUfYeQUo=; b=ZRuG7G32AhGQNBeYHihM76EMu1KMT1Nb7Ntfx81CGbmX80PpT2ZcCEqL jUZMg0ZQ5r66mLlo0F4XjabiP0GdNFQp8enS3PY4fqIkLzRy/MaxSpv6C Z4/Sa/YEifK6CykY0h1XHE2hmtPsF+miJFbS+aGtpLF0WGCHd3VKRI67d 8=; X-IronPort-AV: E=Sophos;i="4.65,456,1304251200"; d="scan'208";a="69836355" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 01 Jul 2011 20:44:27 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QcZKt-0008Bw-IL; Fri, 01 Jul 2011 20:44:27 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QcZKt-0004Nr-L4; Fri, 01 Jul 2011 20:44:27 +1200 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201106301746.p5UHkXYV014149@fs4113.wdf.sap.corp> Message-Id: Date: Fri, 01 Jul 2011 20:44:27 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] rfc3161 TimeStamps and sha1-based sigs/imprints in pkcs7/cms X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 08:44:35 -0000 Martin Rex writes: >The original plan was to _have_completed_ phasing out the use of SHA-1 for >digital signatures by the end of 2010, but that target seems to have been >missed entirely. There is a significant availability of RSA 2048-bit >certificates, but the use of sha256WithRsaEncryption is still at homeopathic >levels. I think one reason for this may be the vanishingly small use of TSP. There's a pile of closed environments for which the goal is to meet requirements set ten years ago by lawyers that haven't been updated since then (and where they could just as well use CRC32 because the target is to meet some particular compliance requirement rather than to follow the state of the art in security), and that's about it (AuthentiCode uses timestamping but AFAIK that's a standard PKCS #7 countersignature and not what TSP does). So the apparent apathy over hash algorithms could just be a reflection of the actual apathy over TSP. Peter. From rob.stradling@comodo.com Fri Jul 1 02:21:58 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A981F11E80C2 for ; Fri, 1 Jul 2011 02:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-jZq47vrQjL for ; Fri, 1 Jul 2011 02:21:57 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2306A11E80B8 for ; Fri, 1 Jul 2011 02:21:56 -0700 (PDT) Received: (qmail 26138 invoked from network); 1 Jul 2011 09:21:55 -0000 Received: from ian.bd.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 1 Jul 2011 09:21:55 -0000 Received: (qmail 9763 invoked by uid 1000); 1 Jul 2011 09:21:51 -0000 Received: from nigel.brad.office.comodo.net (HELO nigel.localnet) (192.168.0.58) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPS; Fri, 01 Jul 2011 10:21:51 +0100 From: Rob Stradling To: pkix@ietf.org Date: Fri, 1 Jul 2011 10:21:42 +0100 User-Agent: KMail/1.13.7 (Linux/2.6.38-gentoo-r6; KDE/4.6.3; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201107011021.43286.rob.stradling@comodo.com> Subject: Re: [pkix] rfc3161 TimeStamps and sha1-based sigs/imprints in pkcs7/cms X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 09:21:58 -0000 On Friday 01 Jul 2011 09:44:27 Peter Gutmann wrote: > state of the art in security), and that's about it (AuthentiCode uses > timestamping but AFAIK that's a standard PKCS #7 countersignature and not > what TSP does). The Windows 7 implementation of Authenticode still supports Microsoft's legacy PKCS#7 countersignature timestamping [1], but it also introduces support for RFC3161 timestamping [2]. Microsoft require all Code Signing CAs in the Microsoft Root Certificate Program to "operate a timestamp server authority (TSA) in conjunction with their code signing service, and as a best practice request that Subscribers timestamp the digital signature after signing their code. Effective no later than October 31, 2011, the TSA must comply with RFC 3161" [3]. [1] http://msdn.microsoft.com/en-us/library/bb931395%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa387764%28v=vs.85%29.aspx (signtool's "/tr" and "/td" flags) [3] Sorry, I can't find this requirement stated on any public webpages. > So the apparent apathy over hash algorithms could just be a reflection of > the actual apathy over TSP. > > Peter. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From denis.pinkas@bull.net Fri Jul 1 04:59:39 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12B021F8741 for ; Fri, 1 Jul 2011 04:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 AYE19wZNkcsX for ; Fri, 1 Jul 2011 04:59:38 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id D144821F873F for ; Fri, 1 Jul 2011 04:59:37 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 833D741806B; Fri, 1 Jul 2011 14:09:10 +0200 (CEST) In-Reply-To: <201106301746.p5UHkXYV014149@fs4113.wdf.sap.corp> References: <4E0C9A45.8070407@edelweb.fr> from "Peter Sylvester" at Jun 30, 11 05:46:13 pm <201106301746.p5UHkXYV014149@fs4113.wdf.sap.corp> To: mrex@sap.com MIME-Version: 1.0 X-KeepSent: 0211DADE:95156740-C12578C0:003F8EE1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Fri, 1 Jul 2011 13:59:36 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 01/07/2011 13:59:36, Serialize complete at 01/07/2011 13:59:36 Content-Type: multipart/alternative; boundary="=_alternative 0041D608C12578C0_=" Cc: pkix@ietf.org Subject: Re: [pkix] rfc3161 TimeStamps and sha1-based sigs/imprints in pkcs7/cms X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 11:59:39 -0000 Message en plusieurs parties au format MIME --=_alternative 0041D608C12578C0_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Martin, You seriously question the security of timestamps with sha1-based=20 signatures. Formats have been described on how to address this issue in general, i.e.=20 when the hash function becomes weak. Such formats exist in the context of Advanced Electronic Signatures with=20 the AdES-A format as defined=20 by ETSI for CAdES and XAdES. Late 2009, ETSI has defined new ways to sign PDF documents which can=20 contain several time-stamps. See ETSI TS 102 778-4. In this document, it is explained that TSTs can be=20 used in two cases:=20 when the document is signed and when the document is unsigned. Note: In order to capture the content of this document, it may be useful=20 to read parts 1 to 3 as well. While formats exist, in many cases the way to use these formats is not=20 crystal clear. Basically, the problem to "renew a time-stamp" does not happen first=20 because the hash function=20 becomes weak, but because the validity period of the TSU certificate is=20 over. A new TST must then be used to protect the previous one. It must then be demonstrated that, at the time the new TST was applied,=20 the certificate of the previous=20 time-stamp was not revoked with the revocation reason "key compromise". So the certification path and the revocation information MUST be captured=20 and a new TST=20 (with a stronger hash function) must be applied. Do you think it might be useful to draft an Informational RFC to explain=20 such things ? Denis=20 =20 De : Martin Rex A : peter.sylvester@edelweb.fr (Peter Sylvester) Cc : pkix@ietf.org Date : 30/06/2011 19:46 Objet : [pkix] rfc3161 TimeStamps and sha1-based sigs/imprints in=20 pkcs7/cms Envoy=E9 par : pkix-bounces@ietf.org Peter Sylvester wrote: >=20 > We are sorry for them. This URL has been deprecated > since years, a good one can be found reading >=20 > http://timestamping.edelweb.fr >=20 > Thanks for your attention and sorry for the inconvenience > of this message for those who are not interested in timestamping Speaking of rfc3161 timestamping, most public services seem to be limited to sha1WithRsaEncryption { 1, 2, 840, 113549, 1, 1, 5 } which looks like an anachronism and a security problem to me. Are the proposals or is there a standard how to migrate to a more resonable signature algorithm such as sha256WithRsaEncryption { 1, 2, 840, 113549, 1, 1, 11 } e.g. when the MessageImprint uses SHA256? While requesting this feature explicitly through a specific TSA policy OID would theoretically be possible, this very same approach would be quite non-portable. The original plan was to =5Fhave=5Fcompleted=5F phasing out the use of SHA-1 for digital signatures by the end of 2010, but that target seems to have been missed entirely. There is a significant availability of RSA 2048-bit certificates, but the use of sha256WithRsaEncryption is still at homeopathic levels. The purpose of rfc3161 timestamps is to prove that something existed before or at a certain time, and the two most common uses I can think of are: - determine whether a digital signature was created within the validity period of the signer certificate - determine whether a digital signature was created before the point in time when the signer certificate was revoked Both these cases, a purposes looking into the future, sometimes far into the future (think e.g. about signed×tamped code), and I seriously question the security of timestamps with sha1-based signatures (or sha1-based message imprints or the original, often indirect signatures on the underlying pkcs7/CMS) for purposes with a useful lifetime of many years into the future. -Martin =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 0041D608C12578C0_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Martin,

You seriously question the security of timestamps with sha1-based signatures.

Formats have been described on how to address this issue in general, i.e. when the hash function becomes weak.

Such formats exist in the context of Advanced Electr= onic Signatures with the AdES-A format as defined
by ETSI for CAdES and XAdES.

Late 2009, ETSI has defined new ways to sign PDF doc= uments which can contain several time-stamps.
See ETSI TS 102 778-4. In this document, it is expla= ined that TSTs can be used in two cases:
when the document is signed and when the document is unsigned.

Note: In order to capture the content of this document, it may be useful to read parts 1 to 3 as well.

While formats exist, in many cases the way to use these formats is not crystal clear.

Basically, the problem to "renew a time-stamp&q= uot; does not happen first because the hash function
becomes weak, but because the validity period of the TSU certificate is over.

A new TST must then be used to protect the previous one.

It must then be demonstrated that, at the time the new TST was applied, the certificate of the previous
time-stamp was not revoked with the revocation reason "key compromise&= quot;.

So the certification path and the revocation informa= tion MUST be captured and a new TST
(with a stronger hash function) must be applied.

Do you think it might be useful to draft an Informat= ional RFC to explain such things ?

Denis
 



De :     &= nbsp;  Martin Rex <mrex@sap.com= >
A :     &n= bsp;  peter.sylvester@edelweb.fr (Peter Sylvester)
Cc :   &nb= sp;    pkix@ietf.org
Date :    =    30/06/2011 19:46
Objet :        [pkix] rfc3161 TimeStamps and sha1-based sigs/imprints in pkcs7/cms
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



Peter Sylvester wrote:
>
> We are sorry for them. This URL has been deprecated
> since years,  a good one can be found reading
>
>      http://timestamping.edelweb.fr
>
> Thanks for your attention and sorry for the inconvenience
> of this message for those who are not interested in timestamping

Speaking of rfc3161 timestamping, most public services seem to
be limited to sha1WithRsaEncryption { 1, 2, 840, 113549, 1, 1, 5 }
which looks like an anachronism and a security problem to me.

Are the proposals or is there a standard how to migrate to
a more resonable signature algorithm such as
sha256WithRsaEncryption { 1, 2, 840, 113549, 1, 1, 11 }

e.g. when the MessageImprint uses SHA256?

While requesting this feature explicitly through a specific
TSA policy OID would theoretically be possible, this very
same approach would be quite non-portable.

The original plan was to =5Fhave=5Fcompleted=5F phasing out the use of SHA-= 1
for digital signatures by the end of 2010, but that target seems to
have been missed entirely.  There is a significant availability of
RSA 2048-bit certificates, but the use of sha256WithRsaEncryption
is still at homeopathic levels.


The purpose of rfc3161 timestamps is to prove that something existed
before or at a certain time, and the two most common uses I can
think of are:

   - determine whether a digital signature was created within
     the validity period of the signer certificate

   - determine whether a digital signature was created before
     the point in time when the signer certificate was revoked

Both these cases, a purposes looking into the future, sometimes
far into the future (think e.g. about signed&timestamped code),
and I seriously question the security of timestamps with
sha1-based signatures (or sha1-based message imprints or the
original, often indirect signatures on the underlying pkcs7/CMS)
for purposes with a useful lifetime of many years into the future.


-Martin

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 0041D608C12578C0_=-- From mrex@sap.com Fri Jul 1 17:19:26 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBB39E800A for ; Fri, 1 Jul 2011 17:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.165 X-Spam-Level: X-Spam-Status: No, score=-10.165 tagged_above=-999 required=5 tests=[AWL=0.084, 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 2BP4ZXaBIoNB for ; Fri, 1 Jul 2011 17:19:26 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 92E549E8005 for ; Fri, 1 Jul 2011 17:19:25 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p620JIq0020688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 2 Jul 2011 02:19:23 +0200 (MEST) From: Martin Rex Message-Id: <201107020019.p620JIr6010121@fs4113.wdf.sap.corp> To: denis.pinkas@bull.net Date: Sat, 2 Jul 2011 02:19:18 +0200 (MEST) In-Reply-To: from "denis.pinkas@bull.net" at Jul 1, 11 01:59:36 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] rfc3161 TimeStamps and sha1-based sigs/imprints in pkcs7/cms X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 00:19:26 -0000 denis.pinkas@bull.net wrote: > > You seriously question the security of timestamps with sha1-based > signatures. Yes. ;-) I believe one of the things I'm looking for is sometimes referred to as "Hash Agility"-- here for rfc3161 TimeStamps, and as a result interop of such agility between independent implementations (rfc3161 TSA/Servers and rfc3161 TS-requesting clients). The information from Rob about the rfc3161 support in Win7 was quite useful -- I didn't know about that -- thanks, Rob. I would have assumed that rfc3161 usage scenarios created/shipped in recent years or that are being planned would require the use of SHA-2 or better hashes algorithms for message digest purposes (i.e. the MessageDigest of the timestamped PKCS7/CMS SignedData, the MessageDigest of the TimeStampToken SignedData and the HashAlgorithm of the MessageImprint within TSTInfo.) or that they would have a migration plan for switching to SHA-2 or better. (Timestamped) digital signatures on code should IMHO anticipate useful validation lifetimes of >10 years. If there is reason to worry about the security of SHA-1 for digital signatures, it applies much more to digital signatures on code, which is expected to still validate OK in 10 years, than to X.509 certs for online authentication with a validity of one year. Also, if you're upping the keylength of your assymetric crypto (like RSA-1024 -> RSA-2048) it seems awkward to continue using SHA-1 because of the resulting crypto-imbalance. You take an 8x performance hit for RSA-2048 over RSA-1024 on RSA crypto operations, but your effective security level remains unchanged at 80-bit comparable symmetric crypto strength if you continue to use SHA-1. That make a move from RSA-1024 to RSA-2048 but no SHA-2 a marketing stunt / security theater that wastes significant computing resources (on the RSA crypto operations) for no real security benefit. Admittedly, it is not clear that SHA-1 is the weakest spot in the security of the entire system, e.g. http://xkcd.com/538/ but the performance hit when moving from RSA-1024 to RSA-2048 might be significant enough to deserve considerations of the real benefits/ROI of an imbalanced crypto algorithm move. > > Formats have been described on how to address this issue in general, > i.e. when the hash function becomes weak. > > Such formats exist in the context of Advanced Electronic Signatures with > the AdES-A format as defined by ETSI for CAdES and XAdES. > > Basically, the problem to "renew a time-stamp" does not happen first > because the hash function becomes weak, but because the validity period > of the TSU certificate is over. There is a difference between signed+timestamped stuff that I archive myself and intend to keep as proof (against others) that I can eventually show as evidence, and signed+timestamped stuff that I want to use to reassure myself that it is still what I originally recived (or what the signer originally signed), like signed code / software distributions. These might be hardware device drivers on installation media accompanying the hardware or distributed as software updates over the internet, but also application software (not all software is as "exposed" and as bugridden as some active content browser-plugin that needs to be newly redistributed in its entirety once per week). > > A new TST must then be used to protect the previous one. > > It must then be demonstrated that, at the time the new TST was applied, > the certificate of the previous time-stamp was not revoked with the > revocation reason "key compromise". Different to Qualified/Advanded Electronic Signatures where a lot of constraints are non-technical and subject to legislative regulation, Software distributors usually have the option to use longer validity for their TSA cert and they can redistribute newly signed×tamped code as an alternative to recursively timestamp old software packages. For software distribution, the motivation for timestamping is more likely finer grained damage control, when having to revoke a signing cert that got compromised. -Martin From era@x500.eu Tue Jul 5 23:34:51 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E0C21F8677 for ; Tue, 5 Jul 2011 23:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.011 X-Spam-Level: * X-Spam-Status: No, score=1.011 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DK=1.009, 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 1+7VpT2pFQZ1 for ; Tue, 5 Jul 2011 23:34:50 -0700 (PDT) Received: from mail01.dandomain.dk (mail01.dandomain.dk [194.150.112.201]) by ietfa.amsl.com (Postfix) with ESMTP id 57F0121F862E for ; Tue, 5 Jul 2011 23:34:49 -0700 (PDT) Received: from Morten ([94.191.246.200]) by mail01.dandomain.dk (DanDomain Mailserver) with ASMTP id PNO11347; Wed, 06 Jul 2011 08:34:47 +0200 From: "Erik Andersen" To: "Directory list" , "SG17-Q11" , "PKIX" Date: Wed, 6 Jul 2011 08:34:39 +0200 Message-ID: <000901cc3ba6$cc97c490$65c74db0$@eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CC3BB7.90209490" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw7psf+KN1+17eoSPOazbD9xs5czw== Content-Language: da Subject: [pkix] DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 06:34:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01CC3BB7.90209490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi folks, In contrast to RFC 5280, X.509 does not require DER encoding. It only requires that the signature is generated across a DER encoded certificate, but the itself certificate may be encoded using BER. Should we add a sentence somewhere in X.509 and possibly in RFC 5280 specifying that when verifying a signature a relying party shall decode and then encode the certificate in DER to verifying the signature? Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik ------=_NextPart_000_000A_01CC3BB7.90209490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = folks,

 

In contrast to RFC 5280,  X.509 does not require = DER encoding. It only requires that the signature is generated across a = DER encoded certificate, but the itself certificate may be encoded using = BER.

 

Should we add a sentence somewhere in X.509 and = possibly in RFC 5280 specifying that when verifying a signature a = relying party shall decode and then encode the certificate in DER to = verifying the signature?

 

Erik = Andersen

Andersen's = L-Service

Elsevej = 48,

DK-3500 = Vaerloese

Denmark=

Mobile: +45 2097 = 1490

e-amail: era@x500.eu

Skype: = andersen-erik

http://www.x500.eu/

http://www.x500standard.c= om/

http://dk.linkedin.com/in= /andersenerik

 

------=_NextPart_000_000A_01CC3BB7.90209490-- From carl@redhoundsoftware.com Wed Jul 6 05:01:26 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E59F21F85EB for ; Wed, 6 Jul 2011 05:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 W9I9sgkIX6iB for ; Wed, 6 Jul 2011 05:01:24 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2524421F85E3 for ; Wed, 6 Jul 2011 05:01:24 -0700 (PDT) Received: by qyk29 with SMTP id 29so5381752qyk.10 for ; Wed, 06 Jul 2011 05:01:23 -0700 (PDT) Received: by 10.229.98.16 with SMTP id o16mr6242565qcn.277.1309953681644; Wed, 06 Jul 2011 05:01:21 -0700 (PDT) Received: from [192.168.1.5] (pool-173-79-129-248.washdc.fios.verizon.net [173.79.129.248]) by mx.google.com with ESMTPS id u10sm3069476qct.21.2011.07.06.05.01.16 (version=SSLv3 cipher=OTHER); Wed, 06 Jul 2011 05:01:19 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 06 Jul 2011 08:01:14 -0400 From: Carl Wallace To: Erik Andersen , Directory list , SG17-Q11 , PKIX Message-ID: Thread-Topic: [pkix] DER encoding of certificates In-Reply-To: <000901cc3ba6$cc97c490$65c74db0$@eu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3392784078_8503876" Subject: Re: [pkix] DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 12:01:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3392784078_8503876 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit No. For one reason, verifiers may not know how to DER encode some extensions. It'd be better to require DER or require verification to use toBeSigned bytes as they appear (be they BER or DER). From: Erik Andersen Date: Wed, 6 Jul 2011 08:34:39 +0200 To: Directory list , SG17-Q11 , PKIX Subject: [pkix] DER encoding of certificates > Hi folks, > > In contrast to RFC 5280, X.509 does not require DER encoding. It only > requires that the signature is generated across a DER encoded certificate, but > the itself certificate may be encoded using BER. > > Should we add a sentence somewhere in X.509 and possibly in RFC 5280 > specifying that when verifying a signature a relying party shall decode and > then encode the certificate in DER to verifying the signature? > > Erik Andersen > Andersen's L-Service > Elsevej 48, > DK-3500 Vaerloese > Denmark > Mobile: +45 2097 1490 > e-amail: era@x500.eu > Skype: andersen-erik > http://www.x500.eu/ > http://www.x500standard.com/ > http://dk.linkedin.com/in/andersenerik > > > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3392784078_8503876 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
No.  For one reason, ve= rifiers may not know how to DER encode some extensions.  It'd be better= to require DER or require verification to use toBeSigned bytes as they appe= ar (be they BER or DER).  

From: Erik Andersen <era@x500.eu= >
Date: Wed, 6 Jul 2011 08:= 34:39 +0200
To: Directory list <= ;x500standard@freelists.org&= gt;, SG17-Q11 <t09sg17q11@lists= .itu.int>, PKIX <pkix@ietf.org&= gt;
Subject: [pkix] DER encoding o= f certificates

Hi folks,

<= p class=3D"MsoNormal"> 

In contrast to= RFC 5280,  X.509 does not require DER encoding. It only requires that = the signature is generated across a DER encoded certificate, but the itself = certificate may be encoded using BER.

 

Should we add a sentence somewhere in= X.509 and possibly in RFC 5280 specifying that when verifying a signature a= relying party shall decode and then encode the certificate in DER to verify= ing the signature?

 

=

Erik Andersen

Andersen's L-Service

Elsevej 48,

= DK-3500 Vaerlo= ese

Denmark

Mobile: +45 2097 1= 490

e-amail: era@x500.eu

Skype: anders= en-erik

http://www= .x500.eu/

ht= tp://www.x500standard.com/

http://dk.linkedin.com/in/andersenerik

 

_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3392784078_8503876-- From mrex@sap.com Wed Jul 6 06:40:11 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB3721F871D for ; Wed, 6 Jul 2011 06:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.183 X-Spam-Level: X-Spam-Status: No, score=-10.183 tagged_above=-999 required=5 tests=[AWL=0.066, 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 nWAlibi8iwXF for ; Wed, 6 Jul 2011 06:40:11 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id AB47D21F86E6 for ; Wed, 6 Jul 2011 06:40:10 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p66De13k011109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jul 2011 15:40:01 +0200 (MEST) From: Martin Rex Message-Id: <201107061340.p66De0vY000983@fs4113.wdf.sap.corp> To: carl@redhoundsoftware.com (Carl Wallace) Date: Wed, 6 Jul 2011 15:40:00 +0200 (MEST) In-Reply-To: from "Carl Wallace" at Jul 6, 11 08:01:14 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: x500standard@freelists.org, t09sg17q11@lists.itu.int, pkix@ietf.org Subject: Re: [pkix] DER encoding of 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: Wed, 06 Jul 2011 13:40:11 -0000 Carl Wallace wrote: > > No. For one reason, verifiers may not know how to DER encode some > extensions. It'd be better to require DER or require verification to use > toBeSigned bytes as they appear (be they BER or DER). Expecting verifiers to parse and re-encode certs before being able to verify a digital certificate seems like a very bad idea with respect to performance, reliability and complexity. The other problem is that there are too many defective ASN.1 encoders out there, some of them actively used by certificate issuers. GlobalSign has been distributing a RootCA cert in browsers that was using incorrect ASN.1 DER -- and that caused verification failures on some occasions. IIRC, the bug was in the ASN.1 encoding of the KeyUsage BIT STRING, which is a NamedBitList (and according to X.690 11.2 + X.680 21.7 tailing 0 bits must be removed in ASN.1 DER from a NamedBitList during encoding.) -Martin From SChokhani@cygnacom.com Wed Jul 6 06:56:50 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2765921F85ED for ; Wed, 6 Jul 2011 06:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Kye4xvhNsxc for ; Wed, 6 Jul 2011 06:56:49 -0700 (PDT) Received: from sottexchE2.entrust.com (sottexche2.entrust.com [216.191.252.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8A13221F85D9 for ; Wed, 6 Jul 2011 06:56:49 -0700 (PDT) Received: from scygexch7.cygnacom.com (10.4.60.22) by sottexchE2.entrust.com (216.191.252.22) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Jul 2011 09:56:28 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 6 Jul 2011 09:56:44 -0400 From: Santosh Chokhani To: "mrex@sap.com" , Carl Wallace Date: Wed, 6 Jul 2011 09:56:43 -0400 Thread-Topic: [pkix] DER encoding of certificates Thread-Index: Acw74j3l3VhmQpe1RomatiNN552HsAAAjjwQ Message-ID: References: from "Carl Wallace" at Jul 6, 11 08:01:14 am <201107061340.p66De0vY000983@fs4113.wdf.sap.corp> In-Reply-To: <201107061340.p66De0vY000983@fs4113.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: "x500standard@freelists.org" , "t09sg17q11@lists.itu.int" , "pkix@ietf.org" Subject: Re: [pkix] DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 13:56:50 -0000 Do not need to re-encode. Always keep the blob around. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mar= tin Rex Sent: Wednesday, July 06, 2011 9:40 AM To: Carl Wallace Cc: x500standard@freelists.org; t09sg17q11@lists.itu.int; pkix@ietf.org Subject: Re: [pkix] DER encoding of certificates Carl Wallace wrote: >=20 > No. For one reason, verifiers may not know how to DER encode some > extensions. It'd be better to require DER or require verification to use > toBeSigned bytes as they appear (be they BER or DER). Expecting verifiers to parse and re-encode certs before being able to verify a digital certificate seems like a very bad idea with respect to performance, reliability and complexity. The other problem is that there are too many defective ASN.1 encoders out there, some of them actively used by certificate issuers. GlobalSign has been distributing a RootCA cert in browsers that was using incorrect ASN.1 DER -- and that caused verification failures on some occasions. IIRC, the bug was in the ASN.1 encoding of the KeyUsage BIT STRING, which is a NamedBitList (and according to X.690 11.2 + X.680 21.7 tailing 0 bits must be removed in ASN.1 DER from a NamedBitList during encoding.) -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From peterryb@gmail.com Tue Jul 5 23:52:07 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870F221F86A0 for ; Tue, 5 Jul 2011 23:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzjLHgQF3n8i for ; Tue, 5 Jul 2011 23:52:06 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1006421F8639 for ; Tue, 5 Jul 2011 23:52:05 -0700 (PDT) Received: by qwc23 with SMTP id 23so5712701qwc.31 for ; Tue, 05 Jul 2011 23:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AcV/0pjjzNNwiUfME9te/guml3DZWwN//Up73FPooT4=; b=tnlS+P2eqsqZ2ZQILgdBRHkqHvZYFPDD8lNMoIl1a2iOEar7Olqih5vQXnnukRBaXq OZdEco8+0B2+QEWSwclB1+91IjuRw7MYJE0YSdtYj5OXof54a5vaE/CRXmwhH+ovOkFh BCjm47NxY/CqtMfAqsPmKBUxBP8M8G31Ml0sA= MIME-Version: 1.0 Received: by 10.229.26.84 with SMTP id d20mr5949734qcc.203.1309935124424; Tue, 05 Jul 2011 23:52:04 -0700 (PDT) Received: by 10.229.33.68 with HTTP; Tue, 5 Jul 2011 23:52:04 -0700 (PDT) In-Reply-To: <000901cc3ba6$cc97c490$65c74db0$@eu> References: <000901cc3ba6$cc97c490$65c74db0$@eu> Date: Wed, 6 Jul 2011 08:52:04 +0200 Message-ID: From: Peter Rybar To: Erik Andersen Content-Type: multipart/alternative; boundary=0016364ede82c5281904a761090d X-Mailman-Approved-At: Wed, 06 Jul 2011 07:29:24 -0700 Cc: Directory list , SG17-Q11 , PKIX Subject: Re: [pkix] DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 06:52:07 -0000 --0016364ede82c5281904a761090d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Erik, detail information is in ITU-T X.509 http://www.itu.int/rec/T-REC-X.509-200508-I RFC 5280 is only a profile for Internet on-line services like TSL/SSL, ... ITU-T Rec. X.509 (08/2005) 6.1 Digital signatures The value of the bit string is generated by taking the octets which form th= e complete encoding (using the ASN.1 Basic Encoding Rules =E2=80=93 ITU-T Rec= . X.690 (2002) | ISO/IEC 8825-1:2002) of the value of the ToBeEnciphered type and applying an encipherment procedure to those octets. New certificates for any test or use you can generate in "Utility" tab, "Ne= w Key" button. http://lockitin.webnode.sk/products/produkt-1/ Peter Rybar National Security Authority Information Security and Electronic Signature Department Budatinska 30, 850 07 Bratislava 57, Slovak Republic tel.: +421 2 6869 2163 mob.: +421 902 891 155 fax: +421 2 6869 1701 e-mail: peter.rybar@nbusr.sk e-mail: peterryb@gmail.com 2011/7/6 Erik Andersen > Hi folks, > > > > In contrast to RFC 5280, X.509 does not require DER encoding. It only > requires that the signature is generated across a DER encoded certificate= , > but the itself certificate may be encoded using BER. > > > > Should we add a sentence somewhere in X.509 and possibly in RFC 5280 > specifying that when verifying a signature a relying party shall decode a= nd > then encode the certificate in DER to verifying the signature? > > > > Erik Andersen > > Andersen's L-Service > > Elsevej 48, > > DK-3500 Vaerloese > > Denmark > > Mobile: +45 2097 1490 > > e-amail: era@x500.eu > > Skype: andersen-erik > > http://www.x500.eu/ > > http://www.x500standard.com/ > > http://dk.linkedin.com/in/andersenerik > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > --0016364ede82c5281904a761090d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Erik,

detail information is in ITU-T X.50= 9

RFC 5280 = is only a profile for Internet on-line services like TSL/SSL, ...

ITU-T Rec. X.509 (08/2005)
6.1 Digital signat= ures
The value of the bit string is generated by taking the octet= s which form the complete encoding (using the ASN.1 Basic Encoding Rules = =E2=80=93 ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002) of the value of th= e ToBeEnciphered type and applying an encipherment procedure to those octet= s.

New certificates for any test or use you can generate i= n "Utility" tab, "New Key" button.

Peter Rybar

National Security Authority
Information Security and Electronic Signature Department
Budatinska 30, 850 07 Bratislava 57, Slovak Republic
tel.: +421 2 6869 2163
mob.: +421 902 891 155
fax: +421 2 6869 1701
e-mail: peter.rybar@nbusr.sk

e-mail= : peterryb@gmail.com

2011/7= /6 Erik Andersen <era@x= 500.eu>

Hi folks,

=C2=A0

In= contrast to RFC 5280,=C2=A0 X.509 does not require DER encoding. It only r= equires that the signature is generated across a DER encoded certificate, b= ut the itself certificate may be encoded using BER.

=C2=A0

Should we add a sen= tence somewhere in X.509 and possibly in RFC 5280 specifying that when veri= fying a signature a relying party shall decode and then encode the certific= ate in DER to verifying the signature?

=C2=A0

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese<= /p>

Denmark

Mobile: +45 2097 1490

e-amail: era@x500.eu

Skype: andersen-erik

http://www.x500.eu/

ht= tp://www.x500standard.com/

http://dk.linkedin.com/in/= andersenerik

=C2=A0


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


--0016364ede82c5281904a761090d-- From rbarnes@bbn.com Wed Jul 6 08:37:42 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFEA21F8605 for ; Wed, 6 Jul 2011 08:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Gej6q8m978p for ; Wed, 6 Jul 2011 08:37:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id AF36321F866C for ; Wed, 6 Jul 2011 08:37:40 -0700 (PDT) Received: from [192.1.255.156] (port=64668 helo=col-dhcp-192-1-255-156.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QeUAS-000Pzb-5X; Wed, 06 Jul 2011 11:37:36 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 6 Jul 2011 11:37:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9C52F283-BCD7-4943-B909-438C1ABA4D32@bbn.com> References: from "Carl Wallace" at Jul 6, 11 08:01:14 am <201107061340.p66De0vY000983@fs4113.wdf.sap.corp> To: Santosh Chokhani X-Mailer: Apple Mail (2.1082) Cc: "x500standard@freelists.org" , "t09sg17q11@lists.itu.int" , "pkix@ietf.org" Subject: Re: [pkix] DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 15:37:42 -0000 Don't you then run into the question of whether the DER blob is the same = as the non-DER bits? --Richard On Jul 6, 2011, at 9:56 AM, Santosh Chokhani wrote: > Do not need to re-encode. Always keep the blob around. >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of Martin Rex > Sent: Wednesday, July 06, 2011 9:40 AM > To: Carl Wallace > Cc: x500standard@freelists.org; t09sg17q11@lists.itu.int; = pkix@ietf.org > Subject: Re: [pkix] DER encoding of certificates >=20 > Carl Wallace wrote: >>=20 >> No. For one reason, verifiers may not know how to DER encode some >> extensions. It'd be better to require DER or require verification to = use >> toBeSigned bytes as they appear (be they BER or DER). >=20 > Expecting verifiers to parse and re-encode certs before being able > to verify a digital certificate seems like a very bad idea with > respect to performance, reliability and complexity. >=20 >=20 > The other problem is that there are too many defective ASN.1 encoders > out there, some of them actively used by certificate issuers. > GlobalSign has been distributing a RootCA cert in browsers that > was using incorrect ASN.1 DER -- and that caused verification > failures on some occasions. IIRC, the bug was in the ASN.1 > encoding of the KeyUsage BIT STRING, which is a NamedBitList > (and according to X.690 11.2 + X.680 21.7 tailing 0 bits must > be removed in ASN.1 DER from a NamedBitList during encoding.) >=20 >=20 > -Martin > _______________________________________________ > 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 Wed Jul 6 08:40:53 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3715E21F8794 for ; Wed, 6 Jul 2011 08:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbrUQKpqevpW for ; Wed, 6 Jul 2011 08:40:52 -0700 (PDT) Received: from sottexchE1.entrust.com (sottexche1.entrust.com [216.191.252.21]) by ietfa.amsl.com (Postfix) with ESMTP id 68EF021F8792 for ; Wed, 6 Jul 2011 08:40:52 -0700 (PDT) Received: from scygexch7.cygnacom.com (10.4.60.22) by sottexchE1.entrust.com (216.191.252.21) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Jul 2011 11:40:32 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 6 Jul 2011 11:40:49 -0400 From: Santosh Chokhani To: "Richard L. Barnes" Date: Wed, 6 Jul 2011 11:40:48 -0400 Thread-Topic: [pkix] DER encoding of certificates Thread-Index: Acw78qNvFZjnS6uVR9aAPPOB5vznzQAAB1VQ Message-ID: References: from "Carl Wallace" at Jul 6, 11 08:01:14 am <201107061340.p66De0vY000983@fs4113.wdf.sap.corp> <9C52F283-BCD7-4943-B909-438C1ABA4D32@bbn.com> In-Reply-To: <9C52F283-BCD7-4943-B909-438C1ABA4D32@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "x500standard@freelists.org" , "t09sg17q11@lists.itu.int" , "pkix@ietf.org" Subject: Re: [pkix] DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 15:40:53 -0000 (BTW, messages to one mail list seem to get rejected). I do not see an issue. The signer signs something. You verify it. You ke= ep and transmit the blob and signature. You or anyone can decode the blob = and as long as decoding is definitive (which to my knowledge is), no proble= ms or ambiguities should be encountered. -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 Sent: Wednesday, July 06, 2011 11:37 AM To: Santosh Chokhani Cc: mrex@sap.com; Carl Wallace; x500standard@freelists.org; t09sg17q11@list= s.itu.int; pkix@ietf.org Subject: Re: [pkix] DER encoding of certificates Don't you then run into the question of whether the DER blob is the same as= the non-DER bits? --Richard On Jul 6, 2011, at 9:56 AM, Santosh Chokhani wrote: > Do not need to re-encode. Always keep the blob around. >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of M= artin Rex > Sent: Wednesday, July 06, 2011 9:40 AM > To: Carl Wallace > Cc: x500standard@freelists.org; t09sg17q11@lists.itu.int; pkix@ietf.org > Subject: Re: [pkix] DER encoding of certificates >=20 > Carl Wallace wrote: >>=20 >> No. For one reason, verifiers may not know how to DER encode some >> extensions. It'd be better to require DER or require verification to us= e >> toBeSigned bytes as they appear (be they BER or DER). >=20 > Expecting verifiers to parse and re-encode certs before being able > to verify a digital certificate seems like a very bad idea with > respect to performance, reliability and complexity. >=20 >=20 > The other problem is that there are too many defective ASN.1 encoders > out there, some of them actively used by certificate issuers. > GlobalSign has been distributing a RootCA cert in browsers that > was using incorrect ASN.1 DER -- and that caused verification > failures on some occasions. IIRC, the bug was in the ASN.1 > encoding of the KeyUsage BIT STRING, which is a NamedBitList > (and according to X.690 11.2 + X.680 21.7 tailing 0 bits must > be removed in ASN.1 DER from a NamedBitList during encoding.) >=20 >=20 > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From kent@bbn.com Wed Jul 6 10:39:00 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A852F21F8984 for ; Wed, 6 Jul 2011 10:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9XtqgsBB9b8 for ; Wed, 6 Jul 2011 10:38:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A191C21F8987 for ; Wed, 6 Jul 2011 10:38:59 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]:49222) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QeW3o-0001cn-TC; Wed, 06 Jul 2011 13:38:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <000901cc3ba6$cc97c490$65c74db0$@eu> Date: Wed, 6 Jul 2011 13:03:21 -0400 To: Peter Rybar From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-902148564==_ma============" Cc: Directory list , SG17-Q11 , PKIX Subject: Re: [pkix] DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:39:00 -0000 --============_-902148564==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 8:52 AM +0200 7/6/11, Peter Rybar wrote: >Erik, > > >detail information is in ITU-T X.509 >http://www.itu.int/rec/T-REC-X.509-200508-I > >RFC 5280 is only a profile for Internet on-line services like TSL/SSL, ... not quite sure what you mean by "on-line services." Look at the LTANS WG, which deals with long term storage of signed data. Their RFCs cite 5280 (or its predecessor, 3280) as normative. Steve --============_-902148564==_ma============ Content-Type: text/html; charset="us-ascii" Re: [pkix] DER encoding of certificates
At 8:52 AM +0200 7/6/11, Peter Rybar wrote:
Erik,

detail information is in ITU-T X.509
http://www.itu.int/rec/T-REC-X.509-200508-I

RFC 5280 is only a profile for Internet on-line services like TSL/SSL, ...

not quite sure what you mean by "on-line services." Look at the LTANS WG, which deals with long term storage of signed data. Their RFCs cite 5280 (or its predecessor, 3280) as normative.

Steve

--============_-902148564==_ma============-- From era@x500.eu Wed Jul 6 23:44:12 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C9121F88A1 for ; Wed, 6 Jul 2011 23:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 AtCjlrKW3kyV for ; Wed, 6 Jul 2011 23:44:11 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF9D21F881C for ; Wed, 6 Jul 2011 23:44:10 -0700 (PDT) Received: from Morten ([79.138.242.31]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id QNZ89307; Thu, 07 Jul 2011 08:44:07 +0200 From: "Erik Andersen" To: , "SG17-Q11" , "PKIX" References: <000901cc3ba6$cc97c490$65c74db0$@eu> <4E140D1A.4010001@eNitiatives.com.au> In-Reply-To: <4E140D1A.4010001@eNitiatives.com.au> Date: Thu, 7 Jul 2011 08:44:02 +0200 Message-ID: <000e01cc3c71$459140e0$d0b3c2a0$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw7rWqO87PCU5HyTWuuSStCbyn+9gAvYkHQ Content-Language: da Subject: Re: [pkix] [Spam] Re: [x500standard] DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 06:44:12 -0000 Hi Steven, Santosh, and others 6.1 of X.509 the HASH information object states that -- shall be the result of applying a hashing procedure to the DER-encoded octets -- -- of a value of --ToBeHashed The ENCRYPTED-HASH also states -- shall be the result of applying a hashing procedure to the DER-encoded (see 6.1) octets -- The SIGNATURE information object class refers to ENCRYPTED-HASH. Already the 1988 edition required signatures based on DER encoding. Clearly, the X.509 requires and have always required signatures to be performed over the DER encoded data. I have a problem with requiring the standard to take into account non-conforming implementations. However, my proposal was partly a provocation to see the reaction. I see three possible solutions: 1) The decoding and re-encoding in DER as it has been discussed 2) Remove the DER requirements from 6.1 of X.509 3) Mandate use of DER encoding for certificates and other similar data types. This would also include signed operations. Implementations will then always perform signature check over the "blob" (which could be BER encoded). We will still have non-conformant implementations, but they would work and X.509 would be consistent. For some peculiar reasons, Extensions shall always be DER encoded. This requirement was introduced already in 1997, when the concept of extensions was introduced. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: Steven Legg [mailto:steven.legg@enitiatives.com.au] Sendt: 6. juli 2011 09:22 Til: x500standard@freelists.org Cc: Erik Andersen Emne: [Spam] Re: [x500standard] DER encoding of certificates Erik, On 6/07/2011 4:34 PM, Erik Andersen wrote: > Hi folks, > > In contrast to RFC 5280, X.509 does not require DER encoding. It only requires that the signature is > generated across a DER encoded certificate, but the itself certificate may be encoded using BER. > > Should we add a sentence somewhere in X.509 and possibly in RFC 5280 specifying that when verifying a > signature a relying party shall decode and then encode the certificate in DER to verifying the signature? That would cause more problems than it solves because all too often in the real world signatures are calculated over the BER encoding that is transmitted rather than the DER encoding it is supposed to be calculated over. Erik Andersen wrote: > If the RDN is part of a primary distinguished name, the primaryDistinguished > component is TRUE and the valueWithContext shall not be included. If in addition, > the primaryDistnguished component is absent taking the default value, the encoding > of a 5280 certificate and the encoding of an X.509 certificate are identical. > However, if the primaryDistingished component is present and takes the value TRUE, > a X.509 certificate will be different from a 5280 certificate and may not be > accepted by all systems. Apparently, some tool will always add the primaryDistingished > component with the value TRUE. Is this an observed problem or a theoretical one ? A decoder using the 5280 definition may well treat the AttributeTypeAndValue type as implicitly extensible, in which case the primaryDistinguished component will be an unknown extension that is gracefully ignored. The certificate couldn't be re-encoded in DER, but that's not a wise thing to do anyway for the reason above. Regards, Steven > > Erik Andersen > > Andersen's L-Service > > Elsevej 48, > > DK-3500 Vaerloese > > Denmark > > Mobile: +45 2097 1490 > > e-amail: era@x500.eu > > Skype: andersen-erik > > http://www.x500.eu/ > > http://www.x500standard.com/ > > http://dk.linkedin.com/in/andersenerik > From peter.sylvester@edelweb.fr Thu Jul 7 02:13:30 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E2521F8789 for ; Thu, 7 Jul 2011 02:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 YkPdEZJa7ije for ; Thu, 7 Jul 2011 02:13:25 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id E53C021F87C7 for ; Thu, 7 Jul 2011 02:13:23 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 9B25B7FBD; Thu, 7 Jul 2011 11:13:22 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 474DE16F64; Thu, 7 Jul 2011 11:13:22 +0200 (CEST) Received: from [192.168.18.186] (unknown [192.168.18.186]) by smtps.on-x.com (Postfix) with ESMTP id 3C1D6782B; Thu, 7 Jul 2011 11:13:22 +0200 (CEST) Message-ID: <4E1578FD.6090705@edelweb.fr> Date: Thu, 07 Jul 2011 11:14:37 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Erik Andersen References: <000901cc3ba6$cc97c490$65c74db0$@eu> <4E140D1A.4010001@eNitiatives.com.au> <000e01cc3c71$459140e0$d0b3c2a0$@eu> In-Reply-To: <000e01cc3c71$459140e0$d0b3c2a0$@eu> Content-Type: multipart/alternative; boundary="------------000607050801070806090104" Cc: x500standard@freelists.org, SG17-Q11 , PKIX Subject: Re: [pkix] [Spam] Re: [x500standard] DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 09:13:30 -0000 This is a multi-part message in MIME format. --------------000607050801070806090104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit removing a DER requirement is unacceptable. Most implementations tolerate certain deviations from DER (the second half of point a below for example) are probably not prepared to handle a violation of the first part of point a. I think the following text in X/509 is sufficiently clear (assuming that we are all in THE directory): In 6.1 : (draft version 2008): Generating a distinguished encoding requires the abstract syntax of the data to be encoded to be fully understood. The Directory may be required to sign data or check the signature of data that contains unknown protocol extensions or unknown attribute syntaxes. The Directory shall follow these rules: -- It shall preserve the encoding of received information whose abstract syntax it does not fully know and which it expects to subsequently sign; -- When signing data for sending, it shall send data whose syntax it fully knows with a distinguished encoding and any other data with its preserved encoding, and shall sign the actual encoding it sends; -- When checking signatures in received data, it shall check the signature against the actual data received rather than its conversion of the received data to a distinguished encoding. == too bad that this doesn't work if one wants to work with XER only. The text above in 6.1 (with comments inline) SIGNED { ToBeSigned } ::= SEQUENCE { *toBeSigned ToBeSigned,* *COMPONENTS OF SIGNATURE { ToBeSigned } }* In order to enable the validation of *SIGNED* and *SIGNATURE* types in a distributed environment, a distinguished encoding is required. PS: == a distinguished encoding is only required if one decodes and reencodes which is not what is recommended later. Nevertheless, this is not a reason to remove the requirement for the encoding and open it to an arbitrary BER. A distinguished encoding of a *SIGNED* or *SIGNATURE* data value shall be obtained by applying the Basic Encoding Rules defined in ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002, with the following restrictions: a) the definite form of length encoding shall be used, encoded in the minimum number of octets; b) for string types, the constructed form of encoding shall not be used; c) if the value of a type is its default value, it shall be absent; d) the components of a Set type shall be encoded in ascending order of their tag value; e) the components of a Set-of type shall be encoded in ascending order of their octet value; f) if the value of a Boolean type is true, the encoding shall have its contents octet set to "FF"16; g) each unused bit in the final octet of the encoding of a Bit String value, if there are any, shall be set to zero; h) the encoding of a Real type shall be such that bases 8, 10, and 16 shall not be used, and the binary scaling factor shall be zero. i) the encoding of a UTC time shall be as specified in ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002; j) the encoding of a Generalized time shall be as specified in ITU-T Rec. X.690 (2002) | ISO/IEC 8825 1:2002. PS: == the points above are just a description of DER? This part of the text shouldn't be there and simply reference DER (which is actually done in the comments like in *ENCRYPTED-HASH { ToBeSigned } ::= BIT STRING ( CONSTRAINED BY {* /-- shall be the result of applying a hashing procedure to the DER-encoded (see 6.1) octets --/ */-- of a value of -- ToBeSigned -- and then applying an encipherment procedure to those octets -- /}) * A very bad style to define meaning in comments IMO (without doing it in the text). On 07/07/2011 08:44 AM, Erik Andersen wrote: > Hi Steven, Santosh, and others > > 6.1 of X.509 the HASH information object states that > > -- shall be the result of applying a hashing procedure to the DER-encoded > octets -- > -- of a value of --ToBeHashed > > The ENCRYPTED-HASH also states > > -- shall be the result of applying a hashing procedure to the DER-encoded > (see 6.1) octets -- > > The SIGNATURE information object class refers to ENCRYPTED-HASH. > > Already the 1988 edition required signatures based on DER encoding. > > Clearly, the X.509 requires and have always required signatures to be > performed over the DER encoded data. > > I have a problem with requiring the standard to take into account > non-conforming implementations. However, my proposal was partly a > provocation to see the reaction. > > I see three possible solutions: > > 1) The decoding and re-encoding in DER as it has been discussed X.509 does not require this and recommends against. (see above) > 2) Remove the DER requirements from 6.1 of X.509 This will break any conformant and strict verifiers, and many tolerant verifiers. > 3) Mandate use of DER encoding for certificates and other similar data > types. This would also include signed operations. Implementations will then > always perform signature check over the "blob" (which could be BER encoded). Isn't that exactly what X.509 says. > We will still have non-conformant implementations, but they would work and > X.509 would be consistent. Consistency and compatibility in time is not exactly where X standards are the best. (x400 84 vs 88, well that's old) recent X.509 keyusage changes breaks XER decoders (Non Repudiation vs Contentcommitment). Since two names are allowed for the same bit there is no longer a distinguished XML encoding possible. > For some peculiar reasons, Extensions shall always be DER encoded. This > requirement was introduced already in 1997, when the concept of extensions > was introduced. It is for exactly the same reason, to have a distinguished encoding. With extensions it has become even impossible to decode them and reencode completely. regards Peter Sylvester > Erik Andersen > Andersen's L-Service > Elsevej 48, > DK-3500 Vaerloese > Denmark > Mobile: +45 2097 1490 > e-amail: era@x500.eu > Skype: andersen-erik > http://www.x500.eu/ > http://www.x500standard.com/ > http://dk.linkedin.com/in/andersenerik > > > -----Oprindelig meddelelse----- > Fra: Steven Legg [mailto:steven.legg@enitiatives.com.au] > Sendt: 6. juli 2011 09:22 > Til: x500standard@freelists.org > Cc: Erik Andersen > Emne: [Spam] Re: [x500standard] DER encoding of certificates > > > Erik, > > On 6/07/2011 4:34 PM, Erik Andersen wrote: >> Hi folks, >> >> In contrast to RFC 5280, X.509 does not require DER encoding. It only > requires that the signature is >> generated across a DER encoded certificate, but the itself certificate may > be encoded using BER. >> Should we add a sentence somewhere in X.509 and possibly in RFC 5280 > specifying that when verifying a >> signature a relying party shall decode and then encode the certificate in > DER to verifying the signature? > > That would cause more problems than it solves because all too often in > the real world signatures are calculated over the BER encoding that is > transmitted rather than the DER encoding it is supposed to be calculated > over. > > Erik Andersen wrote: > > If the RDN is part of a primary distinguished name, the > primaryDistinguished > > component is TRUE and the valueWithContext shall not be included. If in > addition, > > the primaryDistnguished component is absent taking the default value, the > encoding > > of a 5280 certificate and the encoding of an X.509 certificate are > identical. > > However, if the primaryDistingished component is present and takes the > value TRUE, > > a X.509 certificate will be different from a 5280 certificate and may not > be > > accepted by all systems. Apparently, some tool will always add the > primaryDistingished > > component with the value TRUE. > > Is this an observed problem or a theoretical one ? A decoder using the 5280 > definition may well treat the AttributeTypeAndValue type as implicitly > extensible, in which case the primaryDistinguished component will be an > unknown extension that is gracefully ignored. The certificate couldn't be > re-encoded in DER, but that's not a wise thing to do anyway for the reason > above. > > Regards, > Steven > >> Erik Andersen >> >> Andersen's L-Service >> >> Elsevej 48, >> >> DK-3500 Vaerloese >> >> Denmark >> >> Mobile: +45 2097 1490 >> >> e-amail: era@x500.eu >> >> Skype: andersen-erik >> >> http://www.x500.eu/ >> >> http://www.x500standard.com/ >> >> http://dk.linkedin.com/in/andersenerik >> > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------000607050801070806090104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit


removing a DER requirement is unacceptable. Most implementations tolerate
certain deviations from DER (the second half of point a below for example)
are probably not prepared to handle a violation of the first part of point a.

I think the following text in X/509 is sufficiently clear (assuming that we are all in THE directory):

In 6.1 : (draft version 2008):

Generating a distinguished encoding requires the abstract syntax of the data to be encoded to be fully understood. The Directory may be required to sign data or check the signature of data that contains unknown protocol extensions or unknown attribute syntaxes. The Directory shall follow these rules:

– It shall preserve the encoding of received information whose abstract syntax it does not fully know and which it expects to subsequently sign;

– When signing data for sending, it shall send data whose syntax it fully knows with a distinguished encoding and any other data with its preserved encoding, and shall sign the actual encoding it sends;

– When checking signatures in received data, it shall check the signature against the actual data received rather than its conversion of the received data to a distinguished encoding.


== too bad that this doesn't work if one wants to work with XER only. 

The text above in 6.1 (with comments inline)


SIGNED { ToBeSigned } ::= SEQUENCE {

toBeSigned ToBeSigned,

COMPONENTS OF SIGNATURE { ToBeSigned } }


In order to enable the validation of SIGNED and SIGNATURE types in a distributed environment, a distinguished encoding is required.

PS: == a distinguished encoding is only required if one decodes and reencodes which is not
what is recommended later. Nevertheless, this is not a reason to remove the
requirement for the encoding and open it to an arbitrary BER.

A distinguished encoding of a SIGNED or SIGNATURE data value shall be obtained by applying the Basic Encoding Rules defined in ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002, with the following restrictions:

a) the definite form of length encoding shall be used, encoded in the minimum number of octets;

b) for string types, the constructed form of encoding shall not be used;

c) if the value of a type is its default value, it shall be absent;

d) the components of a Set type shall be encoded in ascending order of their tag value;

e) the components of a Set-of type shall be encoded in ascending order of their octet value;

f) if the value of a Boolean type is true, the encoding shall have its contents octet set to "FF"16;

g) each unused bit in the final octet of the encoding of a Bit String value, if there are any, shall be set to zero;

h) the encoding of a Real type shall be such that bases 8, 10, and 16 shall not be used, and the binary scaling factor shall be zero.

i) the encoding of a UTC time shall be as specified in ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002;

j) the encoding of a Generalized time shall be as specified in ITU-T Rec. X.690 (2002) | ISO/IEC 8825 1:2002.


PS: == the points above are just a description of DER? This part of the text shouldn't be there and simply reference DER (which is actually done in the comments like in

ENCRYPTED-HASH { ToBeSigned } ::= BIT STRING ( CONSTRAINED BY {

-- shall be the result of applying a hashing procedure to the DER-encoded (see 6.1) octets --

-- of a value of -- ToBeSigned -- and then applying an encipherment procedure to those octets -- })

A very bad style to define meaning in comments IMO (without doing it in the text).


On 07/07/2011 08:44 AM, Erik Andersen wrote: 
Hi Steven, Santosh, and others

6.1 of X.509 the HASH information object states that

-- shall be the result of applying a hashing procedure to the DER-encoded
octets --
			-- of a value of --ToBeHashed

The ENCRYPTED-HASH also states

-- shall be the result of applying a hashing procedure to the DER-encoded
(see 6.1) octets --

The SIGNATURE information object class refers to ENCRYPTED-HASH.

Already the 1988 edition required signatures based on DER encoding.

Clearly, the X.509 requires and have always required signatures to be
performed over the DER encoded data.

I have a problem with requiring the standard to take into account
non-conforming implementations. However, my proposal was partly a
provocation to see the reaction.

I see three possible solutions:

1)	The decoding and re-encoding in DER as it has been discussed
X.509 does not require this and recommends against. (see above)
2)	Remove the DER requirements from 6.1 of X.509
This will break any conformant and strict verifiers,
and many tolerant verifiers. 
3)	Mandate use of DER encoding for certificates and other similar data
types. This would also include signed operations. Implementations will then
always perform signature check over the "blob" (which could be BER encoded).
Isn't that exactly what X.509 says. 
We will still have non-conformant implementations, but they would work and
X.509 would be consistent.
Consistency and compatibility in time is not exactly where X standards
are the best. (x400 84 vs 88, well that's old)

recent X.509 keyusage changes breaks XER decoders
(Non Repudiation vs Contentcommitment).
Since two names are allowed for the same bit there is no longer
a distinguished XML encoding possible. 

For some peculiar reasons, Extensions shall always be DER encoded. This
requirement was introduced already in 1997, when the concept of extensions
was introduced.

It is for exactly the same reason, to have a distinguished encoding.
With extensions it has become even impossible to decode
them and reencode completely.

regards
Peter Sylvester


Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: era@x500.eu
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/
http://dk.linkedin.com/in/andersenerik


-----Oprindelig meddelelse-----
Fra: Steven Legg [mailto:steven.legg@enitiatives.com.au] 
Sendt: 6. juli 2011 09:22
Til: x500standard@freelists.org
Cc: Erik Andersen
Emne: [Spam] Re: [x500standard] DER encoding of certificates


Erik,

On 6/07/2011 4:34 PM, Erik Andersen wrote:

Hi folks,

In contrast to RFC 5280, X.509 does not require DER encoding. It only

requires that the signature is

generated across a DER encoded certificate, but the itself certificate may

be encoded using BER.

Should we add a sentence somewhere in X.509 and possibly in RFC 5280

specifying that when verifying a

signature a relying party shall decode and then encode the certificate in

DER to verifying the signature?

That would cause more problems than it solves because all too often in
the real world signatures are calculated over the BER encoding that is
transmitted rather than the DER encoding it is supposed to be calculated
over.

Erik Andersen wrote:
 > If the RDN is part of a primary distinguished name, the
primaryDistinguished
 > component is TRUE and the valueWithContext shall not be included. If in
addition,
 > the primaryDistnguished component is absent taking the default value, the
encoding
 > of a 5280 certificate and the encoding of an X.509 certificate are
identical.
 > However, if the primaryDistingished component is present and takes the
value TRUE,
 > a X.509 certificate will be different from a 5280 certificate and may not
be
 > accepted by all systems. Apparently, some tool will always add the
primaryDistingished
 > component with the value TRUE.

Is this an observed problem or a theoretical one ? A decoder using the 5280
definition may well treat the AttributeTypeAndValue type as implicitly
extensible, in which case the primaryDistinguished component will be an
unknown extension that is gracefully ignored. The certificate couldn't be
re-encoded in DER, but that's not a wise thing to do anyway for the reason
above.

Regards,
Steven


Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail: era@x500.eu

Skype: andersen-erik

http://www.x500.eu/

http://www.x500standard.com/

http://dk.linkedin.com/in/andersenerik


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

--------------000607050801070806090104-- From SChokhani@cygnacom.com Thu Jul 7 04:19:24 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12B821F879C for ; Thu, 7 Jul 2011 04:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cJr1SXdKUlz for ; Thu, 7 Jul 2011 04:19:23 -0700 (PDT) Received: from sottexchE1.entrust.com (sottexche1.entrust.com [216.191.252.21]) by ietfa.amsl.com (Postfix) with ESMTP id 77A0321F850F for ; Thu, 7 Jul 2011 04:19:23 -0700 (PDT) Received: from scygexch7.cygnacom.com (10.4.60.22) by sottexchE1.entrust.com (216.191.252.21) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Jul 2011 07:18:56 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 7 Jul 2011 07:19:16 -0400 From: Santosh Chokhani To: "x500standard@freelists.org" , SG17-Q11 , PKIX Date: Thu, 7 Jul 2011 07:19:14 -0400 Thread-Topic: [x500standard] SV: [Spam] Re: DER encoding of certificates Thread-Index: Acw7rWqO87PCU5HyTWuuSStCbyn+9gAvYkHQAAshoYA= Message-ID: References: <000901cc3ba6$cc97c490$65c74db0$@eu> <4E140D1A.4010001@eNitiatives.com.au> <000e01cc3c71$459140e0$d0b3c2a0$@eu> In-Reply-To: <000e01cc3c71$459140e0$d0b3c2a0$@eu> 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] [x500standard] SV: [Spam] Re: DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 11:19:24 -0000 I would say that the order of preference should be 3, 2, and 1.=20 -----Original Message----- From: x500standard-bounce@freelists.org [mailto:x500standard-bounce@freelis= ts.org] On Behalf Of Erik Andersen Sent: Thursday, July 07, 2011 2:44 AM To: x500standard@freelists.org; SG17-Q11; PKIX Subject: [x500standard] SV: [Spam] Re: DER encoding of certificates Hi Steven, Santosh, and others 6.1 of X.509 the HASH information object states that -- shall be the result of applying a hashing procedure to the DER-encoded octets -- -- of a value of --ToBeHashed The ENCRYPTED-HASH also states -- shall be the result of applying a hashing procedure to the DER-encoded (see 6.1) octets -- The SIGNATURE information object class refers to ENCRYPTED-HASH. Already the 1988 edition required signatures based on DER encoding. Clearly, the X.509 requires and have always required signatures to be performed over the DER encoded data. I have a problem with requiring the standard to take into account non-conforming implementations. However, my proposal was partly a provocation to see the reaction. I see three possible solutions: 1) The decoding and re-encoding in DER as it has been discussed 2) Remove the DER requirements from 6.1 of X.509 3) Mandate use of DER encoding for certificates and other similar data types. This would also include signed operations. Implementations will then always perform signature check over the "blob" (which could be BER encoded)= . We will still have non-conformant implementations, but they would work and X.509 would be consistent. For some peculiar reasons, Extensions shall always be DER encoded. This requirement was introduced already in 1997, when the concept of extensions was introduced. =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: Steven Legg [mailto:steven.legg@enitiatives.com.au]=20 Sendt: 6. juli 2011 09:22 Til: x500standard@freelists.org Cc: Erik Andersen Emne: [Spam] Re: [x500standard] DER encoding of certificates Erik, On 6/07/2011 4:34 PM, Erik Andersen wrote: > Hi folks, > > In contrast to RFC 5280, X.509 does not require DER encoding. It only requires that the signature is > generated across a DER encoded certificate, but the itself certificate ma= y be encoded using BER. > > Should we add a sentence somewhere in X.509 and possibly in RFC 5280 specifying that when verifying a > signature a relying party shall decode and then encode the certificate in DER to verifying the signature? That would cause more problems than it solves because all too often in the real world signatures are calculated over the BER encoding that is transmitted rather than the DER encoding it is supposed to be calculated over. Erik Andersen wrote: > If the RDN is part of a primary distinguished name, the primaryDistinguished > component is TRUE and the valueWithContext shall not be included. If in addition, > the primaryDistnguished component is absent taking the default value, th= e encoding > of a 5280 certificate and the encoding of an X.509 certificate are identical. > However, if the primaryDistingished component is present and takes the value TRUE, > a X.509 certificate will be different from a 5280 certificate and may no= t be > accepted by all systems. Apparently, some tool will always add the primaryDistingished > component with the value TRUE. Is this an observed problem or a theoretical one ? A decoder using the 5280 definition may well treat the AttributeTypeAndValue type as implicitly extensible, in which case the primaryDistinguished component will be an unknown extension that is gracefully ignored. The certificate couldn't be re-encoded in DER, but that's not a wise thing to do anyway for the reason above. Regards, Steven > > Erik Andersen > > Andersen's L-Service > > Elsevej 48, > > DK-3500 Vaerloese > > Denmark > > Mobile: +45 2097 1490 > > e-amail: era@x500.eu > > Skype: andersen-erik > > http://www.x500.eu/ > > http://www.x500standard.com/ > > http://dk.linkedin.com/in/andersenerik > ----- www.x500standard.com: The central source for information on the X.500 Direc= tory Standard. From era@x500.eu Thu Jul 7 04:27:10 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670FC21F8799 for ; Thu, 7 Jul 2011 04:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 4VelyN4aykYQ for ; Thu, 7 Jul 2011 04:27:09 -0700 (PDT) Received: from mail01.dandomain.dk (mail01.dandomain.dk [194.150.112.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2051B21F87F0 for ; Thu, 7 Jul 2011 04:27:08 -0700 (PDT) Received: from Morten ([79.138.242.31]) by mail01.dandomain.dk (DanDomain Mailserver) with ASMTP id QSI41007; Thu, 07 Jul 2011 13:27:07 +0200 From: "Erik Andersen" To: , "'SG17-Q11'" , "'PKIX'" References: <000901cc3ba6$cc97c490$65c74db0$@eu> <4E140D1A.4010001@eNitiatives.com.au> <000e01cc3c71$459140e0$d0b3c2a0$@eu> In-Reply-To: Date: Thu, 7 Jul 2011 13:27:01 +0200 Message-ID: <004b01cc3c98$ce085590$6a1900b0$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw7rWqO87PCU5HyTWuuSStCbyn+9gAvYkHQAAshoYAAACRzIA== Content-Language: da Subject: Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 11:27:10 -0000 I have come to the same conclusion. It is clear by now that the text is already there (if you can find it). So what is needed is some text here = and there to clarify the issue. During the August meeting we will try to come up with pieces of text to = be included in the next edition. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af Santosh Chokhani Sendt: 7. juli 2011 13:19 Til: x500standard@freelists.org; SG17-Q11; PKIX Emne: Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of = certificates I would say that the order of preference should be 3, 2, and 1.=20 -----Original Message----- From: x500standard-bounce@freelists.org [mailto:x500standard-bounce@freelists.org] On Behalf Of Erik Andersen Sent: Thursday, July 07, 2011 2:44 AM To: x500standard@freelists.org; SG17-Q11; PKIX Subject: [x500standard] SV: [Spam] Re: DER encoding of certificates Hi Steven, Santosh, and others 6.1 of X.509 the HASH information object states that -- shall be the result of applying a hashing procedure to the = DER-encoded octets -- -- of a value of --ToBeHashed The ENCRYPTED-HASH also states -- shall be the result of applying a hashing procedure to the = DER-encoded (see 6.1) octets -- The SIGNATURE information object class refers to ENCRYPTED-HASH. Already the 1988 edition required signatures based on DER encoding. Clearly, the X.509 requires and have always required signatures to be performed over the DER encoded data. I have a problem with requiring the standard to take into account non-conforming implementations. However, my proposal was partly a provocation to see the reaction. I see three possible solutions: 1) The decoding and re-encoding in DER as it has been discussed 2) Remove the DER requirements from 6.1 of X.509 3) Mandate use of DER encoding for certificates and other similar data types. This would also include signed operations. Implementations will = then always perform signature check over the "blob" (which could be BER = encoded). We will still have non-conformant implementations, but they would work = and X.509 would be consistent. For some peculiar reasons, Extensions shall always be DER encoded. This requirement was introduced already in 1997, when the concept of = extensions was introduced. =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: Steven Legg [mailto:steven.legg@enitiatives.com.au]=20 Sendt: 6. juli 2011 09:22 Til: x500standard@freelists.org Cc: Erik Andersen Emne: [Spam] Re: [x500standard] DER encoding of certificates Erik, On 6/07/2011 4:34 PM, Erik Andersen wrote: > Hi folks, > > In contrast to RFC 5280, X.509 does not require DER encoding. It only requires that the signature is > generated across a DER encoded certificate, but the itself certificate = may be encoded using BER. > > Should we add a sentence somewhere in X.509 and possibly in RFC 5280 specifying that when verifying a > signature a relying party shall decode and then encode the certificate = in DER to verifying the signature? That would cause more problems than it solves because all too often in the real world signatures are calculated over the BER encoding that is transmitted rather than the DER encoding it is supposed to be calculated over. Erik Andersen wrote: > If the RDN is part of a primary distinguished name, the primaryDistinguished > component is TRUE and the valueWithContext shall not be included. If = in addition, > the primaryDistnguished component is absent taking the default value, = the encoding > of a 5280 certificate and the encoding of an X.509 certificate are identical. > However, if the primaryDistingished component is present and takes = the value TRUE, > a X.509 certificate will be different from a 5280 certificate and may = not be > accepted by all systems. Apparently, some tool will always add the primaryDistingished > component with the value TRUE. Is this an observed problem or a theoretical one ? A decoder using the = 5280 definition may well treat the AttributeTypeAndValue type as implicitly extensible, in which case the primaryDistinguished component will be an unknown extension that is gracefully ignored. The certificate couldn't = be re-encoded in DER, but that's not a wise thing to do anyway for the = reason above. Regards, Steven > > Erik Andersen > > Andersen's L-Service > > Elsevej 48, > > DK-3500 Vaerloese > > Denmark > > Mobile: +45 2097 1490 > > e-amail: era@x500.eu > > Skype: andersen-erik > > http://www.x500.eu/ > > http://www.x500standard.com/ > > http://dk.linkedin.com/in/andersenerik > ----- www.x500standard.com: The central source for information on the X.500 Directory Standard. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From hallam@gmail.com Thu Jul 7 05:11:06 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EC321F85E4 for ; Thu, 7 Jul 2011 05:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-tlbLGOmxmY for ; Thu, 7 Jul 2011 05:11:04 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF5D621F85B0 for ; Thu, 7 Jul 2011 05:11:03 -0700 (PDT) Received: by gwb20 with SMTP id 20so412228gwb.31 for ; Thu, 07 Jul 2011 05:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bFtuae7mdLvI8o9qifw2+DkfZnmTu4N8ZEZWAmsfURM=; b=hy2gD9AHfiqPzIuKMYOuXYNIhfkJzvNuCnsPS0gM6dItX7AROQjqK/uA8hxTTt9GLG bSuQsonDWqGTu2/8ootARyY1CMx1jiDs1T+A5JZXSUB8vPzf6MLyCryXjE0o6WtKODUb DvtIGAzMDGkdiwgY4zelKOtimUNBw9p6tHMJk= MIME-Version: 1.0 Received: by 10.101.162.11 with SMTP id p11mr546936ano.159.1310040662944; Thu, 07 Jul 2011 05:11:02 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Thu, 7 Jul 2011 05:11:01 -0700 (PDT) In-Reply-To: <4E1578FD.6090705@edelweb.fr> References: <000901cc3ba6$cc97c490$65c74db0$@eu> <4E140D1A.4010001@eNitiatives.com.au> <000e01cc3c71$459140e0$d0b3c2a0$@eu> <4E1578FD.6090705@edelweb.fr> Date: Thu, 7 Jul 2011 08:11:01 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Sylvester Content-Type: multipart/alternative; boundary=001636ed6c7f5b2b4704a7799c08 Cc: x500standard@freelists.org, SG17-Q11 , PKIX Subject: Re: [pkix] [Spam] Re: [x500standard] DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 12:11:06 -0000 --001636ed6c7f5b2b4704a7799c08 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Removing a DER requirement is perfectly fine by me. Removing the requirement that the encoder emit the bit stream that was signed is the issue. That would be totally ridiculous * X.500 is obsolete. No matter what the technical merits there is no exampl= e in our industry of a 20 year old technology that has had minimal success eclipsing a successor. * Even LDAP is of limited use unless an enterprise writes its own applications to pull information from it. * Breaking a cert up to store the attributes in a directory and then reassembling is guaranteed to fail. It was nonsense when first proposed If we made any change here at all it should be to require applications to accept PKIX certificates that are encoded using any valid BER encoding and drop mention of DER altogether. I believe that this has been the defacto requirement in any case. On Thu, Jul 7, 2011 at 5:14 AM, Peter Sylvester wrote: > ** > > > removing a DER requirement is unacceptable. Most implementations tolerat= e > certain deviations from DER (the second half of point a below for example= ) > are probably not prepared to handle a violation of the first part of poin= t > a. > > I think the following text in X/509 is sufficiently clear (assuming that = we > are all in THE directory): > > In 6.1 : (draft version 2008): > > Generating a distinguished encoding requires the abstract syntax of the > data to be encoded to be fully understood. The Directory may be required = to > sign data or check the signature of data that contains unknown protocol > extensions or unknown attribute syntaxes. The Directory shall follow thes= e > rules: > > =96 It shall preserve the encoding of received information whose abstract > syntax it does not fully know and which it expects to subsequently sign; > > =96 When signing data for sending, it shall send data whose syntax it ful= ly > knows with a distinguished encoding and any other data with its preserved > encoding, and shall sign the actual encoding it sends; > > =96 When checking signatures in received data, it shall check the signatu= re > against the actual data received rather than its conversion of the receiv= ed > data to a distinguished encoding. > > =3D=3D too bad that this doesn't work if one wants to work with XER only. > > The text above in 6.1 (with comments inline) > > > SIGNED { ToBeSigned } ::=3D SEQUENCE { > > * toBeSigned ToBeSigned,* > > * COMPONENTS OF SIGNATURE { ToBeSigned } }* > > In order to enable the validation of *SIGNED* and *SIGNATURE* types in a > distributed environment, a distinguished encoding is required. > > PS: =3D=3D a distinguished encoding is only required if one decodes and > reencodes which is not > what is recommended later. Nevertheless, this is not a reason to remove t= he > requirement for the encoding and open it to an arbitrary BER. > > A distinguished encoding of a *SIGNED* or *SIGNATURE* data value shall be > obtained by applying the Basic Encoding Rules defined in ITU-T Rec. X.690 > (2002) | ISO/IEC 8825-1:2002, with the following restrictions: > > a) the definite form of length encoding shall be used, encoded in the > minimum number of octets; > > b) for string types, the constructed form of encoding shall not be used; > > c) if the value of a type is its default value, it shall be absent; > > d) the components of a Set type shall be encoded in ascending order of > their tag value; > > e) the components of a Set-of type shall be encoded in ascending order of > their octet value; > > f) if the value of a Boolean type is true, the encoding shall have its > contents octet set to "FF"16; > > g) each unused bit in the final octet of the encoding of a Bit String > value, if there are any, shall be set to zero; > > h) the encoding of a Real type shall be such that bases 8, 10, and 16 sha= ll > not be used, and the binary scaling factor shall be zero. > > i) the encoding of a UTC time shall be as specified in ITU-T Rec. X.690 > (2002) | ISO/IEC 8825-1:2002; > > j) the encoding of a Generalized time shall be as specified in ITU-T Rec. > X.690 (2002) | ISO/IEC 8825 1:2002. > > > PS: =3D=3D the points above are just a description of DER? This part of = the > text shouldn't be there and simply reference DER (which is actually done = in > the comments like in > > *ENCRYPTED-HASH { ToBeSigned } ::=3D BIT STRING ( CONSTRAINED BY {* > > * -- shall be the result of applying a hashing procedure to the > DER-encoded (see 6.1) octets --* > > * -- of a value of -- ToBeSigned -- and then applying an encipherment > procedure to those octets -- }) > * > > A very bad style to define meaning in comments IMO (without doing it in t= he > text). > > On 07/07/2011 08:44 AM, Erik Andersen wrote: > > Hi Steven, Santosh, and others > > 6.1 of X.509 the HASH information object states that > > -- shall be the result of applying a hashing procedure to the DER-encoded > octets -- > -- of a value of --ToBeHashed > > The ENCRYPTED-HASH also states > > -- shall be the result of applying a hashing procedure to the DER-encoded > (see 6.1) octets -- > > The SIGNATURE information object class refers to ENCRYPTED-HASH. > > Already the 1988 edition required signatures based on DER encoding. > > Clearly, the X.509 requires and have always required signatures to be > performed over the DER encoded data. > > I have a problem with requiring the standard to take into account > non-conforming implementations. However, my proposal was partly a > provocation to see the reaction. > > I see three possible solutions: > > 1) The decoding and re-encoding in DER as it has been discussed > > X.509 does not require this and recommends against. (see above) > > 2) Remove the DER requirements from 6.1 of X.509 > > This will break any conformant and strict verifiers, > and many tolerant verifiers. > > 3) Mandate use of DER encoding for certificates and other similar data > types. This would also include signed operations. Implementations will th= en > always perform signature check over the "blob" (which could be BER encode= d). > > Isn't that exactly what X.509 says. > > We will still have non-conformant implementations, but they would work an= d > X.509 would be consistent. > > Consistency and compatibility in time is not exactly where X standards > are the best. (x400 84 vs 88, well that's old) > > recent X.509 keyusage changes breaks XER decoders > (Non Repudiation vs Contentcommitment). > Since two names are allowed for the same bit there is no longer > a distinguished XML encoding possible. > > For some peculiar reasons, Extensions shall always be DER encoded. This > requirement was introduced already in 1997, when the concept of extension= s > was introduced. > > > It is for exactly the same reason, to have a distinguished encoding. > With extensions it has become even impossible to decode > them and reencode completely. > > regards > Peter Sylvester > > > > Erik Andersen > Andersen's L-Service > Elsevej 48, > DK-3500 Vaerloese > Denmark > Mobile: +45 2097 1490 > e-amail: era@x500.eu > Skype: andersen-erikhttp://www.x500.eu/http://www.x500standard.com/http:/= /dk.linkedin.com/in/andersenerik > > > -----Oprindelig meddelelse----- > Fra: Steven Legg [mailto:steven.legg@enitiatives.com.au ] > Sendt: 6. juli 2011 09:22 > Til: x500standard@freelists.org > Cc: Erik Andersen > Emne: [Spam] Re: [x500standard] DER encoding of certificates > > > Erik, > > On 6/07/2011 4:34 PM, Erik Andersen wrote: > > Hi folks, > > In contrast to RFC 5280, X.509 does not require DER encoding. It only > > requires that the signature is > > generated across a DER encoded certificate, but the itself certificate m= ay > > be encoded using BER. > > Should we add a sentence somewhere in X.509 and possibly in RFC 5280 > > specifying that when verifying a > > signature a relying party shall decode and then encode the certificate i= n > > DER to verifying the signature? > > That would cause more problems than it solves because all too often in > the real world signatures are calculated over the BER encoding that is > transmitted rather than the DER encoding it is supposed to be calculated > over. > > Erik Andersen wrote: > > If the RDN is part of a primary distinguished name, the > primaryDistinguished > > component is TRUE and the valueWithContext shall not be included. If i= n > addition, > > the primaryDistnguished component is absent taking the default value, = the > encoding > > of a 5280 certificate and the encoding of an X.509 certificate are > identical. > > However, if the primaryDistingished component is present and takes the > value TRUE, > > a X.509 certificate will be different from a 5280 certificate and may = not > be > > accepted by all systems. Apparently, some tool will always add the > primaryDistingished > > component with the value TRUE. > > Is this an observed problem or a theoretical one ? A decoder using the 52= 80 > definition may well treat the AttributeTypeAndValue type as implicitly > extensible, in which case the primaryDistinguished component will be an > unknown extension that is gracefully ignored. The certificate couldn't be > re-encoded in DER, but that's not a wise thing to do anyway for the reaso= n > above. > > Regards, > Steven > > > Erik Andersen > > Andersen's L-Service > > Elsevej 48, > > DK-3500 Vaerloese > > Denmark > > Mobile: +45 2097 1490 > > e-amail: era@x500.eu > > Skype: andersen-erik > http://www.x500.eu/ > http://www.x500standard.com/ > http://dk.linkedin.com/in/andersenerik > > _______________________________________________ > pkix mailing listpkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > --=20 Website: http://hallambaker.com/ --001636ed6c7f5b2b4704a7799c08 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Removing a DER requirement is perfectly fine by me.

Remo= ving the requirement that the encoder emit the bit stream that was signed i= s the issue. That would be totally ridiculous

* X.= 500 is obsolete. No matter what the technical merits there is no example in= our industry of a 20 year old technology that has had minimal success ecli= psing a successor.

* Even LDAP is of limited use unless an enterprise writ= es its own applications to pull information from it.

* Breaking a cert up to store the attributes in a directory and then rea= ssembling is guaranteed to fail. It was nonsense when first proposed


If we made any change here at all it sho= uld be to require applications =A0to accept PKIX certificates that are enco= ded using any valid BER encoding and drop mention of DER altogether. I beli= eve that this has been the defacto requirement in any case.


On Thu, Jul 7= , 2011 at 5:14 AM, Peter Sylvester <peter.sylvester@edelweb.fr> wrote= :
=20 =20 =20


removing a DER requirement is unacceptable. Most implementations tolerate
certain deviations from DER (the second half of point a below for example)
are probably not prepared to handle a violation of the first part of point a.

I think the following text in X/509 is sufficiently clear (assuming that we are all in THE directory):

In 6.1 : (draft version 2008):

Generating a distinguished encoding requires the abstract syntax of the data to be encoded to be fully understood. The Directory may be required to sign data or check the signature of data that contains unknown protocol extensions or unknown attribute syntaxes. The Directory shall follow these rules:

=96 It shall preserve the encoding of received information whose abstract syntax it does not fully know and which it expects to subsequently sign;

=96 When signing data for sending, it shall send data whose syntax it fully knows with a distinguished encoding and any other data with its preserved encoding, and shall sign the actual encoding it sends;

=96 When checking signatures in received data, it shall check the signature against the actual data received rather than its conversion of the received data to a distinguished encoding.


=3D=3D too bad that this doesn't wor= k if one wants to work with XER only.=A0

The text above in 6.1 (with comments inline)


=20

SIGNED { ToBeSigned } ::=3D SEQUEN= CE {

toBeSigned ToBeS= igned,

COMPONENTS OF SIGNATURE { ToBeSigned } }


=20

=20

In order to enable the validatio= n of SIGNED and SIGNATURE types in a distributed environment, a distinguished encoding is required.

PS: =3D=3D a distinguished encoding is only required if one decodes and reencodes which is not
what is recommended later. Nevertheless, this is not a reason to remove the
requirement for the encoding and open it to an arbitrary BER.

A distinguished encoding of a = SIGNED or SIGNATURE data value shall be obtained by applying the Basic Encoding Rules defined in ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002, with the following restrictions:

=20

a) the definite form of length encoding shall be used, encoded in the minimum number of octets;

b) for string types, the constructed form of encoding shall not be used;

c) if the value of a type is its default value, it shall be absent;

d) the components of a Set type shall be encoded in ascending order of their tag value;

e) the components of a Set-of type shall be encoded in ascending order of their octet value;

f) if the value of a Boolean type is true, the encoding shall have its contents octet set to "FF"16;

g) each unused bit in the final octet of the encoding of a Bit String value, if there are any, shall be set to zero;

h) the encoding of a Real type shall be such that bases 8, 10, and 16 shall not be used, and the binary scaling factor shall be zero.

i) the encoding of a UTC time shall be as specified in ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002;

j) the encoding of a Generalized time shall be as specified in ITU-T Rec. X.690 (2002) | ISO/IEC=A08825=A01:2002.

<= br>

P= S: =3D=3D the points above are just a description of DER? This part of the text shouldn't be there an= d simply reference DER (which is actually done in the comments like in

=20

ENCRYPTED-H= ASH { ToBeSigned } ::=3D BIT STRING ( CONSTRAINED BY {

-- shall be the result of applying a hashing procedure to the DER-encoded (see 6.1) octets --

-- of a value of -- ToBeSigned -- and then applying an encipherment procedure to those octets -- })

A very bad style to define meaning in comments IMO (without doing it in the text).


On 07/07/2011 08:44 AM, Erik Andersen wrote: 
Hi Steven, Santosh, and others

6.1 of X.509 the HASH information object states that

-- shall be the result of applying a hashing procedure to the DER-encoded
octets --
			-- of a value of --ToBeHashed

The ENCRYPTED-HASH also states

-- shall be the result of applying a hashing procedure to the DER-encoded
(see 6.1) octets --

The SIGNATURE information object class refers to ENCRYPTED-HASH.

Already the 1988 edition required signatures based on DER encoding.

Clearly, the X.509 requires and have always required signatures to be
performed over the DER encoded data.

I have a problem with requiring the standard to take into account
non-conforming implementations. However, my proposal was partly a
provocation to see the reaction.

I see three possible solutions:

1)	The decoding and re-encoding in DER as it has been discussed
X.509 does not require this and recommends against. (see above)

2)	Remove the DER requirements from 6.1 of X.509
This will break any conformant and strict verifiers,
and many tolerant verifiers. 
3)	Mandate use of DER encoding for certificates and other simila=
r data
types. This would also include signed operations. Implementations will then
always perform signature check over the "blob" (which could be BE=
R encoded).
Isn't that exactly what X.509 says. 
We will still have non-conformant implementations, but they woul=
d work and
X.509 would be consistent.
Consistency and compatibility in time is not exactly where X standards
are the best. (x400 84 vs 88, well that's old)

recent X.509 keyusage changes breaks XER decoders
(Non Repudiation vs Contentcommitment).
Since two names are allowed for the same bit there is no longer
a distinguished XML encoding possible. 

For some peculiar reasons, Extensions shall always be DER encode=
d. This
requirement was introduced already in 1997, when the concept of extensions
was introduced. =20

It is for exactly the same reason, to have a distinguished encoding. With extensions it has become even impossible to decode
them and reencode completely.

regards
Peter Sylvester



Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: era@x500.eu
Skype: andersen-erik
http://www.x500.eu/
http://www.x500s=
tandard.com/
http:/=
/dk.linkedin.com/in/andersenerik


-----Oprindelig meddelelse-----
Fra: Steven Legg [mailto:steven.legg@enitiatives.com.au]=20
Sendt: 6. juli 2011 09:22
Til: x500st=
andard@freelists.org
Cc: Erik Andersen
Emne: [Spam] Re: [x500standard] DER encoding of certificates


Erik,

On 6/07/2011 4:34 PM, Erik Andersen wrote:

Hi folks,

In contrast to RFC 5280, X.509 does not require DER encoding. It only

requires that the signature is

generated across a DER encoded certificate, but the itself cer=
tificate may

be encoded using BER.

Should we add a sentence somewhere in X.509 and possibly in RF=
C 5280

specifying that when verifying a

signature a relying party shall decode and then encode the cer=
tificate in

DER to verifying the signature?

That would cause more problems than it solves because all too often in
the real world signatures are calculated over the BER encoding that is
transmitted rather than the DER encoding it is supposed to be calculated
over.

Erik Andersen wrote:
 > If the RDN is part of a primary distinguished name, the
primaryDistinguished
 > component is TRUE and the valueWithContext shall not be included. If =
in
addition,
 > the primaryDistnguished component is absent taking the default value,=
 the
encoding
 > of a 5280 certificate and the encoding of an X.509 certificate are
identical.
 > However, if the primaryDistingished component is present and takes th=
e
value TRUE,
 > a X.509 certificate will be different from a 5280 certificate and may=
 not
be
 > accepted by all systems. Apparently, some tool will always add the
primaryDistingished
 > component with the value TRUE.

Is this an observed problem or a theoretical one ? A decoder using the 5280
definition may well treat the AttributeTypeAndValue type as implicitly
extensible, in which case the primaryDistinguished component will be an
unknown extension that is gracefully ignored. The certificate couldn't =
be
re-encoded in DER, but that's not a wise thing to do anyway for the rea=
son
above.

Regards,
Steven


Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail: era@x500.eu

Skype: andersen-erik

http://www.x500.eu/

http://www.x500s=
tandard.com/

http:/=
/dk.linkedin.com/in/andersenerik


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


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




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

--001636ed6c7f5b2b4704a7799c08-- From hallam@gmail.com Thu Jul 7 05:16:20 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973D721F8489 for ; Thu, 7 Jul 2011 05:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stfLKPZd4iPx for ; Thu, 7 Jul 2011 05:16:19 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2E9321F854C for ; Thu, 7 Jul 2011 05:16:15 -0700 (PDT) Received: by yxp4 with SMTP id 4so431232yxp.31 for ; Thu, 07 Jul 2011 05:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SsfI3y4Obbbx98jAgIJLtmoTLljKUaioONrX0h7IUGM=; b=FEUyHW0FuEi/+j6EBuzZNhn1yt1PUHISmPpHo53QDjqL0rGl0O/De8+JW90K9n4XiG ZAt8/jBexNAdrhjBzaz4bVN1diF5C2Kt1EFvTvonA5DuXXOVfEAUcI2bGANJG1ZINVb6 m/uO1Cnu6h+D3tf5PdXyIfFpYn9N+T3IC6xW8= MIME-Version: 1.0 Received: by 10.101.179.7 with SMTP id g7mr579300anp.102.1310040975369; Thu, 07 Jul 2011 05:16:15 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Thu, 7 Jul 2011 05:16:15 -0700 (PDT) In-Reply-To: <000e01cc3c71$459140e0$d0b3c2a0$@eu> References: <000901cc3ba6$cc97c490$65c74db0$@eu> <4E140D1A.4010001@eNitiatives.com.au> <000e01cc3c71$459140e0$d0b3c2a0$@eu> Date: Thu, 7 Jul 2011 08:16:15 -0400 Message-ID: From: Phillip Hallam-Baker To: Erik Andersen Content-Type: multipart/alternative; boundary=001636c92664fa651a04a779ae1f Cc: x500standard@freelists.org, SG17-Q11 , PKIX Subject: Re: [pkix] [Spam] Re: [x500standard] DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 12:16:20 -0000 --001636c92664fa651a04a779ae1f Content-Type: text/plain; charset=ISO-8859-1 I chose 4 or 5: 4) Eliminate the DER encoding requirement completely 5) Do nothing at all PKIX is written to serve the needs of Internet applications. Canonical encoding of certs has no value for those applications. On Thu, Jul 7, 2011 at 2:44 AM, Erik Andersen wrote: > Hi Steven, Santosh, and others > > 6.1 of X.509 the HASH information object states that > > -- shall be the result of applying a hashing procedure to the DER-encoded > octets -- > -- of a value of --ToBeHashed > > The ENCRYPTED-HASH also states > > -- shall be the result of applying a hashing procedure to the DER-encoded > (see 6.1) octets -- > > The SIGNATURE information object class refers to ENCRYPTED-HASH. > > Already the 1988 edition required signatures based on DER encoding. > > Clearly, the X.509 requires and have always required signatures to be > performed over the DER encoded data. > > I have a problem with requiring the standard to take into account > non-conforming implementations. However, my proposal was partly a > provocation to see the reaction. > > I see three possible solutions: > > 1) The decoding and re-encoding in DER as it has been discussed > 2) Remove the DER requirements from 6.1 of X.509 > 3) Mandate use of DER encoding for certificates and other similar data > types. This would also include signed operations. Implementations will then > always perform signature check over the "blob" (which could be BER > encoded). > We will still have non-conformant implementations, but they would work and > X.509 would be consistent. > > For some peculiar reasons, Extensions shall always be DER encoded. This > requirement was introduced already in 1997, when the concept of extensions > was introduced. > > Erik Andersen > Andersen's L-Service > Elsevej 48, > DK-3500 Vaerloese > Denmark > Mobile: +45 2097 1490 > e-amail: era@x500.eu > Skype: andersen-erik > http://www.x500.eu/ > http://www.x500standard.com/ > http://dk.linkedin.com/in/andersenerik > > > -----Oprindelig meddelelse----- > Fra: Steven Legg [mailto:steven.legg@enitiatives.com.au] > Sendt: 6. juli 2011 09:22 > Til: x500standard@freelists.org > Cc: Erik Andersen > Emne: [Spam] Re: [x500standard] DER encoding of certificates > > > Erik, > > On 6/07/2011 4:34 PM, Erik Andersen wrote: > > Hi folks, > > > > In contrast to RFC 5280, X.509 does not require DER encoding. It only > requires that the signature is > > generated across a DER encoded certificate, but the itself certificate > may > be encoded using BER. > > > > Should we add a sentence somewhere in X.509 and possibly in RFC 5280 > specifying that when verifying a > > signature a relying party shall decode and then encode the certificate in > DER to verifying the signature? > > That would cause more problems than it solves because all too often in > the real world signatures are calculated over the BER encoding that is > transmitted rather than the DER encoding it is supposed to be calculated > over. > > Erik Andersen wrote: > > If the RDN is part of a primary distinguished name, the > primaryDistinguished > > component is TRUE and the valueWithContext shall not be included. If in > addition, > > the primaryDistnguished component is absent taking the default value, > the > encoding > > of a 5280 certificate and the encoding of an X.509 certificate are > identical. > > However, if the primaryDistingished component is present and takes the > value TRUE, > > a X.509 certificate will be different from a 5280 certificate and may > not > be > > accepted by all systems. Apparently, some tool will always add the > primaryDistingished > > component with the value TRUE. > > Is this an observed problem or a theoretical one ? A decoder using the 5280 > definition may well treat the AttributeTypeAndValue type as implicitly > extensible, in which case the primaryDistinguished component will be an > unknown extension that is gracefully ignored. The certificate couldn't be > re-encoded in DER, but that's not a wise thing to do anyway for the reason > above. > > Regards, > Steven > > > > > Erik Andersen > > > > Andersen's L-Service > > > > Elsevej 48, > > > > DK-3500 Vaerloese > > > > Denmark > > > > Mobile: +45 2097 1490 > > > > e-amail: era@x500.eu > > > > Skype: andersen-erik > > > > http://www.x500.eu/ > > > > http://www.x500standard.com/ > > > > http://dk.linkedin.com/in/andersenerik > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Website: http://hallambaker.com/ --001636c92664fa651a04a779ae1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I chose 4 or 5:

4) Eliminate the DER encoding requiremen= t completely
5) Do nothing at all

PKIX i= s written to serve the needs of Internet applications. Canonical encoding o= f certs has no value for those applications.



On Thu, Jul 7, 2011 = at 2:44 AM, Erik Andersen <era@x500.eu> wrote:
Hi Steven, Santosh, and others

6.1 of X.509 the HASH information object states that

-- shall be the result of applying a hashing procedure to the DER-encoded octets --
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- of a value of --ToBeHash= ed

The ENCRYPTED-HASH also states

-- shall be the result of applying a hashing procedure to the DER-encoded (see 6.1) octets --

The SIGNATURE information object class refers to ENCRYPTED-HASH.

Already the 1988 edition required signatures based on DER encoding.

Clearly, the X.509 requires and have always required signatures to be
performed over the DER encoded data.

I have a problem with requiring the standard to take into account
non-conforming implementations. However, my proposal was partly a
provocation to see the reaction.

I see three possible solutions:

1) =A0 =A0 =A0The decoding and re-encoding in DER as it has been discussed<= br> 2) =A0 =A0 =A0Remove the DER requirements from 6.1 of X.509
3) =A0 =A0 =A0Mandate use of DER encoding for certificates and other simila= r data
types. This would also include signed operations. Implementations will then=
always perform signature check over the "blob" (which could be BE= R encoded).
We will still have non-conformant implementations, but they would work and<= br> X.509 would be consistent.

For some peculiar reasons, Extensions shall always be DER encoded. This
requirement was introduced already in 1997, when the concept of extensions<= br> was introduced.

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 = 1490
e-amail: era@x500.eu
Skype: andersen-erik
http://www.x500.eu/ http://www.x500s= tandard.com/
http:/= /dk.linkedin.com/in/andersenerik


-----Oprindelig meddelelse-----
Fra: Steven Legg [mailto:= steven.legg@enitiatives.com.au]
Sendt: 6. juli 2011 09:22
Til: x500standard@freelists.o= rg
Cc: Erik Andersen
Emne: [Spam] Re: [x500standard] DER encoding of certificates


Erik,

On 6/07/2011 4:34 PM, Erik Andersen wrote:
> Hi folks,
>
> In contrast to RFC 5280, X.509 does not require DER encoding. It only<= br> requires that the signature is
> generated across a DER encoded certificate, but the itself certificate= may
be encoded using BER.
>
> Should we add a sentence somewhere in X.509 and possibly in RFC 5280 specifying that when verifying a
> signature a relying party shall decode and then encode the certificate= in
DER to verifying the signature?

That would cause more problems than it solves because all too often i= n
the real world signatures are calculated over the BER encoding that is
transmitted rather than the DER encoding it is supposed to be calculated over.

Erik Andersen wrote:
=A0> If the RDN is part of a primary distinguished name, the
primaryDistinguished
=A0> component is TRUE and the valueWithContext shall not be included. I= f in
addition,
=A0> the primaryDistnguished component is absent taking the default valu= e, the
encoding
=A0> of a 5280 certificate and the encoding of an X.509 certificate are<= br> identical.
=A0> However, if the primaryDistingished component is present and takes = the
value TRUE,
=A0> a X.509 certificate will be different from a 5280 certificate and m= ay not
be
=A0> accepted by all systems. Apparently, some tool will always add the<= br> primaryDistingished
=A0> component with the value TRUE.

Is this an observed problem or a theoretical one ? A decoder using the 5280=
definition may well treat the AttributeTypeAndValue type as implicitly
extensible, in which case the primaryDistinguished component will be an
unknown extension that is gracefully ignored. The certificate couldn't = be
re-encoded in DER, but that's not a wise thing to do anyway for the rea= son
above.

Regards,
Steven

>
> Erik Andersen
>
> Andersen's L-Service
>
> Elsevej 48,
>
> DK-3500 Vaerloese
>
> Denmark
>
> Mobile: +45 = 2097 1490
>
> e-amail: era@x500.eu
>
> Skype: andersen-erik
>
> http://www.x500.eu/<= /a>
>
> http://www.= x500standard.com/
>
> h= ttp://dk.linkedin.com/in/andersenerik
>

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



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

--001636c92664fa651a04a779ae1f-- From peter.sylvester@edelweb.fr Thu Jul 7 05:56:17 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BF521F85F6 for ; Thu, 7 Jul 2011 05:56:17 -0700 (PDT) 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 I8xqYZu6a86f for ; Thu, 7 Jul 2011 05:56:12 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id DFEA421F85F5 for ; Thu, 7 Jul 2011 05:56:11 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 7C48D7FB6; Thu, 7 Jul 2011 14:56:10 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 50E1E16F64; Thu, 7 Jul 2011 14:56:10 +0200 (CEST) Received: from [192.168.18.186] (unknown [192.168.18.186]) by smtps.on-x.com (Postfix) with ESMTP id 46BE6782B; Thu, 7 Jul 2011 14:56:10 +0200 (CEST) Message-ID: <4E15AD36.30307@edelweb.fr> Date: Thu, 07 Jul 2011 14:57:26 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Erik Andersen References: <000901cc3ba6$cc97c490$65c74db0$@eu> <4E140D1A.4010001@eNitiatives.com.au> <000e01cc3c71$459140e0$d0b3c2a0$@eu> In-Reply-To: <000e01cc3c71$459140e0$d0b3c2a0$@eu> Content-Type: multipart/alternative; boundary="------------020907040202010408080401" Cc: x500standard@freelists.org, SG17-Q11 , PKIX Subject: Re: [pkix] [Spam] Re: [x500standard] DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 12:56:17 -0000 This is a multi-part message in MIME format. --------------020907040202010408080401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all. removing a DER requirement is unacceptable. Most implementations tolerate certain deviations from DER (the second half of point a below for example) are probably not prepared to handle a violation of the first part of point a. I think the following text in X/509 is sufficiently clear (assuming that we are all in THE directory): In 6.1 : (draft version 2008): Generating a distinguished encoding requires the abstract syntax of the data to be encoded to be fully understood. The Directory may be required to sign data or check the signature of data that contains unknown protocol extensions or unknown attribute syntaxes. The Directory shall follow these rules: -- It shall preserve the encoding of received information whose abstract syntax it does not fully know and which it expects to subsequently sign; -- When signing data for sending, it shall send data whose syntax it fully knows with a distinguished encoding and any other data with its preserved encoding, and shall sign the actual encoding it sends; -- When checking signatures in received data, it shall check the signature against the actual data received rather than its conversion of the received data to a distinguished encoding. == too bad that this doesn't work if one wants to work with XER only. The text above in 6.1 (with comments inline) SIGNED { ToBeSigned } ::= SEQUENCE { *toBeSigned ToBeSigned,* *COMPONENTS OF SIGNATURE { ToBeSigned } }* In order to enable the validation of *SIGNED* and *SIGNATURE* types in a distributed environment, a distinguished encoding is required. PS: == a distinguished encoding is only required if one decodes and reencodes which is not what is recommended later. Nevertheless, this is not a reason to remove the requirement for the encoding and open it to an arbitrary BER. A distinguished encoding of a *SIGNED* or *SIGNATURE* data value shall be obtained by applying the Basic Encoding Rules defined in ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002, with the following restrictions: a) the definite form of length encoding shall be used, encoded in the minimum number of octets; b) for string types, the constructed form of encoding shall not be used; c) if the value of a type is its default value, it shall be absent; d) the components of a Set type shall be encoded in ascending order of their tag value; e) the components of a Set-of type shall be encoded in ascending order of their octet value; f) if the value of a Boolean type is true, the encoding shall have its contents octet set to "FF"16; g) each unused bit in the final octet of the encoding of a Bit String value, if there are any, shall be set to zero; h) the encoding of a Real type shall be such that bases 8, 10, and 16 shall not be used, and the binary scaling factor shall be zero. i) the encoding of a UTC time shall be as specified in ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002; j) the encoding of a Generalized time shall be as specified in ITU-T Rec. X.690 (2002) | ISO/IEC 8825 1:2002. PS: == the points above are just a description of DER? This part of the text shouldn't be there and simply reference DER (which is actually done in the comments like in *ENCRYPTED-HASH { ToBeSigned } ::= BIT STRING ( CONSTRAINED BY {* /-- shall be the result of applying a hashing procedure to the DER-encoded (see 6.1) octets --/ */-- of a value of -- ToBeSigned -- and then applying an encipherment procedure to those octets -- /}) * A very bad style to define meaning in comments IMO (without doing it in the text). On 07/07/2011 08:44 AM, Erik Andersen wrote: > Hi Steven, Santosh, and others > > 6.1 of X.509 the HASH information object states that > > -- shall be the result of applying a hashing procedure to the DER-encoded > octets -- > -- of a value of --ToBeHashed > > The ENCRYPTED-HASH also states > > -- shall be the result of applying a hashing procedure to the DER-encoded > (see 6.1) octets -- > > The SIGNATURE information object class refers to ENCRYPTED-HASH. > > Already the 1988 edition required signatures based on DER encoding. > > Clearly, the X.509 requires and have always required signatures to be > performed over the DER encoded data. > > I have a problem with requiring the standard to take into account > non-conforming implementations. However, my proposal was partly a > provocation to see the reaction. > > I see three possible solutions: > > 1) The decoding and re-encoding in DER as it has been discussed X.509 does not require this and recommends against. (see above) > 2) Remove the DER requirements from 6.1 of X.509 This will break any conformant and strict verifiers, and many tolerant verifiers. > 3) Mandate use of DER encoding for certificates and other similar data > types. This would also include signed operations. Implementations will then > always perform signature check over the "blob" (which could be BER encoded). Isn't that exactly what X.509 says. > We will still have non-conformant implementations, but they would work and > X.509 would be consistent. Consistency and compatibility in time is not exactly where X standards are the best. (x400 84 vs 88, well that's old) recent X.509 keyusage changes breaks XER decoders (Non Repudiation vs Contentcommitment). Since two names are allowed for the same bit there is no longer a distinguished XML encoding possible. > For some peculiar reasons, Extensions shall always be DER encoded. This > requirement was introduced already in 1997, when the concept of extensions > was introduced. It is for exactly the same reason, to have a distinguished encoding. With extensions it has become even impossible to decode them and reencode completely. regards Peter Sylvester > Erik Andersen > Andersen's L-Service > Elsevej 48, > DK-3500 Vaerloese > Denmark > Mobile: +45 2097 1490 > e-amail:era@x500.eu > Skype: andersen-erik > http://www.x500.eu/ > http://www.x500standard.com/ > http://dk.linkedin.com/in/andersenerik > > > -----Oprindelig meddelelse----- > Fra: Steven Legg [mailto:steven.legg@enitiatives.com.au] > Sendt: 6. juli 2011 09:22 > Til:x500standard@freelists.org > Cc: Erik Andersen > Emne: [Spam] Re: [x500standard] DER encoding of certificates > > > Erik, > > On 6/07/2011 4:34 PM, Erik Andersen wrote: >> Hi folks, >> >> In contrast to RFC 5280, X.509 does not require DER encoding. It only > requires that the signature is >> generated across a DER encoded certificate, but the itself certificate may > be encoded using BER. >> Should we add a sentence somewhere in X.509 and possibly in RFC 5280 > specifying that when verifying a >> signature a relying party shall decode and then encode the certificate in > DER to verifying the signature? > > That would cause more problems than it solves because all too often in > the real world signatures are calculated over the BER encoding that is > transmitted rather than the DER encoding it is supposed to be calculated > over. > > Erik Andersen wrote: > > If the RDN is part of a primary distinguished name, the > primaryDistinguished > > component is TRUE and the valueWithContext shall not be included. If in > addition, > > the primaryDistnguished component is absent taking the default value, the > encoding > > of a 5280 certificate and the encoding of an X.509 certificate are > identical. > > However, if the primaryDistingished component is present and takes the > value TRUE, > > a X.509 certificate will be different from a 5280 certificate and may not > be > > accepted by all systems. Apparently, some tool will always add the > primaryDistingished > > component with the value TRUE. > > Is this an observed problem or a theoretical one ? A decoder using the 5280 > definition may well treat the AttributeTypeAndValue type as implicitly > extensible, in which case the primaryDistinguished component will be an > unknown extension that is gracefully ignored. The certificate couldn't be > re-encoded in DER, but that's not a wise thing to do anyway for the reason > above. > > Regards, > Steven > >> Erik Andersen >> >> Andersen's L-Service >> >> Elsevej 48, >> >> DK-3500 Vaerloese >> >> Denmark >> >> Mobile: +45 2097 1490 >> >> e-amail:era@x500.eu >> >> Skype: andersen-erik >> >> http://www.x500.eu/ >> >> http://www.x500standard.com/ >> >> http://dk.linkedin.com/in/andersenerik >> > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------020907040202010408080401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi all.

removing a DER requirement is unacceptable. Most implementations tolerate
certain deviations from DER (the second half of point a below for example)
are probably not prepared to handle a violation of the first part of point a.

I think the following text in X/509 is sufficiently clear (assuming that we are all in THE directory):

In 6.1 : (draft version 2008):

Generating a distinguished encoding requires the abstract syntax of the data to be encoded to be fully understood. The Directory may be required to sign data or check the signature of data that contains unknown protocol extensions or unknown attribute syntaxes. The Directory shall follow these rules:

– It shall preserve the encoding of received information whose abstract syntax it does not fully know and which it expects to subsequently sign;

– When signing data for sending, it shall send data whose syntax it fully knows with a distinguished encoding and any other data with its preserved encoding, and shall sign the actual encoding it sends;

– When checking signatures in received data, it shall check the signature against the actual data received rather than its conversion of the received data to a distinguished encoding.


== too bad that this doesn't work if one wants to work with XER only. 

The text above in 6.1 (with comments inline)


SIGNED { ToBeSigned } ::= SEQUENCE {

toBeSigned ToBeSigned,

COMPONENTS OF SIGNATURE { ToBeSigned } }


In order to enable the validation of SIGNED and SIGNATURE types in a distributed environment, a distinguished encoding is required.

PS: == a distinguished encoding is only required if one decodes and reencodes which is not
what is recommended later. Nevertheless, this is not a reason to remove the
requirement for the encoding and open it to an arbitrary BER.

A distinguished encoding of a SIGNED or SIGNATURE data value shall be obtained by applying the Basic Encoding Rules defined in ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002, with the following restrictions:

a) the definite form of length encoding shall be used, encoded in the minimum number of octets;

b) for string types, the constructed form of encoding shall not be used;

c) if the value of a type is its default value, it shall be absent;

d) the components of a Set type shall be encoded in ascending order of their tag value;

e) the components of a Set-of type shall be encoded in ascending order of their octet value;

f) if the value of a Boolean type is true, the encoding shall have its contents octet set to "FF"16;

g) each unused bit in the final octet of the encoding of a Bit String value, if there are any, shall be set to zero;

h) the encoding of a Real type shall be such that bases 8, 10, and 16 shall not be used, and the binary scaling factor shall be zero.

i) the encoding of a UTC time shall be as specified in ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002;

j) the encoding of a Generalized time shall be as specified in ITU-T Rec. X.690 (2002) | ISO/IEC 8825 1:2002.


PS: == the points above are just a description of DER? This part of the text shouldn't be there and simply reference DER (which is actually done in the comments like in

ENCRYPTED-HASH { ToBeSigned } ::= BIT STRING ( CONSTRAINED BY {

-- shall be the result of applying a hashing procedure to the DER-encoded (see 6.1) octets --

-- of a value of -- ToBeSigned -- and then applying an encipherment procedure to those octets -- })

A very bad style to define meaning in comments IMO (without doing it in the text).


On 07/07/2011 08:44 AM, Erik Andersen wrote: 
Hi Steven, Santosh, and others

6.1 of X.509 the HASH information object states that

-- shall be the result of applying a hashing procedure to the DER-encoded
octets --
			-- of a value of --ToBeHashed

The ENCRYPTED-HASH also states

-- shall be the result of applying a hashing procedure to the DER-encoded
(see 6.1) octets --

The SIGNATURE information object class refers to ENCRYPTED-HASH.

Already the 1988 edition required signatures based on DER encoding.

Clearly, the X.509 requires and have always required signatures to be
performed over the DER encoded data.

I have a problem with requiring the standard to take into account
non-conforming implementations. However, my proposal was partly a
provocation to see the reaction.

I see three possible solutions:

1)	The decoding and re-encoding in DER as it has been discussed
X.509 does not require this and recommends against. (see above)
2)	Remove the DER requirements from 6.1 of X.509
This will break any conformant and strict verifiers,
and many tolerant verifiers. 
3)	Mandate use of DER encoding for certificates and other similar data
types. This would also include signed operations. Implementations will then
always perform signature check over the "blob" (which could be BER encoded).
Isn't that exactly what X.509 says. 
We will still have non-conformant implementations, but they would work and
X.509 would be consistent.
Consistency and compatibility in time is not exactly where X standards
are the best. (x400 84 vs 88, well that's old)

recent X.509 keyusage changes breaks XER decoders
(Non Repudiation vs Contentcommitment).
Since two names are allowed for the same bit there is no longer
a distinguished XML encoding possible. 

For some peculiar reasons, Extensions shall always be DER encoded. This
requirement was introduced already in 1997, when the concept of extensions
was introduced.

It is for exactly the same reason, to have a distinguished encoding.
With extensions it has become even impossible to decode
them and reencode completely.

regards
Peter Sylvester


Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: era@x500.eu
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/
http://dk.linkedin.com/in/andersenerik


-----Oprindelig meddelelse-----
Fra: Steven Legg [mailto:steven.legg@enitiatives.com.au] 
Sendt: 6. juli 2011 09:22
Til: x500standard@freelists.org
Cc: Erik Andersen
Emne: [Spam] Re: [x500standard] DER encoding of certificates


Erik,

On 6/07/2011 4:34 PM, Erik Andersen wrote:

Hi folks,

In contrast to RFC 5280, X.509 does not require DER encoding. It only

requires that the signature is

generated across a DER encoded certificate, but the itself certificate may

be encoded using BER.

Should we add a sentence somewhere in X.509 and possibly in RFC 5280

specifying that when verifying a

signature a relying party shall decode and then encode the certificate in

DER to verifying the signature?

That would cause more problems than it solves because all too often in
the real world signatures are calculated over the BER encoding that is
transmitted rather than the DER encoding it is supposed to be calculated
over.

Erik Andersen wrote:
 > If the RDN is part of a primary distinguished name, the
primaryDistinguished
 > component is TRUE and the valueWithContext shall not be included. If in
addition,
 > the primaryDistnguished component is absent taking the default value, the
encoding
 > of a 5280 certificate and the encoding of an X.509 certificate are
identical.
 > However, if the primaryDistingished component is present and takes the
value TRUE,
 > a X.509 certificate will be different from a 5280 certificate and may not
be
 > accepted by all systems. Apparently, some tool will always add the
primaryDistingished
 > component with the value TRUE.

Is this an observed problem or a theoretical one ? A decoder using the 5280
definition may well treat the AttributeTypeAndValue type as implicitly
extensible, in which case the primaryDistinguished component will be an
unknown extension that is gracefully ignored. The certificate couldn't be
re-encoded in DER, but that's not a wise thing to do anyway for the reason
above.

Regards,
Steven


Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail: era@x500.eu

Skype: andersen-erik

http://www.x500.eu/

http://www.x500standard.com/

http://dk.linkedin.com/in/andersenerik


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

--------------020907040202010408080401-- From SChokhani@cygnacom.com Thu Jul 7 06:10:57 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E78521F869C for ; Thu, 7 Jul 2011 06:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 nijmNucn4imx for ; Thu, 7 Jul 2011 06:10:48 -0700 (PDT) Received: from sottexchE2.entrust.com (sottexche2.entrust.com [216.191.252.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1A91B21F85B2 for ; Thu, 7 Jul 2011 06:10:47 -0700 (PDT) Received: from scygexch7.cygnacom.com (10.4.60.22) by sottexchE2.entrust.com (216.191.252.22) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Jul 2011 09:10:25 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 7 Jul 2011 09:10:46 -0400 From: Santosh Chokhani To: Phillip Hallam-Baker , Peter Sylvester Date: Thu, 7 Jul 2011 09:10:42 -0400 Thread-Topic: [pkix] [Spam] Re: [x500standard] DER encoding of certificates Thread-Index: Acw8nv92vLfNhFvzRFCVc4hewbPOgQACB1SA Message-ID: References: <000901cc3ba6$cc97c490$65c74db0$@eu> <4E140D1A.4010001@eNitiatives.com.au> <000e01cc3c71$459140e0$d0b3c2a0$@eu> <4E1578FD.6090705@edelweb.fr> In-Reply-To: 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_B83745DA469B7847811819C5005244AF0F44D7FEscygexch7cygnac_" MIME-Version: 1.0 Cc: "x500standard@freelists.org" , SG17-Q11 , PKIX Subject: Re: [pkix] [Spam] Re: [x500standard] DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:10:57 -0000 --_000_B83745DA469B7847811819C5005244AF0F44D7FEscygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phillip, So, you are saying, do not transmit the payload; do not reassemble the pay = and do not require to do DER. Whow. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Phi= llip Hallam-Baker Sent: Thursday, July 07, 2011 8:11 AM To: Peter Sylvester Cc: x500standard@freelists.org; SG17-Q11; PKIX Subject: Re: [pkix] [Spam] Re: [x500standard] DER encoding of certificates Removing a DER requirement is perfectly fine by me. Removing the requirement that the encoder emit the bit stream that was sign= ed is the issue. That would be totally ridiculous * X.500 is obsolete. No matter what the technical merits there is no exampl= e in our industry of a 20 year old technology that has had minimal success = eclipsing a successor. * Even LDAP is of limited use unless an enterprise writes its own applicati= ons to pull information from it. * Breaking a cert up to store the attributes in a directory and then reasse= mbling is guaranteed to fail. It was nonsense when first proposed If we made any change here at all it should be to require applications to = accept PKIX certificates that are encoded using any valid BER encoding and = drop mention of DER altogether. I believe that this has been the defacto re= quirement in any case. On Thu, Jul 7, 2011 at 5:14 AM, Peter Sylvester > wrote: removing a DER requirement is unacceptable. Most implementations tolerate certain deviations from DER (the second half of point a below for example) are probably not prepared to handle a violation of the first part of point = a. I think the following text in X/509 is sufficiently clear (assuming that we= are all in THE directory): In 6.1 : (draft version 2008): Generating a distinguished encoding requires the abstract syntax of the dat= a to be encoded to be fully understood. The Directory may be required to si= gn data or check the signature of data that contains unknown protocol exten= sions or unknown attribute syntaxes. The Directory shall follow these rules= : - It shall preserve the encoding of received information whose abstract syn= tax it does not fully know and which it expects to subsequently sign; - When signing data for sending, it shall send data whose syntax it fully k= nows with a distinguished encoding and any other data with its preserved en= coding, and shall sign the actual encoding it sends; - When checking signatures in received data, it shall check the signature a= gainst the actual data received rather than its conversion of the received = data to a distinguished encoding. =3D=3D too bad that this doesn't work if one wants to work with XER only. The text above in 6.1 (with comments inline) SIGNED { ToBeSigned } ::=3D SEQUENCE { toBeSigned ToBeSigned, COMPONENTS OF SIGNATURE { ToBeSigned } } In order to enable the validation of SIGNED and SIGNATURE types in a distri= buted environment, a distinguished encoding is required. PS: =3D=3D a distinguished encoding is only required if one decodes and ree= ncodes which is not what is recommended later. Nevertheless, this is not a reason to remove the requirement for the encoding and open it to an arbitrary BER. A distinguished encoding of a SIGNED or SIGNATURE data value shall be obtai= ned by applying the Basic Encoding Rules defined in ITU-T Rec. X.690 (2002)= | ISO/IEC 8825-1:2002, with the following restrictions: a) the definite form of length encoding shall be used, encoded in the minim= um number of octets; b) for string types, the constructed form of encoding shall not be used; c) if the value of a type is its default value, it shall be absent; d) the components of a Set type shall be encoded in ascending order of thei= r tag value; e) the components of a Set-of type shall be encoded in ascending order of t= heir octet value; f) if the value of a Boolean type is true, the encoding shall have its cont= ents octet set to "FF"16; g) each unused bit in the final octet of the encoding of a Bit String value= , if there are any, shall be set to zero; h) the encoding of a Real type shall be such that bases 8, 10, and 16 shall= not be used, and the binary scaling factor shall be zero. i) the encoding of a UTC time shall be as specified in ITU-T Rec. X.690 (20= 02) | ISO/IEC 8825-1:2002; j) the encoding of a Generalized time shall be as specified in ITU-T Rec. X= .690 (2002) | ISO/IEC 8825 1:2002. PS: =3D=3D the points above are just a description of DER? This part of the= text shouldn't be there and simply reference DER (which is actually done i= n the comments like in ENCRYPTED-HASH { ToBeSigned } ::=3D BIT STRING ( CONSTRAINED BY { -- shall be the result of applying a hashing procedure to the DER-encoded (= see 6.1) octets -- -- of a value of -- ToBeSigned -- and then applying an encipherment procedu= re to those octets -- }) A very bad style to define meaning in comments IMO (without doing it in the= text). On 07/07/2011 08:44 AM, Erik Andersen wrote: Hi Steven, Santosh, and others 6.1 of X.509 the HASH information object states that -- shall be the result of applying a hashing procedure to the DER-encoded octets -- -- of a value of --ToBeHashed The ENCRYPTED-HASH also states -- shall be the result of applying a hashing procedure to the DER-encoded (see 6.1) octets -- The SIGNATURE information object class refers to ENCRYPTED-HASH. Already the 1988 edition required signatures based on DER encoding. Clearly, the X.509 requires and have always required signatures to be performed over the DER encoded data. I have a problem with requiring the standard to take into account non-conforming implementations. However, my proposal was partly a provocation to see the reaction. I see three possible solutions: 1) The decoding and re-encoding in DER as it has been discussed X.509 does not require this and recommends against. (see above) 2) Remove the DER requirements from 6.1 of X.509 This will break any conformant and strict verifiers, and many tolerant verifiers. 3) Mandate use of DER encoding for certificates and other similar dat= a types. This would also include signed operations. Implementations will then always perform signature check over the "blob" (which could be BER encoded)= . Isn't that exactly what X.509 says. We will still have non-conformant implementations, but they would work and X.509 would be consistent. Consistency and compatibility in time is not exactly where X standards are the best. (x400 84 vs 88, well that's old) recent X.509 keyusage changes breaks XER decoders (Non Repudiation vs Contentcommitment). Since two names are allowed for the same bit there is no longer a distinguished XML encoding possible. For some peculiar reasons, Extensions shall always be DER encoded. This requirement was introduced already in 1997, when the concept of extensions was introduced. It is for exactly the same reason, to have a distinguished encoding. With extensions it has become even impossible to decode them and reencode completely. regards Peter Sylvester Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: Steven Legg [mailto:steven.legg@enitiatives.com.au] Sendt: 6. juli 2011 09:22 Til: x500standard@freelists.org Cc: Erik Andersen Emne: [Spam] Re: [x500standard] DER encoding of certificates Erik, On 6/07/2011 4:34 PM, Erik Andersen wrote: Hi folks, In contrast to RFC 5280, X.509 does not require DER encoding. It only requires that the signature is generated across a DER encoded certificate, but the itself certificate may be encoded using BER. Should we add a sentence somewhere in X.509 and possibly in RFC 5280 specifying that when verifying a signature a relying party shall decode and then encode the certificate in DER to verifying the signature? That would cause more problems than it solves because all too often in the real world signatures are calculated over the BER encoding that is transmitted rather than the DER encoding it is supposed to be calculated over. Erik Andersen wrote: > If the RDN is part of a primary distinguished name, the primaryDistinguished > component is TRUE and the valueWithContext shall not be included. If in addition, > the primaryDistnguished component is absent taking the default value, th= e encoding > of a 5280 certificate and the encoding of an X.509 certificate are identical. > However, if the primaryDistingished component is present and takes the value TRUE, > a X.509 certificate will be different from a 5280 certificate and may no= t be > accepted by all systems. Apparently, some tool will always add the primaryDistingished > component with the value TRUE. Is this an observed problem or a theoretical one ? A decoder using the 5280 definition may well treat the AttributeTypeAndValue type as implicitly extensible, in which case the primaryDistinguished component will be an unknown extension that is gracefully ignored. The certificate couldn't be re-encoded in DER, but that's not a wise thing to do anyway for the reason above. Regards, Steven Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik _______________________________________________ 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 -- Website: http://hallambaker.com/ --_000_B83745DA469B7847811819C5005244AF0F44D7FEscygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phillip,

 

So, you are saying, do not transmit the payload; do no= t reassemble the pay and do not require to do DER.

 

= Whow.

 

From: pkix-bounces@ietf.org [mailto:pkix-b= ounces@ietf.org] On Behalf Of Phillip Hallam-Baker
Sent: T= hursday, July 07, 2011 8:11 AM
To: Peter Sylvester
Cc: = x500standard@freelists.org; SG17-Q11; PKIX
Subject: Re: [pkix] [S= pam] Re: [x500standard] DER encoding of certificates

<= /div>

 

Removin= g a DER requirement is perfectly fine by me.

 

Removing the= requirement that the encoder emit the bit stream that was signed is the is= sue. That would be totally ridiculous

 

* X.500 is ob= solete. No matter what the technical merits there is no example in our indu= stry of a 20 year old technology that has had minimal success eclipsing a s= uccessor.

 

* Even LDAP is of limited use unless an e= nterprise writes its own applications to pull information from it.

 

* Breaking a cert up to store the attributes in a directory= and then reassembling is guaranteed to fail. It was nonsense when first pr= oposed

 

<= /div>

 

If we made any change here at all it should be to require applicat= ions  to accept PKIX certificates that are encoded using any valid BER= encoding and drop mention of DER altogether. I believe that this has been = the defacto requirement in any case.

 

 

On Thu, Jul 7, 2011 at 5:14 AM,= Peter Sylvester <peter.sy= lvester@edelweb.fr> wrote:

 

removing a DER requirement is unacceptable. M= ost implementations tolerate
certain deviations from DER (the second hal= f of point a below for example)
are probably not prepared to handle a vi= olation of the first part of point a.

I think the following text in X/509 is suffic= iently clear (assuming that we are all in THE directory):

In 6.1 : (draft version 2= 008):

G= enerating a distinguished encoding requires the abstract syntax of the data= to be encoded to be fully understood. The Directory may be required to sig= n data or check the signature of data that contains unknown protocol extens= ions or unknown attribute syntaxes. The Directory shall follow these rules:=

– It shall pre= serve the encoding of received information whose abstract syntax it does no= t fully know and which it expects to subsequently sign;

– When signing data for sending, i= t shall send data whose syntax it fully knows with a distinguished encoding= and any other data with its preserved encoding, and shall sign the actual = encoding it sends;

&#= 8211; When checking signatures in received data, it shall check the signatu= re against the actual data received rather than its conversion of the recei= ved data to a distinguished encoding.

 

=3D=3D too bad that th= is doesn't work if one wants to work with XER only. 

The text above in 6.1 (w= ith comments inline)

 

SIGNED { ToBeSigned } ::=3D SEQUENCE {

toBeSigned ToBeSigned,=

COMPONENTS= OF SIGNATURE { ToBeSigned } }

 

In order to enable the validation of SIGNED and SIGNATURE = types in a distributed environment, a distinguished encoding is required.

PS: =3D= =3D a distinguished encoding is only required if one decodes and reencodes = which is not
what is recommended later. Nevertheless, this is not a reas= on to remove the
requirement for the encoding and open it to an arbitrar= y BER.

A= distinguished encoding of a SIGNED or SIGNATURE data value= shall be obtained by applying the Basic Encoding Rules defined in ITU-T Re= c. X.690 (2002) | ISO/IEC 8825-1:2002, with the following restrictions:

a) the definite form of = length encoding shall be used, encoded in the minimum number of octets;

b) for string types, the= constructed form of encoding shall not be used;

c) if the value of a type is its default value,= it shall be absent;

= d) the components of a Set type shall be encoded in ascending order of thei= r tag value;

e) the c= omponents of a Set-of type shall be encoded in ascending order of their oct= et value;

f) if the v= alue of a Boolean type is true, the encoding shall have its contents octet = set to "FF"16;

g) each unused bit in the final octet of the encoding of a Bit String v= alue, if there are any, shall be set to zero;

h) the encoding of a Real type shall be such that = bases 8, 10, and 16 shall not be used, and the binary scaling factor shall = be zero.

i) the encod= ing of a UTC time shall be as specified in ITU-T Rec. X.690 (2002) | ISO/IE= C 8825-1:2002;

j) the= encoding of a Generalized time shall be as specified in ITU-T Rec. X.690 (= 2002) | ISO/IEC 8825 1:2002.

 

PS: =3D=3D the points above are just a description of DER? This part of= the text shouldn't be there and simply reference DER (which is actually do= ne in the comments like in

ENCRYPTED-HASH { ToBeSigned } ::=3D BIT STRING ( CONSTRAINE= D BY {

-- shall be the result of applying a hashing procedure to the D= ER-encoded (see 6.1) octets --

-- of a value of -- ToBeSig= ned -- and then applying an encipherment procedure to those octets -- })

A very bad style to define meaning in comments IMO (without do= ing it in the text).

 

On 07/07/2011 08:44 AM, Erik Andersen wrote: 

Hi Steven, Santosh, and others
=
 
6.1 of X.509 the HASH information object states that=

 
-- shall be the result of=
 applying a hashing procedure to the DER-encoded
octet=
s --
        &=
nbsp;           &nbs=
p;  -- of a value of --ToBeHashed
 
The ENCRYPTED-HASH also states
 =
;
-- shall be the result of applying a hashing procedure to=
 the DER-encoded
(see 6.1) octets --
<= pre> 
The SIGNATURE information object class refe=
rs to ENCRYPTED-HASH.
 
Alre=
ady the 1988 edition required signatures based on DER encoding.<=
/pre>
 
Clearly, the X.509 requires and have =
always required signatures to be
performed over the DE=
R encoded data.
 
I have a p=
roblem with requiring the standard to take into account
non-conforming implementations. However, my proposal was partly a
provocation to see the reaction.
&n=
bsp;
I see three possible solutions:
<=
o:p> 
1)      The decoding an=
d re-encoding in DER as it has been discussed

X.509 does not require this and recommends against. (see abov= e)



2)&n=
bsp;     Remove the DER requirements from 6.1 of X.509<=
o:p>

This will break any conformant a= nd strict verifiers,
and many tolerant verifiers. 

3)  =
;     Mandate use of DER encoding for certificates and =
other similar data
types. This would also include sign=
ed operations. Implementations will then
always perfor=
m signature check over the "blob" (which could be BER encoded).

Isn't that exactly w= hat X.509 says. 

We will still have non-conformant implementations,=
 but they would work and
X.509 would be consistent.

Consistency and compa= tibility in time is not exactly where X standards
are the best. (x400 84= vs 88, well that's old)

recent X.509 keyusage changes breaks XER d= ecoders
(Non Repudiation vs Contentcommitment).
Since two names are a= llowed for the same bit there is no longer
a distinguished XML encoding= possible.



= 
For some peculiar reasons, Extensions shall always be DER encoded. Thi=
s
requirement was introduced already in 1997, when the=
 concept of extensions
was introduced. 

 

It is for exactly the same reason, to have a distinguished encoding.
W= ith extensions it has become even impossible to decode
them and reencod= e completely.

regards
Peter Sylves= ter





Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese<=
/o:p>
Denmark
Mobile: +45 2097 1490
e-am=
ail: era@x500.eu<=
/o:p>
Skype: andersen-erik
http://www.x500.eu/
http://www.x5= 00standard.com/
http://dk.linkedin.com/in/andersenerik
 
 
= 
-----Oprindelig meddelelse-----
Fra: Steven Legg =
[mailto=
:steven.legg@enitiatives.com.au] 
Sendt: 6. juli 2=
011 09:22
Til: x500standard@freelists.org
Cc: Erik Andersen
Emne: [Spam] Re: [x500standard] DE=
R encoding of certificates
 
 
Erik,
 
On 6/07/2011 4:34 PM, Erik Andersen wrote:
Hi folks,
 
In contrast to RFC 5280, X.509 doe=
s not require DER encoding. It only
requi=
res that the signature is
generated across a DER encoded certificate, =
but the itself certificate may
be encoded=
 using BER.
Should we add a sentence somewhere in X.509 and possibly i=
n RFC 5280
specifying that when verifying=
 a
signature a relying party shall decode and then encode the certific=
ate in
DER to verifying the signature?
 
That would cause more proble=
ms than it solves because all too often in
the real wo=
rld signatures are calculated over the BER encoding that is
transmitted rather than the DER encoding it is supposed to be calcula=
ted
over.
 
=

Erik Andersen wrote:
 > If the RDN is part of =
a primary distinguished name, the
primaryDistinguished=

 > component is TRUE and the valueWithContext shal=
l not be included. If in
addition,
 > the primaryDistnguished component is absent taking the default valu=
e, the
encoding
 > of a 5280 c=
ertificate and the encoding of an X.509 certificate are
identical.
 > However, if the primaryDistingished=
 component is present and takes the
value TRUE,
 > a X.509 certificate will be different from a 5280 cert=
ificate and may not
be
 > acce=
pted by all systems. Apparently, some tool will always add the
primaryDistingished
 > component with the =
value TRUE.
 
Is this an obs=
erved problem or a theoretical one ? A decoder using the 5280
definition may well treat the AttributeTypeAndValue type as implici=
tly
extensible, in which case the primaryDistinguished=
 component will be an
unknown extension that is gracef=
ully ignored. The certificate couldn't be
re-encoded i=
n DER, but that's not a wise thing to do anyway for the reason
above.
 
Regards,
Steven
 
Erik Andersen
 
Andersen's L-Service
 
Elsevej 48,
 
DK-3500 Vaerloese
&n=
bsp;
Denmark
 
Mobile: +45 2097 1=
490
 
e-amail: era@x500.eu
<=
pre> 
Skype: andersen-erik
<=
o:p> 
http://www.x500.eu/
 
=
http://www.x500s=
tandard.com/
 
http://dk.lin=
kedin.com/in/andersenerik
 
<= /blockquote>
_______________________________________________=

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

 


_______________________________________________
pkix ma= iling list
pkix@ietf.org
https://w= ww.ietf.org/mailman/listinfo/pkix




--
Website: = http://hallambaker.com/<= /p>

= --_000_B83745DA469B7847811819C5005244AF0F44D7FEscygexch7cygnac_-- From David.Wilson@isode.com Thu Jul 7 02:01:32 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E177821F8600 for ; Thu, 7 Jul 2011 02:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2G2IlbsUPbg for ; Thu, 7 Jul 2011 02:01:32 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0748A21F85F3 for ; Thu, 7 Jul 2011 02:01:32 -0700 (PDT) Received: from [172.16.0.137] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 7 Jul 2011 10:01:30 +0100 From: David Wilson To: x500standard@freelists.org In-Reply-To: <000e01cc3c71$459140e0$d0b3c2a0$@eu> References: <000901cc3ba6$cc97c490$65c74db0$@eu> <4E140D1A.4010001@eNitiatives.com.au> <000e01cc3c71$459140e0$d0b3c2a0$@eu> Organization: Isode Limited Date: Thu, 07 Jul 2011 10:01:30 +0100 Message-ID: <1310029290.2739.91.camel@tardis.isode.net> X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 Jul 2011 08:27:52 -0700 Cc: PKIX , SG17-Q11 Subject: Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 09:01:33 -0000 On Thu, 2011-07-07 at 08:44 +0200, Erik Andersen wrote: > Implementations will then > always perform signature check over the "blob" (which could be BER > encoded). This is already specified in X.509 (end of section 6): "When checking signatures in received data, [the Directory] shall check the signature against the actual data received rather than its conversion of the received data to a distinguished encoding." So, for generators of signed objects, the octets sent must be the octets used to generate the signature. For SIGNATURE rather than SIGNED, the requirement means that the verifier needs to preserve the received encoding of the object(s) to be used. However, signers should use DER, in case a verifier does not follow this, and does decode+re-encode in DER. David From era@x500.eu Thu Jul 7 09:03:56 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB6E11E8074 for ; Thu, 7 Jul 2011 09:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 eKrobPKJ+u9J for ; Thu, 7 Jul 2011 09:03:56 -0700 (PDT) Received: from mail01.dandomain.dk (mail01.dandomain.dk [194.150.112.201]) by ietfa.amsl.com (Postfix) with ESMTP id 97F531F0C34 for ; Thu, 7 Jul 2011 09:03:55 -0700 (PDT) Received: from Morten ([79.138.242.31]) by mail01.dandomain.dk (DanDomain Mailserver) with ASMTP id QXK50453; Thu, 07 Jul 2011 18:03:53 +0200 From: "Erik Andersen" To: "'David Wilson'" , References: <000901cc3ba6$cc97c490$65c74db0$@eu> <4E140D1A.4010001@eNitiatives.com.au> <000e01cc3c71$459140e0$d0b3c2a0$@eu> <1310029290.2739.91.camel@tardis.isode.net> In-Reply-To: <1310029290.2739.91.camel@tardis.isode.net> Date: Thu, 7 Jul 2011 18:03:47 +0200 Message-ID: <000301cc3cbf$78203ae0$6860b0a0$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw8uqI3nnAwH2OcTHuCgxYOFQToBAABIopQ Content-Language: da Cc: 'PKIX' , 'SG17-Q11' Subject: Re: [pkix] [Spam] Re: [x500standard] SV: [Spam] Re: DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 16:03:56 -0000 I agree and I feel the issue is sufficiently resolved.=20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = David Wilson Sendt: 7. juli 2011 11:02 Til: x500standard@freelists.org Cc: PKIX; SG17-Q11 Emne: [Spam] Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of certificates On Thu, 2011-07-07 at 08:44 +0200, Erik Andersen wrote: > Implementations will then > always perform signature check over the "blob" (which could be BER > encoded).=20 This is already specified in X.509 (end of section 6): "When checking signatures in received data, [the Directory] shall check the signature against the actual data received rather than its conversion of the received data to a distinguished encoding." So, for generators of signed objects, the octets sent must be the octets used to generate the signature. For SIGNATURE rather than SIGNED, the requirement means that the verifier needs to preserve the received encoding of the object(s) to be used. However, signers should use DER, in case a verifier does not follow this, and does decode+re-encode in DER. David _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From kent@bbn.com Thu Jul 7 10:19:35 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E76111E8098 for ; Thu, 7 Jul 2011 10:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmQL994+Nt8a for ; Thu, 7 Jul 2011 10:19:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C198811E8097 for ; Thu, 7 Jul 2011 10:19:34 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]:49241) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QesEa-000Eb5-6R; Thu, 07 Jul 2011 13:19:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <004b01cc3c98$ce085590$6a1900b0$@eu> References: <000901cc3ba6$cc97c490$65c74db0$@eu> <4E140D1A.4010001@eNitiatives.com.au> <000e01cc3c71$459140e0$d0b3c2a0$@eu> <004b01cc3c98$ce085590$6a1900b0$@eu> Date: Thu, 7 Jul 2011 13:16:45 -0400 To: "Erik Andersen" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: x500standard@freelists.org, 'SG17-Q11' , 'PKIX' Subject: Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 17:19:35 -0000 At 1:27 PM +0200 7/7/11, Erik Andersen wrote: >I have come to the same conclusion. It is clear by now that the text is >already there (if you can find it). So what is needed is some text here and >there to clarify the issue. > >During the August meeting we will try to come up with pieces of text to be >included in the next edition. > >Erik Andersen Erik, Thanks. I agree that the text you cited is unambiguous. It does seem to be a slight change from what I remember of X.509, where presentation layer transformation of data was a motivation (in part) for DER encoding of signed directory data. The notion of "send what you signed and verify what was received" is simple, but it does not accommodate the possibility of some "helpful" intermediate system altering what was sent (in a reversible fashion). As other have noted, the assumption is that the signer did render the' data into DER before hashing and signing. If we augment that assumption with the notion that the signer also sent what it signed, then life is easy for RPs. I do not agree with PHB's suggestion to remove the DER encoding requirement. We should observe that in some cases an RP will want to use some of the fields extracted from a cert to match against ACLs (or their moral equivalent). It is easier to do this if the cert fields have been encoded in a canonical fashion, because the RP can then compare against ACL data that is also DER-encoded. Steve From kent@bbn.com Thu Jul 7 12:36:51 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63DD11E8085 for ; Thu, 7 Jul 2011 12:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmdOUiSwSEbm for ; Thu, 7 Jul 2011 12:36:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 67B7C11E8072 for ; Thu, 7 Jul 2011 12:36:51 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]:49254) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QeuNW-000CM9-Fl; Thu, 07 Jul 2011 15:36:50 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 7 Jul 2011 15:36:46 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Jim Schaad Subject: [pkix] WGLC for draft-ietf-pkix-rfc5272-bis-03 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 19:36:52 -0000 well, the WGLC ended a week ago. I received one set of comments, from Sean, which were copied to Jim Schaad as well. When Jim acts on Sean's comments, and provides the PKIX list with a reasonable Security Considerations section (JIM?), I'll consider the WGLC to be completed successfully, unless I received adverse comments otherwise. Steve From internet-drafts@ietf.org Thu Jul 7 14:44:19 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BB29E8031; Thu, 7 Jul 2011 14:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyOdVwh7BUE4; Thu, 7 Jul 2011 14:44:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290279E801C; Thu, 7 Jul 2011 14:44:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110707214419.31671.81962.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2011 14:44:19 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-caa-01.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 21:44:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : DNS Certification Authority Authorization (CAA) Resource= Record Author(s) : Phillip Hallam-Baker Rob Stradling Ben Laurie Filename : draft-ietf-pkix-caa-01.txt Pages : 21 Date : 2011-07-07 The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis- issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-caa-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-caa-01.txt From hallam@gmail.com Thu Jul 7 14:54:01 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C77D9E8035 for ; Thu, 7 Jul 2011 14:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=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 D9oSSut0SIqV for ; Thu, 7 Jul 2011 14:54:00 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B16F49E8045 for ; Thu, 7 Jul 2011 14:53:56 -0700 (PDT) Received: by gwb20 with SMTP id 20so674602gwb.31 for ; Thu, 07 Jul 2011 14:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=H3Lh5iP2MQo/LGgbXY3054XeyGYQdksMzA7iCQcjl4c=; b=euebQZdBQ+AnfPQZFydqjYc5Ni5hMNVlBrJcaN1Gqge4eGfYKuVCzZHluiSz+sMq4d B+rSM1EmMk7rSgaz7ynSeyf8bobpcBDD27yDDpM/I2MSp00vHKETPntbRBmCgJjHnxOJ 3ajC5EGRDhrL6/crwXS+SXJ+Ivq7zUIiiR9+s= MIME-Version: 1.0 Received: by 10.101.179.7 with SMTP id g7mr1148351anp.102.1310075627822; Thu, 07 Jul 2011 14:53:47 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Thu, 7 Jul 2011 14:53:47 -0700 (PDT) Date: Thu, 7 Jul 2011 17:53:47 -0400 Message-ID: From: Phillip Hallam-Baker To: pkix@ietf.org Content-Type: multipart/alternative; boundary=001636c926646cdfb104a781c006 Subject: [pkix] Updated Version of CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 21:54:01 -0000 --001636c926646cdfb104a781c006 Content-Type: text/plain; charset=ISO-8859-1 I have submitted an updated version of CAA. http://www.ietf.org/id/draft-ietf-pkix-caa-01.txt The main change here has been to take out most of the references to Relying Party use except for: 1) The parts that explain why it is as bad idea for applications to use CAA records intended to control issue to reject certs at the time of reliance. 2) Bit 6 is reserved to signify RP use (Bit 6 in DNS terms being Bit 1 to everyone else). Note that there is no statement to the effect of 'don't use this for relying party use ever'. Nor is there any statement about how CAs might use the RP bit to audit certificate issue. Given that Google has deployed code that uses the 'auth' property for the purpose of validating RP keys, I think that this is probably a good separation to insist on in future. So we might want to state that the policy/path properties are NEVER for use by RP applications. I don't want to state that the RP bit should be ignored for issuer properties, just that applications should not be using it. The value of the RP bit in my view is for telling audit scripts that are set up to monitor certificate issue that the site authorized the issuer in the past. So for example, imagine that the EFF decides that it is going to use this data in the EFF observatory. I want it to be possible for an auditor to determine if a certificate that is inconsistent with the current issue criteria is so because it was never consistent or because it might have been at the time of issue but the criteria have changed since Another issue from the list that has not been acted on in the text, but has been acted on in my code is to support the specification of the issuer by reference to a string rather than a policy OID. I don't much like this proposal actually. Policy OIDs work very well for us because they are hierarchical. They allow a customer to make statements like 'cert must be under Comodo.EV' or 'cert must be under Comodo'. Policy OIDs are pretty well an objective definition, I don't think there are many arguments in practice over who controls them. Certainly not in the Web Trust or ETSI audit community. That is not necessarily true for an arbitrary string. Another disadvantage of strings is that they encourage variation and ambiguity. There is precisely one way that my code will encode an OID. If we start using strings then we have questions about "Comodo", "Comodo Group" "Comodo Inc" "Comodo CA" which all have different meaning in a legal sense. And then there is "Comodo" vs "Comodo " and "Comodo Inc" vs "Comodo Inc.". I don't think strings work at all well. The design of the RR may appear baroque, but it is designed to achieve orthogonality. My objective was to make one request from the DNS world for the purposes of CAA and not to need to go back again. Getting a RR through the WG is one thing. Getting it into DNS servers is quite another. I want to do that as infrequently as is possible. -- Website: http://hallambaker.com/ --001636c926646cdfb104a781c006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have submitted an updated version of CAA.



The ma= in change here has been to take out most of the references to Relying Party= use except for:

1) The parts that explain why it is as bad idea for app= lications to use CAA records intended to control issue to reject certs at t= he time of reliance.

2) Bit 6 is reserved to signi= fy RP use (Bit 6 in DNS terms being Bit 1 to everyone else).

Note that there is no statement to the effect of 'd= on't use this for relying party use ever'. Nor is there any stateme= nt about how CAs might use the RP bit to audit certificate issue.


Given that Google has deployed code that= uses the 'auth' property for the purpose of validating RP keys, I = think that this is probably a good separation to insist on in future. So we= might want to state that the policy/path properties are NEVER for use by R= P applications.=A0

I don't want to state that the RP bit should be ign= ored for issuer properties, just that applications should not be using it. = The value of the RP bit in my view is for telling audit scripts that are se= t up to monitor certificate issue that the site authorized the issuer in th= e past.

So for example, imagine that the EFF decides that it is= going to use this data in the EFF observatory. I want it to be possible fo= r an auditor to determine if a certificate that is inconsistent with the cu= rrent issue criteria is so because it was never consistent or because it mi= ght have been at the time of issue but the criteria have changed since=A0


Another issue from the list that has not= been acted on in the text, but has been acted on in my code is to support = the specification of the issuer by reference to a string rather than a poli= cy OID.

I don't much like this proposal actually. Policy OI= Ds work very well for us because they are hierarchical. They allow a custom= er to make statements like 'cert must be under Comodo.EV' or 'c= ert must be under Comodo'.

Policy OIDs are pretty well an objective definition, I = don't think there are many arguments in practice over who controls them= . Certainly not in the Web Trust or ETSI audit community. That is not neces= sarily true for an arbitrary string.

Another disadvantage of strings is that they encourage = variation and ambiguity. There is precisely one way that my code will encod= e an OID. If we start using strings then we have questions about "Como= do", "Comodo Group" "Comodo Inc" "Comodo CA&q= uot; which all have different meaning in a legal sense. And then there is &= quot;Comodo" vs "Comodo " and "Comodo Inc" vs &quo= t;Comodo Inc.".

I don't think strings work at all well.
<= br>

The design of the RR may appear baroque, but i= t is designed to achieve orthogonality. My objective was to make one reques= t from the DNS world for the purposes of CAA and not to need to go back aga= in.

Getting a RR through the WG is one thing. Getting it in= to DNS servers is quite another. I want to do that as infrequently as is po= ssible.

--001636c926646cdfb104a781c006-- From paul.hoffman@vpnc.org Thu Jul 7 16:53:47 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35E811E807A for ; Thu, 7 Jul 2011 16:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.746 X-Spam-Level: X-Spam-Status: No, score=-102.746 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdMmtG6zXUml for ; Thu, 7 Jul 2011 16:53:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A8B429E8013 for ; Thu, 7 Jul 2011 16:53:46 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p67NraA0014849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 7 Jul 2011 16:53:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: Date: Thu, 7 Jul 2011 16:53:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C112475-3D75-453E-A2F9-320030B74FAA@vpnc.org> References: To: pkix@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [pkix] Removing relying party from CAA, again 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, 07 Jul 2011 23:53:47 -0000 On Jun 16, 2011, at 7:04 AM, Stephen Kent wrote: > I think it best to remove the discussion of RP use of this feature, = and focus instead on how CAs are expected to use it. On Jul 7, 2011, at 2:53 PM, Phillip Hallam-Baker wrote: > I have submitted an updated version of CAA. >=20 > http://www.ietf.org/id/draft-ietf-pkix-caa-01.txt >=20 >=20 > The main change here has been to take out most of the references to = Relying Party use except for: >=20 > 1) The parts that explain why it is as bad idea for applications to = use CAA records intended to control issue to reject certs at the time of = reliance. >=20 > 2) Bit 6 is reserved to signify RP use (Bit 6 in DNS terms being Bit 1 = to everyone else). Taking out "most" is not what was asked for. The large amount of relying = party text makes it sound like it should be used, the message to the = list notwithstanding.=20 > Note that there is no statement to the effect of 'don't use this for = relying party use ever'. Nor is there any statement about how CAs might = use the RP bit to audit certificate issue. Noted. And thus the confusion. > Given that Google has deployed code that uses the 'auth' property for = the purpose of validating RP keys, I think that this is probably a good = separation to insist on in future. To the best of my understanding, that "deployed code" is not usable by = nearly anyone, and is thus irrelevant. > So we might want to state that the policy/path properties are NEVER = for use by RP applications.=20 A better thing to do would be to do what was originally asked, and = remove the discussion of RP use of CAA. In specific: In section 1, remove: Relying Party A party that makes use of an application whose operation depends on use of a Certificate for making a security decision. Relying Application An application whose operation depends on use of a Certificate for making a security decision. Relying Party Authorization Set The set of Authorization Entries for a domain name that are flagged for use by Relying Party Applications. Analogous to an Access Control List but with no ordering specified. In section 2, remove: Thus Relying Applications MUST NOT use failure to conform to currently published CAA records as a rejection criteria for certificates unless the published records are flagged as being intended for that use. In section 2.1, remove: Relying Parties MUST NOT attempt to enforce CAA records if the Relying Party Authorization Set contains unknown property entry tags that are flagged as critical . . . Relying Parties MUST NOT attempt to enforce CAA records if the Relying Party Authorization Set contains property entries with the Must Be Zero Tag Set. . . . Relying Party This bit is reserved to specify that the corresponding Property Entry MAY be used by Relying Party Applications. Relying Parties MUST NOT attempt to enforce properties specified in CAA records with the Relying Party bit set clear. . . . Since the validity of an end entity certificate is typically a year or more it is quite possible that the CAA records published at a domain will change between the issue of the certificate and verification by a relying party. In section 3.1, remove: Bit 6: Relying Application Use If set, the property entry contains an Authorization Entry that forms part of the Relying Application Authorization Set for the corresponding domain. Also change the example after the bit description to use bit 7 instead = of bit 5. --Paul Hoffman From kyanha@kyanha.net Thu Jul 7 17:05:08 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C073011E809A for ; Thu, 7 Jul 2011 17:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ld-PyMDpIcHC for ; Thu, 7 Jul 2011 17:05:08 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 435C811E8090 for ; Thu, 7 Jul 2011 17:05:08 -0700 (PDT) Received: by pvh18 with SMTP id 18so1117863pvh.31 for ; Thu, 07 Jul 2011 17:05:03 -0700 (PDT) Received: by 10.68.6.7 with SMTP id w7mr1754618pbw.189.1310083503822; Thu, 07 Jul 2011 17:05:03 -0700 (PDT) Received: from penango (ip68-96-191-113.lv.lv.cox.net [68.96.191.113]) by mx.google.com with ESMTPS id c5sm1457524pbh.94.2011.07.07.17.05.01 (version=SSLv3 cipher=OTHER); Thu, 07 Jul 2011 17:05:02 -0700 (PDT) From: "Kyle Hamilton" To: "Phillip Hallam-Baker" Date: Thu, 7 Jul 2011 17:05:07 -0700 (Pacific Daylight Time) Message-ID: In-Reply-To: <000901cc3ba6$cc97c490$65c74db0$@eu> References: <000901cc3ba6$cc97c490$65c74db0$@eu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.8.1eqgpudw8a8eo9mh6r9882 Cc: x500standard@freelists.org, SG17-Q11 , PKIX Subject: Re: [pkix] [Spam] Re: [x500standard] DER encoding of 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, 08 Jul 2011 00:05:08 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.8.1eqgpudw8a8eo9mh6r9882 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit On Thu, Jul 7, 2011 at 5:16 AM, Phillip Hallam-Baker wrote: > I chose 4 or 5: > 4) Eliminate the DER encoding requirement completely > 5) Do nothing at all > PKIX is written to serve the needs of Internet applications. Canonical > encoding of certs has no value for those applications. Canonical encoding of certificates greatly reduces (but does not completely eliminate) the capacity for malicious actors to find hash collisions which will also be valid. I suggest that either 5 or 3 is appropriate, 1 is already existing practice, and 4 and 2 are unacceptable. 1 causes me to wonder, "doesn't anyone care about CPU cycles and/or memory requirements?" My order of preference would be (from the options proposed by this OP and Erik Andersen) 5, 3. 5) Do nothing 4) remove DER mandate completely 3) Mandate DER (AFAICT, already the case) 2) Remove DER mandate from 6.1 of X.509 (undesirable for the same reason that 4 is) 1) Mandate decoding/re-encoding (already the case for conversion between different encoding rules) Please, stop overthinking it. As for XER and its inability to produce a canonical encoding given the dual names, I suggest accepting and transmitting either. ITU messed it up, and we now have to live with the consequences. Since there are two possible canonical encodings, it still mitigates the hash-collision possibility issue, albeit with twice the potential collision capacity. (This is, of course, unless everyone WANTS to do away with the Certificate definition, which would leave everyone who supports legacy systems -- that is, most of us -- out in the cold.) -Kyle H --gmsm1.8.1eqgpudw8a8eo9mh6r9882 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINAjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGxjCCBa6g AwIBAgICCMUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNzE5MDFaFw0xMjA2MDUyMDMxMzFaMIHAMSAwHgYDVQQNExcyMDc2MDUtQzh5TUxvb3ll VE85NFFKeDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xIDAeBgkqhkiG9w0BCQEWEWt5YW5oYUBreWFuaGEubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5YylxEUtOSlqBT0sxqB7H0YUDx30ADzggTrSLA9n JVa0QCcIXhk04n7VUD5Augbc40rWhgmB8xl6N9pQ5qvAQZj8JmNej6LRlueN/et9MCjNN0euH0Ky zzKBSE5fxoUPYTTa6QBBurmKNR0navAKWBi8ITLRPi864zTay2oW1A1E1nt69SgJGn3PAv/LyKII WWMzu9YeJsRCd4u6vLHOsGHvr5rc7Dq4bXx8x+vyHgSuYccAnNu81lOC2Unea4TORMoULiwKOTRb pEy35H9Y7MW+SCTlaQiSLgxvYB260OuofHZgcS0wr/OnbGVAEUeBRYhfu3BaxNlZ6zY7mvs9NwID AQABo4IC+jCCAvYwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBThUNrymHVQVA3i/K/6BF4dnrmTqDAfBgNVHSMEGDAWgBSuVYNv 7DHKufcd+q9rMfPIHeOsuzAcBgNVHREEFTATgRFreWFuaGFAa3lhbmhhLm5ldDCCAUIGA1UdIASC ATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9p bnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFM aW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9v Y3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDov L3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAjquLhQpUqqxo pg1hbv8zADjhTUY1Gxm1Ha/5Ntdjds7HZ54jOqD2fVwWRbqLAtq+rwHIaudvk13icftTedJlV01r +6VjmOZhSwOPPiYG/v81ABitv8bfyOkei/3BblORXOyzwuXHrbmMOgaEcCmQmqyTo1UJiNMy5Tw0 CvDt+KbSbGP2lQL8BAGyLhswuGePoReqw221KsX6sZJ4Eovk70SlNN19YiRAFYdWL+ggY5mMPn9S qXk8GGLaOyg3g2HnVr7Y4MLYfI0pheoRvoGxj8a4xofTz3u6OlGYE/3D5/uLQbw/rTz6GVVgUFPi GFSKZjzXwfEYJ3Kd1BMXCyfE6zGCAnwwggJ4AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAgjFMAkGBSsOAwIaBQCggb4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTEwNzA4MDAwNTA3WjAjBgkqhkiG9w0BCQQxFgQUSfPKZ8l1TxRvG1JQcQDrZW5M 6sYwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIIBAFgdzy7DkUN3evLm3g3XNG8RkroBy/LIt8ym932/A8qoR+voOBD6k7e1WVvzZ2puScJGhrY1 180e5wW+ygQKY0HRQGMcBk5PBJCqYBFwe27ms4GwlM4i7ZV+pmM4qbiQADpMNIG0NbJvHNyX7HBd atDG1lIdO2jR7ybH80XwEVJ7e1R3EG4pWSXNl1RTW3fJ5XVM61DCIdZSbaFzExgVyeZvbT8/IAHi FxIPOW0yyaxqrNXAcBqL0RnWlTYQlrFeZjvRgtQobGjIczutGaf2wD8JAxPkGeYs/xwOFBfObi69 ekBd5wqruaikhDw0RyA/JEnyoL41i4KosQuxfkF4wsYAAAAAAAA= --gmsm1.8.1eqgpudw8a8eo9mh6r9882-- From paul.hoffman@vpnc.org Thu Jul 7 17:08:01 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EA021F86C5 for ; Thu, 7 Jul 2011 17:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c1jST9na4rS for ; Thu, 7 Jul 2011 17:08:01 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9795221F86C4 for ; Thu, 7 Jul 2011 17:08:00 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6807nIi015336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 7 Jul 2011 17:07:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: Date: Thu, 7 Jul 2011 17:07:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: pkix@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 00:08:01 -0000 On Jul 7, 2011, at 2:53 PM, Phillip Hallam-Baker wrote: > Another issue from the list that has not been acted on in the text, = but has been acted on in my code is to support the specification of the = issuer by reference to a string rather than a policy OID. >=20 > I don't much like this proposal actually. Policy OIDs work very well = for us because they are hierarchical. They allow a customer to make = statements like 'cert must be under Comodo.EV' or 'cert must be under = Comodo'. This is a good argument. Specifying a policy OID that is the root of the = CA's policy OID arc without having to specify the exact-match OID seems = like a good idea. > Policy OIDs are pretty well an objective definition, I don't think = there are many arguments in practice over who controls them. Certainly = not in the Web Trust or ETSI audit community. That is not necessarily = true for an arbitrary string. The latter isn't a good argument. A site that publishes a CAA record is = going to be as restrictive as it wants to be. The fact that a string = like "Comodo" is not an objective definition isn't relevant: it is still = good enough to make any CA whose name is not "Comodo" non-compliant if = they issue a cert. > Another disadvantage of strings is that they encourage variation and = ambiguity. There is precisely one way that my code will encode an OID. = If we start using strings then we have questions about "Comodo", "Comodo = Group" "Comodo Inc" "Comodo CA" which all have different meaning in a = legal sense. And then there is "Comodo" vs "Comodo " and "Comodo Inc" vs = "Comodo Inc.". Quite true. You would need to iteratively improve your code each time = you were about to issue a cert but got a CAA record that your code did = not recognize. However, that additional responsibility on the part of = CAs is not of much concern to those of us in the domain-owning field. > I don't think strings work at all well. Strings as you portray them don't, particularly because they miss the = advantage of OID trees. However, a better definition of strings might. I propose that the identifier be a free-text string. If the string = consists of only ASCII digits and ASCII periods, it is considered a = policy OID, and that OID follows the rule that the policy property = applies to the specified policy OID and all policy OIDs that fall within = the same OID arc. Using strings this proposed way also gets rid of the tortured ASN.1 OID = encoding in the current draft. Now, it's just plain text, easily typed = by the DNS admin. Thoughts? --Paul Hoffman From mrex@sap.com Thu Jul 7 19:52:19 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F7621F889D for ; Thu, 7 Jul 2011 19:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.206 X-Spam-Level: X-Spam-Status: No, score=-10.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 9dhSlF4T35eA for ; Thu, 7 Jul 2011 19:52:18 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6E821F885E for ; Thu, 7 Jul 2011 19:52:18 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p682qBll029601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2011 04:52:16 +0200 (MEST) From: Martin Rex Message-Id: <201107080252.p682qBBm008688@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Fri, 8 Jul 2011 04:52:11 +0200 (MEST) In-Reply-To: from "Paul Hoffman" at Jul 7, 11 05:07:58 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA 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, 08 Jul 2011 02:52:19 -0000 Paul Hoffman wrote: > > Phillip Hallam-Baker wrote: > > > > If we start using strings then we have questions about "Comodo", > > "Comodo Group" "Comodo Inc" "Comodo CA" which all have different > > meaning in a legal sense. And then there is "Comodo" vs "Comodo " > > and "Comodo Inc" vs "Comodo Inc.". That is something that every CA can solve trivilally by (a) choosing names for their businesses that humans can intuitively recognize and (b) showing the information that admins will have to enter in an easily accessible form on the CA's WebSite. (But there are folks who like to rebrand businesses regularly, due to acquisition, merger, sale, consulting ...) Rebranding a CA becomes difficult when there are several ten thousands of customers with CAA records pointing to variantions of the current brand. If you force your customers to update those records, some of them might put in the name of a different CA instead... What strings are acceptable to a CA as CAA strings is something that can be sufficiently addressed by documentation. > > > I don't think strings work at all well. > > Strings as you portray them don't, particularly because they miss the > advantage of OID trees. However, a better definition of strings might. > > I propose that the identifier be a free-text string. If the string > consists of only ASCII digits and ASCII periods, it is considered a > policy OID, and that OID follows the rule that the policy property > applies to the specified policy OID and all policy OIDs that fall > within the same OID arc. If OIDs, then certainly the printable string form of OIDs is preferable to binary blobs. I personally think that OIDs are extremely tough on humans (probably not when the entire universe contains only a one-digit number of them, but definitely when there are 100+ of them). lower estimate for CA policy OIDs: 3 policy oids X 50 CAs = 150 different OIDs > > Using strings this proposed way also gets rid of the tortured ASN.1 OID > encoding in the current draft. Now, it's just plain text, easily typed > by the DNS admin. I also think that the half million DNS admins and their perils are more important than those 50 CAs (who do this for a living and can quickly adapt to recognizing anything, because they do it daily). -Martin From pgut001@login01.cs.auckland.ac.nz Thu Jul 7 21:19:40 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1457011E807C for ; Thu, 7 Jul 2011 21:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YKrcq9tPTXK for ; Thu, 7 Jul 2011 21:19:39 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 336DC11E807A for ; Thu, 7 Jul 2011 21:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1310098779; x=1341634779; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20hallam@gmail.com,=20peter.sylvester@edelweb.fr |Subject:=20Re:=20[pkix]=20[Spam]=20Re:=20[x500standard] =20DER=20encoding=20of=20certificates|Cc:=20pkix@ietf.org ,=20t09sg17q11@lists.itu.int,=20x500standard@freelists.or g|In-Reply-To:=20|Message-Id:=20|Date:=20Fri,=2008=20Jul =202011=2016:19:29=20+1200; bh=6GGKfxbfxlOhoK+IlopcOkn90hBjyHT7D6ysNEItc4k=; b=KB/e721BazCaI00ZyRAGmcqzwpvojBOc3/l/NAHWjNPAzNsNp+PWh6Or W7QRL6BA3OgAB1BmfIoT3jNSuE4GaH4dFtdBt/W7oxE1yMlKVt7Wqgcuw PExeXVpSph6moTi1TmVeuTorH5Vq+54I3bioNKp6MN3XTG/ZebpRjiDgd E=; X-IronPort-AV: E=Sophos;i="4.65,497,1304251200"; d="scan'208";a="70830525" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Jul 2011 16:19:30 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qf2XJ-00041U-IG; Fri, 08 Jul 2011 16:19:29 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qf2XJ-0000IK-Jz; Fri, 08 Jul 2011 16:19:29 +1200 From: Peter Gutmann To: hallam@gmail.com, peter.sylvester@edelweb.fr In-Reply-To: Message-Id: Date: Fri, 08 Jul 2011 16:19:29 +1200 Cc: pkix@ietf.org, t09sg17q11@lists.itu.int, x500standard@freelists.org Subject: Re: [pkix] [Spam] Re: [x500standard] DER encoding of 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, 08 Jul 2011 04:19:40 -0000 Phillip Hallam-Baker writes: >[...] +1 throughout. Saved me having to type up the same thing. (I would prefer to keep the DER requirement though because certs can already get garbled enough without telling developers that they don't even have to make an effort). Peter. From pgut001@login01.cs.auckland.ac.nz Thu Jul 7 21:33:57 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3072021F864A for ; Thu, 7 Jul 2011 21:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RyFTkwAw8mW for ; Thu, 7 Jul 2011 21:33:56 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCD021F864B for ; Thu, 7 Jul 2011 21:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1310099637; x=1341635637; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20David.Wilson@isode.com,=20x500standard@freelists.o rg|Subject:=20Re:=20[pkix]=20[x500standard]=20SV:=20[Spam ]=20Re:=20DER=20encoding=20of=20certificates|Cc:=20pkix@i etf.org,=20t09sg17q11@lists.itu.int|In-Reply-To:=20<13100 29290.2739.91.camel@tardis.isode.net>|Message-Id:=20|Date:=20Fri,=20 08=20Jul=202011=2016:33:55=20+1200; bh=QCCmMIm7TTUoqPDNLJDLVL+8jmFjKMX3EtkfKXiJye4=; b=Y1bZ1ekmclcEUjyBEinB5u8nhF/MpbZK7LCSPrKhmQcPd1Q3ryWfl8Cu x0tjxEb3EHQSaMR2NurGcXTqohsW9eHj62TXPWIY6UQXwOn/G9HMVSf2M +kIrH5uuRgjMtNT6oglsmnob/cjU2+J87LI9V4EPE6SRrzNXXk5v7J21q Y=; X-IronPort-AV: E=Sophos;i="4.65,497,1304251200"; d="scan'208";a="70834645" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Jul 2011 16:33:56 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qf2lH-0004XI-HR; Fri, 08 Jul 2011 16:33:55 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qf2lH-000198-Bt; Fri, 08 Jul 2011 16:33:55 +1200 From: Peter Gutmann To: David.Wilson@isode.com, x500standard@freelists.org In-Reply-To: <1310029290.2739.91.camel@tardis.isode.net> Message-Id: Date: Fri, 08 Jul 2011 16:33:55 +1200 Cc: pkix@ietf.org, t09sg17q11@lists.itu.int Subject: Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of 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, 08 Jul 2011 04:33:57 -0000 David Wilson writes: >This is already specified in X.509 (end of section 6): > >"When checking signatures in received data, [the Directory] shall check the >signature against the actual data received rather than its conversion of the >received data to a distinguished encoding." Just to be pedantic, I guess I should point out that since X.509 seems to be written in terms of some fantasy entity called The Directory, it doesn't apply to anything that actually exists. Applying a strict interpretation, nothing is actually bound by X.509 in this case. Peter. From anders.rundgren@telia.com Thu Jul 7 21:59:22 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9D621F8917 for ; Thu, 7 Jul 2011 21:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNWB5NOfwNKZ for ; Thu, 7 Jul 2011 21:59:22 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5F521F8915 for ; Thu, 7 Jul 2011 21:59:19 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B009F96BD; Fri, 8 Jul 2011 06:59:14 +0200 Message-ID: <4E168E9B.8080502@telia.com> Date: Fri, 08 Jul 2011 06:59:07 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: x500standard@freelists.org, pkix@ietf.org, t09sg17q11@lists.itu.int References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of 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, 08 Jul 2011 04:59:23 -0000 Why should PKIX bother with a document that isn't normative for PKI anymore? For a PKIX-version of this topic I would make a difference between "certificate producers" that indeed SHOULD/MUST generate DER encoding while "certificate consumers" SHOULD NOT break due to incorrect decoding. Certificate consumers in browsers are already dealing with pretty broken certificates. --anders From era@x500.eu Fri Jul 8 01:32:48 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B29B21F86EC for ; Fri, 8 Jul 2011 01:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 M7EJV7aq1XNR for ; Fri, 8 Jul 2011 01:32:47 -0700 (PDT) Received: from mail01.dandomain.dk (mail01.dandomain.dk [194.150.112.201]) by ietfa.amsl.com (Postfix) with ESMTP id E981E21F859A for ; Fri, 8 Jul 2011 01:32:46 -0700 (PDT) Received: from Morten ([212.27.26.62]) by mail01.dandomain.dk (DanDomain Mailserver) with ASMTP id RPO65443; Fri, 08 Jul 2011 10:32:43 +0200 From: "Erik Andersen" To: "'Kyle Hamilton'" , "'Phillip Hallam-Baker'" References: <000901cc3ba6$cc97c490$65c74db0$@eu> In-Reply-To: Date: Fri, 8 Jul 2011 10:32:34 +0200 Message-ID: <003601cc3d49$9bae4c60$d30ae520$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw9ArMLjGV5NFnkR3mTeEywd+kTUwARrGgQ Content-Language: da Cc: x500standard@freelists.org, 'SG17-Q11' , 'PKIX' Subject: Re: [pkix] [Spam] Re: [Spam] Re: [x500standard] DER encoding of 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, 08 Jul 2011 08:32:48 -0000 So far, we have no plans within ITU-T to suggest XER encoding of certificates. This would certainly require a lot of considerations. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: Kyle Hamilton [mailto:kyanha@kyanha.net] Sendt: 8. juli 2011 02:05 Til: Phillip Hallam-Baker Cc: Erik Andersen; x500standard@freelists.org; SG17-Q11; PKIX Emne: [Spam] Re: [pkix] [Spam] Re: [x500standard] DER encoding of certificates On Thu, Jul 7, 2011 at 5:16 AM, Phillip Hallam-Baker wrote: > I chose 4 or 5: > 4) Eliminate the DER encoding requirement completely > 5) Do nothing at all > PKIX is written to serve the needs of Internet applications. Canonical > encoding of certs has no value for those applications. Canonical encoding of certificates greatly reduces (but does not completely eliminate) the capacity for malicious actors to find hash collisions which will also be valid. I suggest that either 5 or 3 is appropriate, 1 is already existing practice, and 4 and 2 are unacceptable. 1 causes me to wonder, "doesn't anyone care about CPU cycles and/or memory requirements?" My order of preference would be (from the options proposed by this OP and Erik Andersen) 5, 3. 5) Do nothing 4) remove DER mandate completely 3) Mandate DER (AFAICT, already the case) 2) Remove DER mandate from 6.1 of X.509 (undesirable for the same reason that 4 is) 1) Mandate decoding/re-encoding (already the case for conversion between different encoding rules) Please, stop overthinking it. As for XER and its inability to produce a canonical encoding given the dual names, I suggest accepting and transmitting either. ITU messed it up, and we now have to live with the consequences. Since there are two possible canonical encodings, it still mitigates the hash-collision possibility issue, albeit with twice the potential collision capacity. (This is, of course, unless everyone WANTS to do away with the Certificate definition, which would leave everyone who supports legacy systems -- that is, most of us -- out in the cold.) -Kyle H From era@x500.eu Fri Jul 8 01:49:12 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E6221F86D4 for ; Fri, 8 Jul 2011 01:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_DK=1.009, SARE_MILLIONSOF=0.315] 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-Q9u6M9HFqE for ; Fri, 8 Jul 2011 01:49:11 -0700 (PDT) Received: from mail01.dandomain.dk (mail01.dandomain.dk [194.150.112.201]) by ietfa.amsl.com (Postfix) with ESMTP id A6E3621F86CB for ; Fri, 8 Jul 2011 01:49:10 -0700 (PDT) Received: from Morten ([212.27.26.62]) by mail01.dandomain.dk (DanDomain Mailserver) with ASMTP id RPF59208; Fri, 08 Jul 2011 10:49:08 +0200 From: "Erik Andersen" To: References: <1310029290.2739.91.camel@tardis.isode.net> In-Reply-To: Date: Fri, 8 Jul 2011 10:49:00 +0200 Message-ID: <003701cc3d4b$e6bfe900$b43fbb00$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw9KFKPYo4oI71dTzCXFMGx5N5uFAAIlA7A Content-Language: da Cc: pkix@ietf.org, t09sg17q11@lists.itu.int Subject: Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of 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, 08 Jul 2011 08:49:12 -0000 I know that X.509 has a life outside directories and that X.509 in some places makes unnecessary references to Directory. Directory is not a fantasy. There many thousands or maybe millions of Microsoft Active Directories spinning every day. A lot of other LDAP = systems are out there. All Identity Management System have a directory, mostly = LDAP, as a major component. X.500 is also very much alive and kicking. =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = Peter Gutmann Sendt: 8. juli 2011 06:34 Til: David.Wilson@isode.com; x500standard@freelists.org Cc: pkix@ietf.org; t09sg17q11@lists.itu.int Emne: Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of = certificates David Wilson writes: >This is already specified in X.509 (end of section 6): > >"When checking signatures in received data, [the Directory] shall check = the >signature against the actual data received rather than its conversion = of the >received data to a distinguished encoding." Just to be pedantic, I guess I should point out that since X.509 seems = to be written in terms of some fantasy entity called The Directory, it doesn't apply to anything that actually exists. Applying a strict interpretation, = nothing is actually bound by X.509 in this case. Peter. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From era@x500.eu Fri Jul 8 01:57:03 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695C321F8574 for ; Fri, 8 Jul 2011 01:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 LMdh3guzKfqR for ; Fri, 8 Jul 2011 01:57:02 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 2D17921F8571 for ; Fri, 8 Jul 2011 01:57:02 -0700 (PDT) Received: from Morten ([212.27.26.62]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id RPM21256; Fri, 08 Jul 2011 10:56:56 +0200 From: "Erik Andersen" To: "'Anders Rundgren'" , , , References: <4E168E9B.8080502@telia.com> In-Reply-To: <4E168E9B.8080502@telia.com> Date: Fri, 8 Jul 2011 10:56:42 +0200 Message-ID: <003801cc3d4c$fd7ba750$f872f5f0$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw9K+YWCfjmjgzYRTWtWCMEc5plfwAIJHbQ Content-Language: da Subject: Re: [pkix] [Spam] Re: [x500standard] SV: [Spam] Re: DER encoding of 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, 08 Jul 2011 08:57:03 -0000 You should bother as X.509 is the recommendation most downloaded of all ITU-T Recommendations and is an important PKI/PMI player. When updating X.509 it is important to consult also the PKIX experts. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = Anders Rundgren Sendt: 8. juli 2011 06:59 Til: x500standard@freelists.org; pkix@ietf.org; t09sg17q11@lists.itu.int Emne: [Spam] Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of certificates Why should PKIX bother with a document that isn't normative for PKI anymore? For a PKIX-version of this topic I would make a difference between "certificate producers" that indeed SHOULD/MUST generate DER encoding while "certificate consumers" SHOULD NOT break due to incorrect decoding. Certificate consumers in browsers are already dealing with pretty broken certificates. --anders _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From DPKemp@missi.ncsc.mil Fri Jul 8 06:11:30 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F172A21F8A25 for ; Fri, 8 Jul 2011 06:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMe9sIaTODYB for ; Fri, 8 Jul 2011 06:11:29 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 67D0E21F8A24 for ; Fri, 8 Jul 2011 06:11:28 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p68DBRHh048774 for ; Fri, 8 Jul 2011 09:11:27 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 09:11:29 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 8 Jul 2011 09:11:26 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Policy OIDs in CAA Thread-Index: Acw9AyXW3ZCTEYNAQ/ezo6c3mL/qFQAa8Mrw References: From: "Kemp, David P." To: X-OriginalArrivalTime: 08 Jul 2011 13:11:29.0890 (UTC) FILETIME=[8D0BE420:01CC3D70] Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 13:11:30 -0000 From: Paul Hoffman > > On Jul 7, 2011, at 2:53 PM, Phillip Hallam-Baker wrote: >> I don't think strings work at all well. > > Strings as you portray them don't, particularly because > they miss the advantage of OID trees. However, a better > definition of strings might. > > I propose that the identifier be a free-text string. > If the string consists of only ASCII digits and ASCII > periods, it is considered a policy OID, and that OID > follows the rule that the policy property applies to > the specified policy OID and all policy OIDs that fall > within the same OID arc. > > Using strings this proposed way also gets rid of the > tortured ASN.1 OID encoding in the current draft. > Now, it's just plain text, easily typed by the DNS admin. > > Thoughts? > > --Paul Hoffman I think you meant the right thing but didn't say it clearly. A string encoding of an OID is fine, a free-text string is not. In order to avoid the non-hierarchical and multi-variant nature of unconstrained strings the rule should be: The string represents a policy OID and MUST consist of only ASCII digits and ASCII periods. Dave From paul.hoffman@vpnc.org Fri Jul 8 07:15:08 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180E721F8A8D for ; Fri, 8 Jul 2011 07:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.726 X-Spam-Level: X-Spam-Status: No, score=-102.726 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAaNRODqzGZq for ; Fri, 8 Jul 2011 07:15:07 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 304D021F8A78 for ; Fri, 8 Jul 2011 07:15:07 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p68EEujg049624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Jul 2011 07:14:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 8 Jul 2011 07:15:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <972FEDEC-6687-4E8D-8D78-0D18E6BFC36D@vpnc.org> References: To: "Kemp, David P." X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 14:15:08 -0000 On Jul 8, 2011, at 6:11 AM, Kemp, David P. wrote: >=20 > From: Paul Hoffman >>=20 >> On Jul 7, 2011, at 2:53 PM, Phillip Hallam-Baker wrote: >>> I don't think strings work at all well. >>=20 >> Strings as you portray them don't, particularly because >> they miss the advantage of OID trees. However, a better >> definition of strings might. >>=20 >> I propose that the identifier be a free-text string. >> If the string consists of only ASCII digits and ASCII >> periods, it is considered a policy OID, and that OID >> follows the rule that the policy property applies to >> the specified policy OID and all policy OIDs that fall >> within the same OID arc. >>=20 >> Using strings this proposed way also gets rid of the >> tortured ASN.1 OID encoding in the current draft. >> Now, it's just plain text, easily typed by the DNS admin. >>=20 >> Thoughts? >>=20 >> --Paul Hoffman >=20 >=20 > I think you meant the right thing but didn't say it clearly. A string > encoding of an OID is fine, a free-text string is not. In order to = avoid > the non-hierarchical and multi-variant nature of unconstrained strings > the rule should be: >=20 > The string represents a policy OID and MUST consist of only > ASCII digits and ASCII periods. That was not my intended meaning: I really did mean "free text, and if = that free text has this property, it is treated as an OID". Given that this is a voluntary protocol that is being run by CAs, false = negatives (that is, a CAA record that has an unrecognized text string = from a domain that actually wanted a cert from the CA doing the test) = seems fairly harmless. The fact that the CA can test the CAA record for = a long period before issuance is needed mitigates any problem even = further. Why do you feel that free text ("WhizzyCA", "WhizzyCA, Inc.", "I want a = WhizzyCA cert" ...) is not fine for this purpose?=20 --Paul Hoffman From hallam@gmail.com Fri Jul 8 07:15:58 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A2121F8A91 for ; Fri, 8 Jul 2011 07:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[AWL=-0.424, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 dCZR12OUTAT3 for ; Fri, 8 Jul 2011 07:15:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF6121F8A8D for ; Fri, 8 Jul 2011 07:15:57 -0700 (PDT) Received: by ywp31 with SMTP id 31so181212ywp.31 for ; Fri, 08 Jul 2011 07:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oPn3dcm4TgGRmDm26cvOIdFhqVY4GS/gAfOBDHRMeJY=; b=n1mf1UBlg0nsheh4C0gso2QoTJzpopIQmIjubrz74/D+g1K72IzhgAP8lRAA7xWaKp aHgSGZ679ZN3nBV6vsWmNVEvWvupmqwVTZ/+ooDcIDkfXXxtTcMtvJ/645JPehmwhB/i XPOFjNK8tbi97s/YYdzQEweKTsWN/Ei6xlYro= MIME-Version: 1.0 Received: by 10.101.162.11 with SMTP id p11mr1718887ano.159.1310134542152; Fri, 08 Jul 2011 07:15:42 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Fri, 8 Jul 2011 07:15:42 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jul 2011 10:15:42 -0400 Message-ID: From: Phillip Hallam-Baker To: "Kemp, David P." Content-Type: multipart/alternative; boundary=001636ed6c7ffe334c04a78f7790 Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 14:15:58 -0000 --001636ed6c7ffe334c04a78f7790 Content-Type: text/plain; charset=ISO-8859-1 That risks getting into the problem that there are multiple encodings for OIDs. One solution would be to use the OID uri scheme: http://tools.ietf.org/html/rfc3061 This would require a new property tag since we have deployed code. We could use 'issuer' example: example.com CAA 33 issuer "oid:1.3.6.1.4.1" On Fri, Jul 8, 2011 at 9:11 AM, Kemp, David P. wrote: > > From: Paul Hoffman > > > > On Jul 7, 2011, at 2:53 PM, Phillip Hallam-Baker wrote: > >> I don't think strings work at all well. > > > > Strings as you portray them don't, particularly because > > they miss the advantage of OID trees. However, a better > > definition of strings might. > > > > I propose that the identifier be a free-text string. > > If the string consists of only ASCII digits and ASCII > > periods, it is considered a policy OID, and that OID > > follows the rule that the policy property applies to > > the specified policy OID and all policy OIDs that fall > > within the same OID arc. > > > > Using strings this proposed way also gets rid of the > > tortured ASN.1 OID encoding in the current draft. > > Now, it's just plain text, easily typed by the DNS admin. > > > > Thoughts? > > > > --Paul Hoffman > > > I think you meant the right thing but didn't say it clearly. A string > encoding of an OID is fine, a free-text string is not. In order to avoid > the non-hierarchical and multi-variant nature of unconstrained strings > the rule should be: > > The string represents a policy OID and MUST consist of only > ASCII digits and ASCII periods. > > Dave > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Website: http://hallambaker.com/ --001636ed6c7ffe334c04a78f7790 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That risks getting into the problem that there are multiple encodings for O= IDs.

One solution would be to use the OID uri scheme:

This would require a new property tag since we have dep= loyed code. =A0We could use 'issuer'

examp= le:


= example.com =A0 =A0CAA =A033 issuer "oid:1.3.6.1.4.1"


On Fri, Jul= 8, 2011 at 9:11 AM, Kemp, David P. <DPKemp@missi.ncsc.mil> wrote:

From: Paul Hoffman
>
> On Jul 7, 2011, at 2:53 PM, Phillip Hallam-Baker wrote:
>> I don't think strings work at all well= .
>
> Strings as you portray them don't, particularly because
> they miss the advantage of OID trees. However, a better
> definition of strings might.
>
> I propose that the identifier be a free-text string.
> If the string consists of only ASCII digits and ASCII
> periods, it is considered a policy OID, and that OID
> follows the rule that the policy property applies to
> the specified policy OID and all policy OIDs that fall
> within the same OID arc.
>
> Using strings this proposed way also gets rid of the
> tortured ASN.1 OID encoding in the current draft.
> Now, it's just plain text, easily typed by the DNS admin.
>
> Thoughts?
>
> --Paul Hoffman


I think you meant the right thing but didn't say it clearly. =A0A= string
encoding of an OID is fine, a free-text string is not. In order to avoid the non-hierarchical and multi-variant nature of unconstrained strings
the rule should be:

=A0 The string represents a policy OID and MUST consist of only
=A0 ASCII digits and ASCII periods.

Dave

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



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

--001636ed6c7ffe334c04a78f7790-- From mrex@sap.com Fri Jul 8 07:24:53 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183B821F87B2 for ; Fri, 8 Jul 2011 07:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.207 X-Spam-Level: X-Spam-Status: No, score=-10.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 JH2fmnbhIq6j for ; Fri, 8 Jul 2011 07:24:52 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 56FB021F8793 for ; Fri, 8 Jul 2011 07:24:51 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p68EOnqo020979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2011 16:24:49 +0200 (MEST) From: Martin Rex Message-Id: <201107081424.p68EOnZv017935@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Fri, 8 Jul 2011 16:24:49 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Jul 8, 11 10:15:42 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA 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, 08 Jul 2011 14:24:53 -0000 Phillip Hallam-Baker wrote: > > That risks getting into the problem that there are multiple > encodings for OIDs. *cough* What?? I've seen quite a variety of bugs around ASN.1, but "multiple encodings for OIDs" is something I have never heard of. I'm wondering: are printable string OIDs used in any SNMP-Tools? -Martin From hallam@gmail.com Fri Jul 8 07:25:26 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC86721F8793 for ; Fri, 8 Jul 2011 07:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.038, 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 xGgIDeczKnKc for ; Fri, 8 Jul 2011 07:25:26 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E9B3D21F86D1 for ; Fri, 8 Jul 2011 07:25:25 -0700 (PDT) Received: by yxp4 with SMTP id 4so985199yxp.31 for ; Fri, 08 Jul 2011 07:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YAiSeMJNAhXuQ/jWmMKVozTPLEr/GdimUsi+eIwH0o4=; b=SVyID8jKLMcxztjT/tQPbQr7K9DS7IYKWzUP4yxjqkGRXtU9lUjauQ5YE4S6c2sb4J VcGg8TGD6LZIZL14KviSvi+yxzMwITOudCbesiHiKKesTSGE7iVzhmQR9mahVvTvKCHs IOFraida1jybMm8bcnEI+AuJWh28dvxhcec00= MIME-Version: 1.0 Received: by 10.101.168.32 with SMTP id v32mr1341403ano.36.1310135125486; Fri, 08 Jul 2011 07:25:25 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Fri, 8 Jul 2011 07:25:25 -0700 (PDT) In-Reply-To: <972FEDEC-6687-4E8D-8D78-0D18E6BFC36D@vpnc.org> References: <972FEDEC-6687-4E8D-8D78-0D18E6BFC36D@vpnc.org> Date: Fri, 8 Jul 2011 10:25:25 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=001636c5969cc32ccb04a78f9a9c Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 14:25:27 -0000 --001636c5969cc32ccb04a78f9a9c Content-Type: text/plain; charset=ISO-8859-1 No, I think that is broken. It requires a mapping to be defined from the string to the policy for a start. One of the use cases we have is that public CAs frequently run CAs for other parties under different policies or under variants of policies. Another use case is to enable control of privately run CAs. Management of those policies with OIDs or paths is straightforward. Introducing a string such a WhizzyCA is much more complex and would lead at least one CA to have a major commercial problem as they don't own the principal brand under which they trade. On Fri, Jul 8, 2011 at 10:15 AM, Paul Hoffman wrote: > On Jul 8, 2011, at 6:11 AM, Kemp, David P. wrote: > > > > > From: Paul Hoffman > >> > >> On Jul 7, 2011, at 2:53 PM, Phillip Hallam-Baker wrote: > >>> I don't think strings work at all well. > >> > >> Strings as you portray them don't, particularly because > >> they miss the advantage of OID trees. However, a better > >> definition of strings might. > >> > >> I propose that the identifier be a free-text string. > >> If the string consists of only ASCII digits and ASCII > >> periods, it is considered a policy OID, and that OID > >> follows the rule that the policy property applies to > >> the specified policy OID and all policy OIDs that fall > >> within the same OID arc. > >> > >> Using strings this proposed way also gets rid of the > >> tortured ASN.1 OID encoding in the current draft. > >> Now, it's just plain text, easily typed by the DNS admin. > >> > >> Thoughts? > >> > >> --Paul Hoffman > > > > > > I think you meant the right thing but didn't say it clearly. A string > > encoding of an OID is fine, a free-text string is not. In order to avoid > > the non-hierarchical and multi-variant nature of unconstrained strings > > the rule should be: > > > > The string represents a policy OID and MUST consist of only > > ASCII digits and ASCII periods. > > > That was not my intended meaning: I really did mean "free text, and if that > free text has this property, it is treated as an OID". > > Given that this is a voluntary protocol that is being run by CAs, false > negatives (that is, a CAA record that has an unrecognized text string from a > domain that actually wanted a cert from the CA doing the test) seems fairly > harmless. The fact that the CA can test the CAA record for a long period > before issuance is needed mitigates any problem even further. > > Why do you feel that free text ("WhizzyCA", "WhizzyCA, Inc.", "I want a > WhizzyCA cert" ...) is not fine for this purpose? > > --Paul Hoffman > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Website: http://hallambaker.com/ --001636c5969cc32ccb04a78f9a9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No, I think that is broken.

It requires a mapping to be = defined from the string to the policy for a start.=A0

<= div>One of the use cases we have is that public CAs frequently run CAs for = other parties under different policies or under variants of policies.

Another use case is to enable control of privately run = CAs.=A0

Management of those policies with OIDs or = paths is straightforward.=A0


Introd= ucing a string such a WhizzyCA is much more complex and would lead at least= one CA to have a major commercial problem as they don't own the princi= pal brand under which they trade.



On Fri, J= ul 8, 2011 at 10:15 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Jul 8, 2011, at 6:11 AM, Kemp, David P. wrote:

>
> From: Paul Hoffman
>>
>> On Jul 7, 2011, at 2:53 PM, Phillip Hallam-Baker wrote:
>>> I don't think strings work at all well.
>>
>> Strings as you portray them don't, particularly because
>> they miss the advantage of OID trees. However, a better
>> definition of strings might.
>>
>> I propose that the identifier be a free-text string.
>> If the string consists of only ASCII digits and ASCII
>> periods, it is considered a policy OID, and that OID
>> follows the rule that the policy property applies to
>> the specified policy OID and all policy OIDs that fall
>> within the same OID arc.
>>
>> Using strings this proposed way also gets rid of the
>> tortured ASN.1 OID encoding in the current draft.
>> Now, it's just plain text, easily typed by the DNS admin.
>>
>> Thoughts?
>>
>> --Paul Hoffman
>
>
> I think you meant the right thing but didn't say it clearly. =A0A = string
> encoding of an OID is fine, a free-text string is not. In order to avo= id
> the non-hierarchical and multi-variant nature of unconstrained strings=
> the rule should be:
>
> =A0 The string represents a policy OID and MUST consist of only
> =A0 ASCII digits and ASCII periods.


That was not my intended meaning: I really did mean "free text, = and if that free text has this property, it is treated as an OID".

Given that this is a voluntary protocol that is being run by CAs, false neg= atives (that is, a CAA record that has an unrecognized text string from a d= omain that actually wanted a cert from the CA doing the test) seems fairly = harmless. The fact that the CA can test the CAA record for a long period be= fore issuance is needed mitigates any problem even further.

Why do you feel that free text ("WhizzyCA", "WhizzyCA, Inc.&= quot;, "I want a WhizzyCA cert" ...) is not fine for this purpose= ?

--Paul Hoffman

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



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

--001636c5969cc32ccb04a78f9a9c-- From hallam@gmail.com Fri Jul 8 07:33:58 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2A821F8ABB for ; Fri, 8 Jul 2011 07:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=0.189, 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 mo3TfpsoO9zS for ; Fri, 8 Jul 2011 07:33:57 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 72B8821F8AAE for ; Fri, 8 Jul 2011 07:33:57 -0700 (PDT) Received: by gwb20 with SMTP id 20so951229gwb.31 for ; Fri, 08 Jul 2011 07:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=blfT0Q9NV2z3Dsrywu4me7M/ezzb/uxIPa9zmmw6nqQ=; b=C3YbJgJXHKUnlYSf7tkzN/vvEHFpuEOfwswRSI0HlhCsIAMtw8Ap9+8BFmLUbeqPa9 EpaebxZVpfqpl64Ctq8Pvd4SchP0YoI71PjrH77ZJh1iFo6E5f+rtvSTIB+rv7j64xQG k1F48FpJLAzqyJNVUAYOmZJRKrvNMqRTGuuhI= MIME-Version: 1.0 Received: by 10.101.168.5 with SMTP id v5mr1780358ano.14.1310135636832; Fri, 08 Jul 2011 07:33:56 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Fri, 8 Jul 2011 07:33:56 -0700 (PDT) In-Reply-To: <201107081424.p68EOnZv017935@fs4113.wdf.sap.corp> References: <201107081424.p68EOnZv017935@fs4113.wdf.sap.corp> Date: Fri, 8 Jul 2011 10:33:56 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016368e35a43db31504a78fb984 Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 14:33:58 -0000 --0016368e35a43db31504a78fb984 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 8, 2011 at 10:24 AM, Martin Rex wrote: > Phillip Hallam-Baker wrote: > > > > That risks getting into the problem that there are multiple > > encodings for OIDs. > > *cough* What?? > > I've seen quite a variety of bugs around ASN.1, > but "multiple encodings for OIDs" is something I have never heard of. > > I'm wondering: are printable string OIDs used in any SNMP-Tools? > > There is one ASN.1 BER encoding of an OID But there are multiple string encodings. You can add the text labels (as the ITU spec says) or not (as is IETF practice). That is why I was proposing to use the ASN.1 encoding. Writing the code to encode and decode the asn.1 was the least of the problems I had patching BIND. It is about 100 lines of C in total. -- Website: http://hallambaker.com/ --0016368e35a43db31504a78fb984 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 8, 2011 at 10:24 AM, Ma= rtin Rex <mrex@sap.com= > wrote:
Phillip Hallam-Baker wrote:
>
> That risks getting into the problem that there are multiple
> encodings for OIDs.

*cough* =A0What??

I've seen quite a variety of bugs around ASN.1,
but "multiple encodings for OIDs" is something I have never heard= of.

I'm wondering: are printable string OIDs used in any SNMP-Tools?


There is one ASN.1 BER encoding of an OID=A0

But there are multiple string encodings. You can add the text labels = (as the ITU spec says) or not (as is IETF practice).

That is why I was proposing to use the ASN.1 encoding.<= /div>


Writing the code to encode and deco= de the asn.1 was the least of the problems I had patching BIND. It is about= 100 lines of C in total.


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

--0016368e35a43db31504a78fb984-- From mrex@sap.com Fri Jul 8 07:37:37 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B12221F877B for ; Fri, 8 Jul 2011 07:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.209 X-Spam-Level: X-Spam-Status: No, score=-10.209 tagged_above=-999 required=5 tests=[AWL=0.040, 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 3KE9xBX9jVuW for ; Fri, 8 Jul 2011 07:37:36 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4808021F8906 for ; Fri, 8 Jul 2011 07:37:36 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p68EbYJ8023747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2011 16:37:34 +0200 (MEST) From: Martin Rex Message-Id: <201107081437.p68EbXrq018692@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Fri, 8 Jul 2011 16:37:33 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Jul 8, 11 10:25:25 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Policy OIDs in CAA 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, 08 Jul 2011 14:37:37 -0000 Phillip Hallam-Baker wrote: > > It requires a mapping to be defined from the string to the policy for a > start. CAs already have one such mapping, and once it is in productive use, it becomes quite difficult to change -- even if the CA wants to, it is the issuer name of the CA certificate. > > One of the use cases we have is that public CAs frequently run CAs for other > parties under different policies or under variants of policies. > > Another use case is to enable control of privately run CAs. > > Management of those policies with OIDs or paths is straightforward. No, it isn't. Currently you do _not_ have to obtain/register an OID arc to set up a private CA. Yes, you can get one for free form the IANA private enterprised registry, but IANA will not be happy if it will have to process half a million requests for such OIDs over the next couple of years, I assume. Getting an OID arc from your national ISO-Member is no alternative. 13 years ago, the german DIN-Certco wanted to _lease_ OID arcs for a yearly fee of around USD 6000,-... > > Introducing a string such a WhizzyCA is much more complex and would lead at > least one CA to have a major commercial problem as they don't own the > principal brand under which they trade. Every CA cert MUST write an issuer name into all certs they issue per rfc5280 (and likely some X.509 as well), so that the issue you are claiming can not possibly exist. -Martin From hallam@gmail.com Fri Jul 8 08:48:50 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FC121F8AC8 for ; Fri, 8 Jul 2011 08:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 5CvVVIy4mRxz for ; Fri, 8 Jul 2011 08:48:50 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCB4F21F8A94 for ; Fri, 8 Jul 2011 08:48:49 -0700 (PDT) Received: by gyd5 with SMTP id 5so981868gyd.31 for ; Fri, 08 Jul 2011 08:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C9uos5mh5D6NI8yNrJDpfiFCoHQGG2xkmVzSjmVvDJI=; b=LDwz/NTuRUPDlWr2SwPtgoPx9fDxFARon9Bdj7u7fqhafVitqF9X9qcZfdErgTTkMA JjKSUxqiSWayU5pBOd9DUVOZ3yYjyTKCstq89yoamTtGK4SvqX+y8NnsyKB0VDaPQ8GO 9KDaJpn2tX/4Ygh8+rIS4JXXf6/jg5FK0/gnw= MIME-Version: 1.0 Received: by 10.101.179.7 with SMTP id g7mr1858110anp.102.1310140128971; Fri, 08 Jul 2011 08:48:48 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Fri, 8 Jul 2011 08:48:48 -0700 (PDT) In-Reply-To: <201107081437.p68EbXrq018692@fs4113.wdf.sap.corp> References: <201107081437.p68EbXrq018692@fs4113.wdf.sap.corp> Date: Fri, 8 Jul 2011 11:48:48 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=001636c92664fe4aa404a790c471 Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 15:48:51 -0000 --001636c92664fe4aa404a790c471 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 8, 2011 at 10:37 AM, Martin Rex wrote: > Phillip Hallam-Baker wrote: > > > > It requires a mapping to be defined from the string to the policy for a > > start. > > CAs already have one such mapping, and once it is in productive use, > it becomes quite difficult to change -- even if the CA wants to, > it is the issuer name of the CA certificate Should Comodo be using Comodo CA or UserTrust? Should Symantec CA use Symantec, VeriSign or RSA Data Security? Successful technology companies have an average lifespan of 5-10 years (unsuccessful ones can have the same lifespan measured in months). Names change, ownership changes, roles change. The name that is in the root cert is frequently one that we would wish the user see as little as possible. We can define other strings but that then starts to make audit impossible. This is not an argument about human readability either. Until the DNS servers have support for the CAA record, users are going to be entering the RR as an unknown RR type which is going to be a string of hex digits. Does the string 'VeriSign' mean VeriSign Class 3 or VeriSign EV? The issuer name is the same in both cases. The industry already has a means to distinguish those cases, its the policy oid. I have no particular objection to adding an issuer property in addition. But I do not think any commercial CA is going to want to use it. > > One of the use cases we have is that public CAs frequently run CAs for > other > > parties under different policies or under variants of policies. > > > > Another use case is to enable control of privately run CAs. > > > > Management of those policies with OIDs or paths is straightforward. > > No, it isn't. Currently you do _not_ have to obtain/register an OID arc > to set up a private CA. Yes, you can get one for free form the > IANA private enterprised registry, but IANA will not be happy if > it will have to process half a million requests for such OIDs > over the next couple of years, I assume. > That is why we put the path property in as an alternative. The path property binds directly to a certificate on the cert path. In most private CA cases that is going to be the self-signed root. The advantage of that approach is that there is no ambiguity and no registration required. > Getting an OID arc from your national ISO-Member is no alternative. > 13 years ago, the german DIN-Certco wanted to _lease_ OID arcs for > a yearly fee of around USD 6000,-... I very much doubt that they persisted in that delusion. I don't see much value to having an OID there unless the CA in question is a public CA. An OID is only going to be useful if there is a CPS etc. For the type of use case you propose the path property is going to be much easier to use. A CA server that recognizes CAA is going to have a configuration tool that spits out the appropriate CAA record in both the canonical and unknown record formats. The use I would see for CAA in such a context would be to control the range of certificates that the server will issue for so that it cannot be used as an attack vector against other sites. Consider the case in which alice.edu has distributed its own private root to browsers across the campus. They want to make it as easy as possible for people to get certs. They don't want to allow people to register certs for store.alice.edu which accepts Visa and Mastercard payments. > Introducing a string such a WhizzyCA is much more complex and would lead > at > > least one CA to have a major commercial problem as they don't own the > > principal brand under which they trade. > > Every CA cert MUST write an issuer name into all certs they issue > per rfc5280 (and likely some X.509 as well), so that the issue > you are claiming can not possibly exist. No, that problem is addressed in existing contracts. Use of that name in the context of CAA can only be addressed in future contracts. --001636c92664fe4aa404a790c471 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On= Fri, Jul 8, 2011 at 10:37 AM, Martin Rex=A0<
Phillip Hallam-Baker wrote:
>
> It requires a mapping to b= e defined from the string to the policy for a
> start.

C= As already have one such mapping, and once it is in productive use,
it becomes quite difficult to change -- even if the CA wants to,
it is t= he issuer name of the CA certificate



The name that is in the root cert is frequently one tha= t we would wish the user see as little as possible.

We can define other strings but that then starts to make audit impossible= .


This is not an argument about human read= ability either. Until the DNS servers have support for the CAA record, user= s are going to be entering the RR as an unknown RR type which is going to b= e a string of hex digits.

Does the string 'VeriSign' mean VeriSign Class = 3 or VeriSign EV? The issuer name is the same in both cases. The industry a= lready has a means to distinguish those cases, its the policy oid.


I have no particular objection to adding= an issuer property in addition. But I do not think any commercial CA is go= ing to want to use it.

=A0
> One of the use cases we have is that public CAs frequently run CA= s for other
> parties under different policies or under variants of p= olicies.
>
> Another use case is to enable control of privately= run CAs.
>
> Management of those policies with OIDs or paths is straightfor= ward.

No, it isn't. =A0Currently you do _not_ have to obta= in/register an OID arc
to set up a private CA. =A0Yes, you can get one f= or free form the
IANA private enterprised registry, but IANA will not be happy if
it will= have to process half a million requests for such OIDs
over the next cou= ple of years, I assume.

That is w= hy we put the path property in as an alternative.

The path property binds directly to a certificate on th= e cert path. In most private CA cases that is going to be the self-signed r= oot.=A0

The advantage of that approach is that the= re is no ambiguity and no registration required.

=A0=
Getting an OID arc from your national ISO-Member is no alternative.
13 y= ears ago, the german DIN-Certco wanted to _lease_ OID arcs for
a yearly = fee of around USD 6000,-...

I very mu= ch doubt that they persisted in that delusion.

I don't see much value to having an OID there unles= s the CA in question is a public CA. An OID is only going to be useful if t= here is a CPS etc.=A0

For the type of use case you= propose the path property is going to be much easier to use.=A0

A CA server that recognizes CAA is going to have a conf= iguration tool that spits out the appropriate CAA record in both the canoni= cal and unknown record formats.


The use I would see for CAA in such a context would be to control the range= of certificates that the server will issue for so that it cannot be used a= s an attack vector against other sites.

Consider t= he case in which=A0alice.edu=A0has distributed its own private = root to browsers across the campus. They want to make it as easy as possibl= e for people to get certs. They don't want to allow people to register = certs for=A0store.alice.edu=A0which accepts Visa and Mast= ercard payments.=A0

> Introducing a string such a WhizzyCA is much more complex and wou= ld lead at
> least one CA to have a major commercial problem as they = don't own the
> principal brand under which they trade.

Every CA cert MUST write an issuer name into all certs they issue
= per rfc5280 (and likely some X.509 as well), so that the issue
you are c= laiming can not possibly exist.

No, t= hat problem is addressed in existing contracts.

Use of that name in the context of CAA can only be addr= essed in future contracts.
=A0

--001636c92664fe4aa404a790c471-- From mrex@sap.com Fri Jul 8 10:24:33 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F94021F8C30 for ; Fri, 8 Jul 2011 10:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.21 X-Spam-Level: X-Spam-Status: No, score=-10.21 tagged_above=-999 required=5 tests=[AWL=0.039, 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 coHI77mCsZ98 for ; Fri, 8 Jul 2011 10:24:32 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 772CF21F8C2D for ; Fri, 8 Jul 2011 10:24:32 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p68HOUqY019931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2011 19:24:30 +0200 (MEST) From: Martin Rex Message-Id: <201107081724.p68HOTlq028064@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Fri, 8 Jul 2011 19:24:29 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Jul 8, 11 11:48:29 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA 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, 08 Jul 2011 17:24:33 -0000 Phillip Hallam-Baker wrote: > > Martin Rex wrote: > > > Phillip Hallam-Baker wrote: > > > > > > It requires a mapping to be defined from the string to the policy for a > > > start. > > > > CAs already have one such mapping, and once it is in productive use, > > it becomes quite difficult to change -- even if the CA wants to, > > it is the issuer name of the CA certificate > > Should Comodo be using Comodo CA or UserTrust? > > Should Symantec CA use Symantec, VeriSign or RSA Data Security? > > Successful technology companies have an average lifespan of 5-10 years > (unsuccessful ones can have the same lifespan measured in months). Names > change, ownership changes, roles change. > > The name that is in the root cert is frequently one that we would wish the > user see as little as possible. I'm sorry. but I strongly disagree. It MUST remain possible to the admins and to the consumers to configure their trust anchors manually, and therefore the names in those certs WILL be inevitably visible to the users. Trying to refer to trust anchors with some weird policy IDs, potentially ones that are not even part of the CA certs contained in configurations of the installed base, seems like a bad idea and a very undesirable usability problem. I believe CAA ought to work with an existing attribute of the CA certs in the installed base that is prominently visible in trust anchors management UIs of the currently installed base. -Martin From hallam@gmail.com Fri Jul 8 10:29:30 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A480621F8B71 for ; Fri, 8 Jul 2011 10:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.035, 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 i-ydSNF0bC-J for ; Fri, 8 Jul 2011 10:29:29 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB34B21F8AE1 for ; Fri, 8 Jul 2011 10:29:29 -0700 (PDT) Received: by ywp31 with SMTP id 31so269358ywp.31 for ; Fri, 08 Jul 2011 10:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AMlLQlZN4JvJDoxB62QVMSqcXfS8rcYS+pLcApWSJt4=; b=UDsXqxcBpjb5+1Q3L2Yl3KbdrnxSJeu/RlRvuj2wlmRe9N7NphDBN2Bsb45h56jc1G KyUQtJDme3fSFHQWUkFOSLvkjn8+wJwWaMEGQisiZFo8Yi9rvd2RQjDHIfxihTCrfGed G2PY00SUWJPVsXLSRwn9cMwTrRyve1AGt30cs= MIME-Version: 1.0 Received: by 10.101.145.12 with SMTP id x12mr5825ann.168.1310146118691; Fri, 08 Jul 2011 10:28:38 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Fri, 8 Jul 2011 10:28:38 -0700 (PDT) In-Reply-To: <201107081724.p68HOTlq028064@fs4113.wdf.sap.corp> References: <201107081724.p68HOTlq028064@fs4113.wdf.sap.corp> Date: Fri, 8 Jul 2011 13:28:38 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016e68fd02b022b9304a7922a72 Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 17:29:30 -0000 --0016e68fd02b022b9304a7922a72 Content-Type: text/plain; charset=ISO-8859-1 Policy OIDs are an existing cert attribute that is visible in the UI. We can add an issuer property if you think it is going to be helpful. On Fri, Jul 8, 2011 at 1:24 PM, Martin Rex wrote: > Phillip Hallam-Baker wrote: > > > > Martin Rex wrote: > > > > > Phillip Hallam-Baker wrote: > > > > > > > > It requires a mapping to be defined from the string to the policy for > a > > > > start. > > > > > > CAs already have one such mapping, and once it is in productive use, > > > it becomes quite difficult to change -- even if the CA wants to, > > > it is the issuer name of the CA certificate > > > > Should Comodo be using Comodo CA or UserTrust? > > > > Should Symantec CA use Symantec, VeriSign or RSA Data Security? > > > > Successful technology companies have an average lifespan of 5-10 years > > (unsuccessful ones can have the same lifespan measured in months). Names > > change, ownership changes, roles change. > > > > The name that is in the root cert is frequently one that we would wish > the > > user see as little as possible. > > > I'm sorry. but I strongly disagree. > > It MUST remain possible to the admins and to the consumers to > configure their trust anchors manually, and therefore the names > in those certs WILL be inevitably visible to the users. > > Trying to refer to trust anchors with some weird policy IDs, > potentially ones that are not even part of the CA certs > contained in configurations of the installed base, seems like > a bad idea and a very undesirable usability problem. > > I believe CAA ought to work with an existing attribute of the > CA certs in the installed base that is prominently visible > in trust anchors management UIs of the currently installed base. > > > -Martin > -- Website: http://hallambaker.com/ --0016e68fd02b022b9304a7922a72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Policy OIDs are an existing cert attribute that is visible in the UI.
<= br>
We can add an issuer property if you think it is going to be = helpful.


On Fri, Jul 8, 2011 a= t 1:24 PM, Martin Rex <mrex@sap.com> wrote:
Phillip Hallam-Baker wrot= e:
>
> Martin Rex <mrex@sap.com> wr= ote:
>
> > Phillip Hallam-Baker wrote:
> > >
> > > It requires a mapping to be defined from the string to the p= olicy for a
> > > start.
> >
> > CAs already have one such mapping, and once it is in productive u= se,
> > it becomes quite difficult to change -- even if the CA wants to,<= br> > > it is the issuer name of the CA certificate
>
> Should Comodo be using Comodo CA or UserTrust?
>
> Should Symantec CA use Symantec, VeriSign or RSA Data Security?
>
> Successful technology companies have an average lifespan of 5-10 years=
> (unsuccessful ones can have the same lifespan measured in months). Nam= es
> change, ownership changes, roles change.
>
> The name that is in the root cert is frequently one that we would wish= the
> user see as little as possible.


I'm sorry. but I strongly disagree.

It MUST remain possible to the admins and to the consumers to
configure their trust anchors manually, and therefore the names
in those certs WILL be inevitably visible to the users.

Trying to refer to trust anchors with some weird policy IDs,
potentially ones that are not even part of the CA certs
contained in configurations of the installed base, seems like
a bad idea and a very undesirable usability problem.

I believe CAA ought to work with an existing attribute of the
CA certs in the installed base that is prominently visible
in trust anchors management UIs of the currently installed base.


-Martin



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

--0016e68fd02b022b9304a7922a72-- From mrex@sap.com Fri Jul 8 11:25:53 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C655A21F8B30 for ; Fri, 8 Jul 2011 11:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.212 X-Spam-Level: X-Spam-Status: No, score=-10.212 tagged_above=-999 required=5 tests=[AWL=0.037, 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 89Z9ozE6Fu4A for ; Fri, 8 Jul 2011 11:25:52 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4C97B21F8AAA for ; Fri, 8 Jul 2011 11:25:52 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p68IPoMa026111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2011 20:25:50 +0200 (MEST) From: Martin Rex Message-Id: <201107081825.p68IPn75001590@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Fri, 8 Jul 2011 20:25:49 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Jul 8, 11 01:28:38 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA 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, 08 Jul 2011 18:25:53 -0000 Phillip Hallam-Baker wrote: > > Policy OIDs are an existing cert attribute that is visible in the UI. > > We can add an issuer property if you think it is going to be helpful. Let's see: https://www.comodo.com/ Firefox 3.5: TA: AddTrust External CA Root _NO_ policy \____ COMODO Certification Autority 2.5.29.32.anyPolicy(0) \____ COMODO Extended Validation Secure Server CA 2.5.29.32.anyPolicy(0) \___ www.comodo.com 1.3.6.1.4.1.6449.1.2.1.5.1 Firefox 3.6: TA: COMODO Certification Autority _NO_ policy \___ COMODO Extended Validation Secure Server CA 2.5.29.32.anyPolicy(0) \___ www.comodo.com 1.3.6.1.4.1.6449.1.2.1.5.1 I somehow fail to see any policy OIDs in any of Comodo's CA certs that could be used to identify these certs as issuers through CAA. CAA is something between the DNS Admin and the CA, and I had assumed you wanted it to become usable _soon_. So you ought to try something that works well with the existing UIs and the existing CA certs. -Martin From hallam@gmail.com Fri Jul 8 11:53:38 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DB421F8614 for ; Fri, 8 Jul 2011 11:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.162, 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 N7URBdvijG5Q for ; Fri, 8 Jul 2011 11:53:37 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C16321F85C6 for ; Fri, 8 Jul 2011 11:53:37 -0700 (PDT) Received: by gwb20 with SMTP id 20so1065048gwb.31 for ; Fri, 08 Jul 2011 11:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TDmRY/FkhyBUwmGAfhk5YfY8hI79NIF9IBFQO2FQl78=; b=cnje8uF+vVOoswVwZi91DH/Sr7fKFo0ijW2R09jXh1SRvHxY9kYrZ6K/BEjVduqi9j zFIaazU/deTZbmpGKBadi6xpdnXvuVtWMsfnvYqy2dSMn8HmyqqjzVoh2zyeD4DUqZMo L26rsmUth6hqS5tXzy/oel/5j9VVtT8x9SadI= MIME-Version: 1.0 Received: by 10.101.179.7 with SMTP id g7mr2044372anp.102.1310151215509; Fri, 08 Jul 2011 11:53:35 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Fri, 8 Jul 2011 11:53:35 -0700 (PDT) In-Reply-To: <201107081825.p68IPn75001590@fs4113.wdf.sap.corp> References: <201107081825.p68IPn75001590@fs4113.wdf.sap.corp> Date: Fri, 8 Jul 2011 14:53:35 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=001636c92664cd701b04a793593e Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 18:53:38 -0000 --001636c92664cd701b04a793593e Content-Type: text/plain; charset=ISO-8859-1 Whats wrong with 1.3.6.1.4.1.6449.1.2.1.5.1 ? On Fri, Jul 8, 2011 at 2:25 PM, Martin Rex wrote: > Phillip Hallam-Baker wrote: > > > > Policy OIDs are an existing cert attribute that is visible in the UI. > > > > We can add an issuer property if you think it is going to be helpful. > > Let's see: https://www.comodo.com/ > > Firefox 3.5: > TA: AddTrust External CA Root _NO_ policy > \____ COMODO Certification Autority 2.5.29.32.anyPolicy(0) > \____ COMODO Extended Validation Secure Server CA > 2.5.29.32.anyPolicy(0) > \___ www.comodo.com 1.3.6.1.4.1.6449.1.2.1.5.1 > > Firefox 3.6: > TA: COMODO Certification Autority _NO_ policy > \___ COMODO Extended Validation Secure Server CA 2.5.29.32.anyPolicy(0) > \___ www.comodo.com 1.3.6.1.4.1.6449.1.2.1.5.1 > > I somehow fail to see any policy OIDs in any of Comodo's CA certs that > could be used to identify these certs as issuers through CAA. > > > CAA is something between the DNS Admin and the CA, and I had assumed > you wanted it to become usable _soon_. So you ought to try something > that works well with the existing UIs and the existing CA certs. > > > -Martin > > -- Website: http://hallambaker.com/ --001636c92664cd701b04a793593e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Whats wrong with=A01.3.6.1.4.1.6449.1.2.1.5.1 ?


On Fri, Jul 8, 2011= at 2:25 PM, Martin Rex <mrex@sap.com> wrote:
Phillip Hallam-Baker wrote:
>
> Policy OIDs are an existing cert attribute that is visible in the UI.<= br> >
> We can add an issuer property if you think it is going to be helpful.<= br>
Let's see: =A0https://www.comodo.com/

Firefox 3.5:
=A0TA: AddTrust External CA Root =A0 _NO_ policy
=A0 =A0\____ =A0COMODO Certification Autority =A0 2.5.29.32.anyPolicy(0) =A0 =A0 \____ COMODO Extended Validation Secure Server CA =A02.5.29.32.any= Policy(0)
=A0 =A0 =A0\___ www.co= modo.com =A0 =A0 1.3.6.1.4.1.6449.1.2.1.5.1

Firefox 3.6:
=A0TA: COMODO Certification Autority =A0 =A0_NO_ policy
=A0 =A0\___ COMODO Extended Validation Secure Server CA =A02.5.29.32.anyPo= licy(0)
=A0 =A0 \___ www.comod= o.com =A0 =A0 1.3.6.1.4.1.6449.1.2.1.5.1

I somehow fail to see any policy OIDs in any of Comodo's CA certs that<= br> could be used to identify these certs as issuers through CAA.


CAA is something between the DNS Admin and the CA, and I had assumed
you wanted it to become usable _soon_. =A0So you ought to try something
that works well with the existing UIs and the existing CA certs.


-Martin




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

--001636c92664cd701b04a793593e-- From paul.hoffman@vpnc.org Fri Jul 8 13:23:10 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E9521F8C7B for ; Fri, 8 Jul 2011 13:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.72 X-Spam-Level: X-Spam-Status: No, score=-102.72 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iW8OyUiFTUN for ; Fri, 8 Jul 2011 13:23:09 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0C00E21F85A9 for ; Fri, 8 Jul 2011 13:23:08 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p68KMuOs065020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Jul 2011 13:22:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 8 Jul 2011 13:23:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 20:23:10 -0000 On Jul 8, 2011, at 7:15 AM, Phillip Hallam-Baker wrote: > That risks getting into the problem that there are multiple encodings = for OIDs. Not really. Remember, it is the CA's software that is interpreting the = information in the CAA record. The CA's software can be made to be = flexible about what it recognizes as its own OID. On Jul 8, 2011, at 7:25 AM, Phillip Hallam-Baker wrote: > No, I think that is broken. >=20 > It requires a mapping to be defined from the string to the policy for = a start.=20 And what is the problem with that? Any CA can write software that makes = such a mapping. > One of the use cases we have is that public CAs frequently run CAs for = other parties under different policies or under variants of policies. Indeed. Why is that a problem? The master CA simply needs to recognize a = larger number of strings. Adding strings to the checking program will = take less tim than it will for you to respond to this message. > Another use case is to enable control of privately run CAs.=20 Absolutely. And that has the same answer. > Management of those policies with OIDs or paths is straightforward.=20 Fully agree. That's why I had a single, unambiguous rule for recognizing = an OID in the string. > Introducing a string such a WhizzyCA is much more complex and would = lead at least one CA to have a major commercial problem as they don't = own the principal brand under which they trade. Huh? What on earth does "owning" a name have to do with the ability to = see it in a string? On Jul 8, 2011, at 8:48 AM, Phillip Hallam-Baker wrote: > CAs already have one such mapping, and once it is in productive use, > it becomes quite difficult to change -- even if the CA wants to, > it is the issuer name of the CA certificate True, and irrelevant to matching one or more strings to a received CAA = record. > Should Comodo be using Comodo CA or UserTrust? Either is fine. > Should Symantec CA use Symantec, VeriSign or RSA Data Security? Any of the three is fine. > Successful technology companies have an average lifespan of 5-10 years = (unsuccessful ones can have the same lifespan measured in months). Names = change, ownership changes, roles change. >=20 > The name that is in the root cert is frequently one that we would wish = the user see as little as possible. >=20 > We can define other strings but that then starts to make audit = impossible. If I were auditing Symantec's logs, and I saw instances where they = issued certificates after seeing CAA records for "Symantec", "VeriSign", = "RSA Data Security", "Symanteck", and so on, I would know what they used = to accept certificates. I could simply ask them to justify each string. = If I saw a CAA record for "Comodo", their justification for that might = be a tad more difficult to swallow. > This is not an argument about human readability either. Until the DNS = servers have support for the CAA record, users are going to be entering = the RR as an unknown RR type which is going to be a string of hex = digits. And the moment it is supported, that argument becomes bunk. > Does the string 'VeriSign' mean VeriSign Class 3 or VeriSign EV? The = issuer name is the same in both cases. The industry already has a means = to distinguish those cases, its the policy oid. True, and irrelevant. If Symantec issues a cert under either name, it is = not a problem. > I have no particular objection to adding an issuer property in = addition. But I do not think any commercial CA is going to want to use = it. Fine: they don't have to. --Paul Hoffman From hallam@gmail.com Fri Jul 8 13:34:11 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E426621F8CFA for ; Fri, 8 Jul 2011 13:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.032, 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 CVjb6o+xrMTg for ; Fri, 8 Jul 2011 13:34:07 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6411C21F8B45 for ; Fri, 8 Jul 2011 13:34:07 -0700 (PDT) Received: by ywp31 with SMTP id 31so342379ywp.31 for ; Fri, 08 Jul 2011 13:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XNjzN4Y/yBxwg/IHHT5wHKRekHvCveqBgkx87hDD8uA=; b=KrE7dHf9R5C7h6tY7vUwQi+AM6dUOmV91iu6F5by/QmjtLA4cGN7WrLBd63b5iBLi/ Gh+RKSsC4U1nxH1Y/X1zBRPSi5xBObgzG2Rql4XI2P834FawogN7U47G5QGU/UpqA9eq Y41GRA1Qhe/9Q7U+JVPUFefuaxov+0teMXAKk= MIME-Version: 1.0 Received: by 10.101.168.5 with SMTP id v5mr2128194ano.14.1310157245730; Fri, 08 Jul 2011 13:34:05 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Fri, 8 Jul 2011 13:34:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jul 2011 16:34:05 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016368e35a43b4f2004a794c1d4 Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 20:34:12 -0000 --0016368e35a43b4f2004a794c1d4 Content-Type: text/plain; charset=ISO-8859-1 > > > If I were auditing Symantec's logs, and I saw instances where they issued > certificates after seeing CAA records for "Symantec", "VeriSign", "RSA Data > Security", "Symanteck", and so on, I would know what they used to accept > certificates. I could simply ask them to justify each string. If I saw a CAA > record for "Comodo", their justification for that might be a tad more > difficult to swallow. So in short you want to turn my scheme which is deterministic into your proposal that involves human interpretations and heuristics. OK, I will put it in the draft as an option. -- Website: http://hallambaker.com/ --0016368e35a43b4f2004a794c1d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

If I were auditing Symantec's logs, and I saw instances where the= y issued certificates after seeing CAA records for "Symantec", &q= uot;VeriSign", "RSA Data Security", "Symanteck", a= nd so on, I would know what they used to accept certificates. I could simpl= y ask them to justify each string. If I saw a CAA record for "Comodo&q= uot;, their justification for that might be a tad more difficult to swallow= .

So in short you want to turn my scheme which is determi= nistic into your proposal that involves human interpretations and heuristic= s.

OK, I will put it in the draft as an option. = =A0

--
Website: http://hallam= baker.com/

--0016368e35a43b4f2004a794c1d4-- From paul.hoffman@vpnc.org Fri Jul 8 13:39:51 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D5E21F8CD6 for ; Fri, 8 Jul 2011 13:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.717 X-Spam-Level: X-Spam-Status: No, score=-102.717 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5+hX910-NcG for ; Fri, 8 Jul 2011 13:39:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B226221F8CAF for ; Fri, 8 Jul 2011 13:39:50 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p68KdcZW065708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Jul 2011 13:39:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 8 Jul 2011 13:39:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 20:39:51 -0000 On Jul 8, 2011, at 1:34 PM, Phillip Hallam-Baker wrote: >=20 > If I were auditing Symantec's logs, and I saw instances where they = issued certificates after seeing CAA records for "Symantec", "VeriSign", = "RSA Data Security", "Symanteck", and so on, I would know what they used = to accept certificates. I could simply ask them to justify each string. = If I saw a CAA record for "Comodo", their justification for that might = be a tad more difficult to swallow. >=20 > So in short you want to turn my scheme which is deterministic into = your proposal that involves human interpretations and heuristics. Correct. That is the same as Stephen Farrell proposed as well. > OK, I will put it in the draft as an option. =20 Thanks, but I was proposing that you replace your current complicated = deterministic requirements with a simple string. A CA who only wants to = accept a single deterministic string (the OID, encoded as ASCII digits = and ASCII periods and nothing else) is free to do so. Such a change would greatly shorten and simplify the protocol. --Paul Hoffman From mrex@sap.com Fri Jul 8 15:14:14 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7051721F8C4C for ; Fri, 8 Jul 2011 15:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.063 X-Spam-Level: X-Spam-Status: No, score=-9.063 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_SIZE=2.3, 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 vaIMi6fMByAU for ; Fri, 8 Jul 2011 15:14:13 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6E621F8C4A for ; Fri, 8 Jul 2011 15:14:13 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p68MEAYd010570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Jul 2011 00:14:10 +0200 (MEST) From: Martin Rex Message-Id: <201107082214.p68ME9OV015584@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Sat, 9 Jul 2011 00:14:09 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Jul 8, 11 02:53:35 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA 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, 08 Jul 2011 22:14:14 -0000 Phillip Hallam-Baker wrote: > > Whats wrong with 1.3.6.1.4.1.6449.1.2.1.5.1 ? I does not appear in any of the Comodo CA certificates. The most logical and most usable choice for the DNS admin would be an **existing** attribute of any CA certificate along the path to the trust anchor. So that when I want to configure a TLS client to be able to authenticate servers in that domain, I can easily determine the CA certificate(s) that I need to add to my trust anchor store. -Martin > On Fri, Jul 8, 2011 at 2:25 PM, Martin Rex wrote: > > > Phillip Hallam-Baker wrote: > > > > > > Policy OIDs are an existing cert attribute that is visible in the UI. > > > > > > We can add an issuer property if you think it is going to be helpful. > > > > Let's see: https://www.comodo.com/ > > > > Firefox 3.5: > > TA: AddTrust External CA Root _NO_ policy > > \____ COMODO Certification Autority 2.5.29.32.anyPolicy(0) > > \____ COMODO Extended Validation Secure Server CA > > 2.5.29.32.anyPolicy(0) > > \___ www.comodo.com 1.3.6.1.4.1.6449.1.2.1.5.1 > > > > Firefox 3.6: > > TA: COMODO Certification Autority _NO_ policy > > \___ COMODO Extended Validation Secure Server CA 2.5.29.32.anyPolicy(0) > > \___ www.comodo.com 1.3.6.1.4.1.6449.1.2.1.5.1 > > > > I somehow fail to see any policy OIDs in any of Comodo's CA certs that > > could be used to identify these certs as issuers through CAA. > > > > > > CAA is something between the DNS Admin and the CA, and I had assumed > > you wanted it to become usable _soon_. So you ought to try something > > that works well with the existing UIs and the existing CA certs. > > > > > > -Martin > > > > > > > -- > Website: http://hallambaker.com/ > > --001636c92664cd701b04a793593e > Content-Type: text/html; charset="ISO-8859-1" > Content-Transfer-Encoding: quoted-printable > > Whats wrong with=A0 e: collapse; color: rgb(51, 51, 51); font-family: arial, sans-serif; font-s= > ize: 16px; ">1.3.6.1.4.1.6449.1.2.1.5.1 ?
tyle-span" color=3D"#333333" face=3D"arial, sans-serif"> e-style-span" style=3D"border-collapse: collapse; font-size: 16px;">
>

On Fri, Jul 8, 2011= > at 2:25 PM, Martin Rex < m">mrex@sap.com> wrote:
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> >
Phillip Hallam-Baker wrote:
> >
> > Policy OIDs are an existing cert attribute that is visible in the UI.<= > br> > >
> > We can add an issuer property if you think it is going to be helpful.<= > br> >
>
Let's see: =A0 k">https://www.comodo.com/
>
> Firefox 3.5:
> =A0TA: AddTrust External CA Root =A0 _NO_ policy
> =A0 =A0\____ =A0COMODO Certification Autority =A0 2.5.29.32.anyPolicy(0) r> > =A0 =A0 \____ COMODO Extended Validation Secure Server CA =A02.5.29.32.any= > Policy(0)
> =A0 =A0 =A0\___ www.co= > modo.com =A0 =A0 1.3.6.1.4.1.6449.1.2.1.5.1
>
> Firefox 3.6:
> =A0TA: COMODO Certification Autority =A0 =A0_NO_ policy
> =A0 =A0\___ COMODO Extended Validation Secure Server CA =A02.5.29.32.anyPo= > licy(0)
> =A0 =A0 \___ www.comod= > o.com =A0 =A0 1.3.6.1.4.1.6449.1.2.1.5.1
>
> I somehow fail to see any policy OIDs in any of Comodo's CA certs that<= > br> > could be used to identify these certs as issuers through CAA.
>
>
> CAA is something between the DNS Admin and the CA, and I had assumed
> you wanted it to become usable _soon_. =A0So you ought to try something
> that works well with the existing UIs and the existing CA certs.
>
>
> -Martin
>
>



--
Website: =3D"http://hallambaker.com/">http://hallambaker.com/

>
> > --001636c92664cd701b04a793593e-- > From hallam@gmail.com Fri Jul 8 15:37:49 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5319B21F8631 for ; Fri, 8 Jul 2011 15:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.142, 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 FOiguZUKx2ug for ; Fri, 8 Jul 2011 15:37:48 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7067521F85FD for ; Fri, 8 Jul 2011 15:37:48 -0700 (PDT) Received: by gwb20 with SMTP id 20so1138691gwb.31 for ; Fri, 08 Jul 2011 15:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rS1KCTPrilG6nZ3wm1vcCPLhGy3brrcpt9INxHRzpLE=; b=Z3bux/BdL1J7+UV6XSH3iwjB5L1bvmge0hh2xLyG4TPv5hGx0WvHbTBkIzEP9LLwHn s9C7EfQ5YThDWi+7XWvXv8WfYPpb67rNP+b9/534WAETnjtLuM34TggKddwFiGS4iYd2 5xCBtFJLy+jvRWf2CLBFh7CfKdZ/ac2tGy0AQ= MIME-Version: 1.0 Received: by 10.101.145.12 with SMTP id x12mr230191ann.168.1310164667831; Fri, 08 Jul 2011 15:37:47 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Fri, 8 Jul 2011 15:37:47 -0700 (PDT) In-Reply-To: <201107082214.p68ME9OV015584@fs4113.wdf.sap.corp> References: <201107082214.p68ME9OV015584@fs4113.wdf.sap.corp> Date: Fri, 8 Jul 2011 18:37:47 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016e68fd02b9f962904a7967be1 Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 22:37:49 -0000 --0016e68fd02b9f962904a7967be1 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 8, 2011 at 6:14 PM, Martin Rex wrote: > Phillip Hallam-Baker wrote: > > > > Whats wrong with 1.3.6.1.4.1.6449.1.2.1.5.1 ? > > I does not appear in any of the Comodo CA certificates > It does not have to, that is how X.509 works. The CA specifies the end entity certificate policy in the end entity certificate. That is how it has always worked. > The most logical and most usable choice for the DNS admin would be an > **existing** attribute of any CA certificate along the path to the > trust anchor. > No, I think it would be a string proposed by the CA on their Web site. -- Website: http://hallambaker.com/ --0016e68fd02b9f962904a7967be1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jul 8, 2011 at 6:14 PM, Martin Rex <mrex@sap.com> wrote:
Phillip Hallam-Baker wrote:
>
> Whats wrong with 1.3.6.1.4.1.6449.1.2.1.5.1 ?

I does not appear in any of the Comodo CA certificates

It does not have to, that is how X.509 works.

The CA specifies the end entity certificate policy in the= end entity certificate. That is how it has always worked.


=A0
The most logical and most usable choice for the DNS admin would be an
**existing** attribute of any CA certificate along the path to the
trust anchor.

No, I think it would be a= string proposed by the CA on their Web site.


=
--
Website: http://hall= ambaker.com/

--0016e68fd02b9f962904a7967be1-- From pgut001@login01.cs.auckland.ac.nz Fri Jul 8 22:43:29 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7E721F8776 for ; Fri, 8 Jul 2011 22:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHbUN53FIiUl for ; Fri, 8 Jul 2011 22:43:28 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8726E21F8773 for ; Fri, 8 Jul 2011 22:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1310190208; x=1341726208; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20hallam@gmail.com,=20mrex@sap.com|Subject:=20Re:=20 [pkix]=20Policy=20OIDs=20in=20CAA|Cc:=20pkix@ietf.org |In-Reply-To:=20|Message-Id:=20|Date:=20Sat,=2009=20Jul =202011=2017:43:17=20+1200; bh=IrkiM5ATxxEYWf1Mdugi4Z2Ugwm5SDSCc+sSPqtXmq8=; b=sUm1q2kb/qGav87FbdDjr/zpABQPsXcMNqIOuqtsNMafCQPksmyciMMZ IVXy5Tr+VD/nS4XylhqpTnBKTVjyx/qMc0s66if5jOELpAdrwLCieCNeB /fl1z79MiZUx4NKJT3y1HITiDx58zc4PNqaBYgcuQ3EbIC9DsiuUSn+Vn Y=; X-IronPort-AV: E=Sophos;i="4.65,502,1304251200"; d="scan'208";a="70918278" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Jul 2011 17:43:17 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QfQJx-0005oV-GO; Sat, 09 Jul 2011 17:43:17 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QfQJx-0004rm-1T; Sat, 09 Jul 2011 17:43:17 +1200 From: Peter Gutmann To: hallam@gmail.com, mrex@sap.com In-Reply-To: Message-Id: Date: Sat, 09 Jul 2011 17:43:17 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 05:43:29 -0000 Phillip Hallam-Baker writes: >Whats wrong with 1.3.6.1.4.1.6449.1.2.1.5.1 ? Nothing wrong with it, but what is it? So many of Comodo's OIDs are undocumented (or at least not documented anywhere that Google can find them) that they're essentially useless in telling you anything about the cert they're in. (This isn't just a Comodo problem, it exists across all CAs, which is why I've made this a public reply). Peter. From ynir@checkpoint.com Fri Jul 8 23:23:21 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EC221F8653 for ; Fri, 8 Jul 2011 23:23:21 -0700 (PDT) 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 9NE3OlaPXWUK for ; Fri, 8 Jul 2011 23:23:20 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF4E21F8652 for ; Fri, 8 Jul 2011 23:23:19 -0700 (PDT) X-CheckPoint: {4E180192-3-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p696N0nK020515; Sat, 9 Jul 2011 09:23:00 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sat, 9 Jul 2011 09:23:00 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 9 Jul 2011 09:23:00 +0300 From: Yoav Nir To: Peter Gutmann Date: Sat, 9 Jul 2011 09:22:58 +0300 Thread-Topic: [pkix] Policy OIDs in CAA Thread-Index: Acw+AKYqh//ByATYRL6zdQDsXQRDFQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 06:23:21 -0000 On Jul 9, 2011, at 8:43 AM, Peter Gutmann wrote: > Phillip Hallam-Baker writes: >=20 >> Whats wrong with 1.3.6.1.4.1.6449.1.2.1.5.1 ? >=20 > Nothing wrong with it, but what is it? So many of Comodo's OIDs are > undocumented (or at least not documented anywhere that Google can find th= em) > that they're essentially useless in telling you anything about the cert > they're in. >=20 > (This isn't just a Comodo problem, it exists across all CAs, which is why= I've > made this a public reply). To use this in CAA, a domain owner would have to know in advance what OID t= he CA was going to stick in the certificate. Is this public knowledge? From pgut001@login01.cs.auckland.ac.nz Sat Jul 9 01:09:35 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FC621F861C for ; Sat, 9 Jul 2011 01:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+FagvrWD7oq for ; Sat, 9 Jul 2011 01:09:35 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id E5A1621F861B for ; Sat, 9 Jul 2011 01:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1310198975; x=1341734975; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pgut001@cs.auckland.ac.nz,=20ynir@checkpoint.com |Subject:=20Re:=20[pkix]=20Policy=20OIDs=20in=20CAA|Cc: =20hallam@gmail.com,=20mozilla-dev-security-policy@lists. mozilla.org,=0D=0A=20=20=20=20mrex@sap.com,=20pkix@ietf.o rg|In-Reply-To:=20|Message-Id:=20|Date:=20Sat,=2009=20Jul=202011=2020:09 :32=20+1200; bh=qmSN/JcoSU/BMYYCVOanpqm+oGcnvgZ9oTRvpUWRFWI=; b=QIsFpZC/TlDs13Aalmy++lFgaZPcJZS2yR9CLkNVr6U5fjzl0yKJkKEP GsNpramEN3THns2j8cZH/aqxer9Uo3SrfUb5Li/+Z0LICHq+0rMo0wI32 XKXcJcX6yolQ86runUMe6ATtYG+s02rakKdj+dXMjApxDC6+PtkEU/j9F 8=; X-IronPort-AV: E=Sophos;i="4.65,503,1304251200"; d="scan'208";a="70923474" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Jul 2011 20:09:33 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QfSbU-0001E4-Iu; Sat, 09 Jul 2011 20:09:32 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QfSbU-0003lL-Qc; Sat, 09 Jul 2011 20:09:32 +1200 From: Peter Gutmann To: pgut001@cs.auckland.ac.nz, ynir@checkpoint.com In-Reply-To: Message-Id: Date: Sat, 09 Jul 2011 20:09:32 +1200 Cc: mozilla-dev-security-policy@lists.mozilla.org, pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 08:09:35 -0000 Yoav Nir writes: >To use this in CAA, a domain owner would have to know in advance what OID the >CA was going to stick in the certificate. Is this public knowledge? Nope, and the problem of completely undocumented policy OIDs that RPs are supposed to use to make decisions is systemic throughout CA-issued certs. (CC'd to the Mozilla policy list, which is probably a better place for this. There should be a requirement that CAs accepted by Mozilla and other browsers publicly document all OIDs they use in certs in an easily-accessible manner, either via a central registry administered by Mozilla or a flat text file or web page on the CA site). Peter. From hallam@gmail.com Sat Jul 9 09:48:46 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E8421F8838 for ; Sat, 9 Jul 2011 09:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.031, 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 mZJEbLFCYFFh for ; Sat, 9 Jul 2011 09:48:45 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 668C421F8837 for ; Sat, 9 Jul 2011 09:48:45 -0700 (PDT) Received: by ywp31 with SMTP id 31so562307ywp.31 for ; Sat, 09 Jul 2011 09:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aciB9XcHFhw/+GI11bHCNkEdZ82Ly4/tH8bOkS/tQJE=; b=k3ZYqJzyJMe5FPD6Y+/uu+odw9TIK1gUZ4nvM7dXIVLjatAPAPIvoyhbss+U3LlXmC VQdwH9vBo5AgR+UDKkEEx3YEd7HZoWYBz84BQ3PUsiJyTKIh/pCTXkafuywUcnweiEnP rcPplA7DLKM3MEGeJXthaxM6QUa0MXXok98i0= MIME-Version: 1.0 Received: by 10.101.168.5 with SMTP id v5mr2627098ano.14.1310230124926; Sat, 09 Jul 2011 09:48:44 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Sat, 9 Jul 2011 09:48:44 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Jul 2011 12:48:44 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=0016368e35a42b966904a7a5b991 Cc: mozilla-dev-security-policy@lists.mozilla.org, pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 16:48:46 -0000 --0016368e35a42b966904a7a5b991 Content-Type: text/plain; charset=ISO-8859-1 The CA is going to have to direct the user s to what information to put in the record anyway. And the user is not going to know what their cert chain looks like before the cert is issued. The criteria I see for the format of the CAA parameter value (in order of importance) are 1) Unambiguity: Can there be a dispute as to the right of the CA to issue under the parameter value. 2) Granularity: Can a the domain owner specify the issue constraints with precision, e.g. Alice CA EV only 3) Stability: Does the parameter value need to be updated in response to changes at the CA 4) Obtainability: Is it easy to obtain the necessary code points? 5) Readability: Is it easy for a human reader to interpret the data without recourse to external data sources? The scores I have are Policy: Meets all except 5 Path: Meets all except 3, 5 Issuer: Meets 4, 5 Path is interesting in that it breaks in a particular circumstance where people might want it to break. On Sat, Jul 9, 2011 at 4:09 AM, Peter Gutmann wrote: > Yoav Nir writes: > > >To use this in CAA, a domain owner would have to know in advance what OID > the > >CA was going to stick in the certificate. Is this public knowledge? > > Nope, and the problem of completely undocumented policy OIDs that RPs are > supposed to use to make decisions is systemic throughout CA-issued certs. > > (CC'd to the Mozilla policy list, which is probably a better place for > this. > There should be a requirement that CAs accepted by Mozilla and other > browsers > publicly document all OIDs they use in certs in an easily-accessible > manner, > either via a central registry administered by Mozilla or a flat text file > or > web page on the CA site). > > Peter. > > -- Website: http://hallambaker.com/ --0016368e35a42b966904a7a5b991 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The CA is going to have to direct the user s to what information to put in = the record anyway.

And the user is not going to know wha= t their cert chain looks like before the cert is issued.=A0

The criteria I see for the format of the CAA parameter value (in= order of importance) are


1) Unambi= guity: Can there be a dispute as to the right of the CA to issue under the = parameter value.

2) Granularity: Can a the domain owner specify the issu= e constraints with precision, e.g. Alice CA EV only

3) Stability: Does the parameter value need to be updated in response to = changes at the CA

4) Obtainability: Is it easy to obtain the necessary co= de points?

5) Readability: Is it easy for a human = reader to interpret the data without recourse to external data sources?


The scores I have are

Policy: Meets all except 5
Path: Meets all except 3, 5
Issuer: Meets 4, 5

Path is interesting in t= hat it breaks in a particular circumstance where people might want it to br= eak.=A0


On Sat, Jul 9, 2011 at 4:09 AM, Pet= er Gutmann <pgut001@cs.auckland.ac.nz> wrote:
Yoav Nir <ynir@= checkpoint.com> writes:

>To use this in CAA, a domain owner would have to know in advance what O= ID the
>CA was going to stick in the certificate. Is this public knowledge?

Nope, and the problem of completely undocumented policy OIDs that RPs= are
supposed to use to make decisions is systemic throughout CA-issued certs.
(CC'd to the Mozilla policy list, which is probably a better place for = this.
There should be a requirement that CAs accepted by Mozilla and other browse= rs
publicly document all OIDs they use in certs in an easily-accessible manner= ,
either via a central registry administered by Mozilla or a flat text file o= r
web page on the CA site).

Peter.




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

--0016368e35a42b966904a7a5b991-- From koichi.sugimoto@globalsign.com Sun Jul 10 19:42:04 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E27421F8642 for ; Sun, 10 Jul 2011 19:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ignk3NaKyX-h for ; Sun, 10 Jul 2011 19:42:03 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEE921F8640 for ; Sun, 10 Jul 2011 19:42:03 -0700 (PDT) Received: by wwe5 with SMTP id 5so2304416wwe.13 for ; Sun, 10 Jul 2011 19:42:02 -0700 (PDT) Received: by 10.227.182.74 with SMTP id cb10mr3781419wbb.48.1310352122414; Sun, 10 Jul 2011 19:42:02 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by mx.google.com with ESMTPS id gg16sm9662195wbb.17.2011.07.10.19.42.01 (version=SSLv3 cipher=OTHER); Sun, 10 Jul 2011 19:42:02 -0700 (PDT) Received: by wyj26 with SMTP id 26so2680284wyj.31 for ; Sun, 10 Jul 2011 19:42:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.187.75 with SMTP id x53mr2595708wem.92.1310352121320; Sun, 10 Jul 2011 19:42:01 -0700 (PDT) Received: by 10.216.7.205 with HTTP; Sun, 10 Jul 2011 19:42:01 -0700 (PDT) In-Reply-To: <3C112475-3D75-453E-A2F9-320030B74FAA@vpnc.org> References: <3C112475-3D75-453E-A2F9-320030B74FAA@vpnc.org> Date: Mon, 11 Jul 2011 11:42:01 +0900 Message-ID: From: koichi sugimoto To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman Subject: Re: [pkix] Removing relying party from CAA, again 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, 11 Jul 2011 02:42:04 -0000 Hello Sirs, The removal should be done directly or we especially for non-native english speakers may confuse. I agree with Paul. Regards, Koichi Sugimoto. 2011/7/8 Paul Hoffman : > On Jun 16, 2011, at 7:04 AM, Stephen Kent wrote: > >> I think it best to remove the discussion of RP use of this feature, and = focus instead on how CAs are expected to use it. > > On Jul 7, 2011, at 2:53 PM, Phillip Hallam-Baker wrote: > >> I have submitted an updated version of CAA. >> >> http://www.ietf.org/id/draft-ietf-pkix-caa-01.txt >> >> >> The main change here has been to take out most of the references to Rely= ing Party use except for: >> >> 1) The parts that explain why it is as bad idea for applications to use = CAA records intended to control issue to reject certs at the time of relian= ce. >> >> 2) Bit 6 is reserved to signify RP use (Bit 6 in DNS terms being Bit 1 t= o everyone else). > > Taking out "most" is not what was asked for. The large amount of relying = party text makes it sound like it should be used, the message to the list n= otwithstanding. > >> Note that there is no statement to the effect of 'don't use this for rel= ying party use ever'. Nor is there any statement about how CAs might use th= e RP bit to audit certificate issue. > > Noted. And thus the confusion. > >> Given that Google has deployed code that uses the 'auth' property for th= e purpose of validating RP keys, I think that this is probably a good separ= ation to insist on in future. > > To the best of my understanding, that "deployed code" is not usable by ne= arly anyone, and is thus irrelevant. > >> =A0So we might want to state that the policy/path properties are NEVER f= or use by RP applications. > > A better thing to do would be to do what was originally asked, and remove= the discussion of RP use of CAA. In specific: > > In section 1, remove: > =A0 Relying Party =A0A party that makes use of an application whose > =A0 =A0 =A0operation depends on use of a Certificate for making a securit= y > =A0 =A0 =A0decision. > > =A0 Relying Application =A0An application whose operation depends on use = of > =A0 =A0 =A0a Certificate for making a security decision. > > =A0 Relying Party Authorization Set =A0The set of Authorization Entries f= or > =A0 =A0 =A0a domain name that are flagged for use by Relying Party > =A0 =A0 =A0Applications. =A0Analogous to an Access Control List but with = no > =A0 =A0 =A0ordering specified. > > In section 2, remove: > =A0 Thus Relying Applications MUST NOT use failure > =A0 to conform to currently published CAA records as a rejection criteria > =A0 for certificates unless the published records are flagged as being > =A0 intended for that use. > > In section 2.1, remove: > =A0 =A0 =A0Relying Parties MUST NOT attempt to enforce CAA records if the > =A0 =A0 =A0Relying Party Authorization Set contains unknown property entr= y > =A0 =A0 =A0tags that are flagged as critical > . . . > =A0 =A0 =A0Relying Parties MUST NOT attempt to enforce CAA records if the > =A0 =A0 =A0Relying Party Authorization Set contains property entries with= the > =A0 =A0 =A0Must Be Zero Tag Set. > . . . > =A0 Relying Party =A0This bit is reserved to specify that the correspondi= ng > =A0 =A0 =A0Property Entry MAY be used by Relying Party Applications. > > =A0 =A0 =A0Relying Parties MUST NOT attempt to enforce properties specifi= ed > =A0 =A0 =A0in CAA records with the Relying Party bit set clear. > . . . > =A0 Since the validity of an end entity certificate is typically a year > =A0 or more it is quite possible that the CAA records published at a > =A0 domain will change between the issue of the certificate and > =A0 verification by a relying party. > > In section 3.1, remove: > =A0 =A0 =A0Bit 6: Relying Application Use =A0If set, the property entry > =A0 =A0 =A0 =A0 contains an Authorization Entry that forms part of the Re= lying > =A0 =A0 =A0 =A0 Application Authorization Set for the corresponding domai= n. > Also change the example after the bit description to use bit 7 instead of= bit 5. > > --Paul Hoffman > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From iang@iang.org Sat Jul 9 15:48:49 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CDB21F89AB for ; Sat, 9 Jul 2011 15:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IT=0.635, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.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 ctXckfBHTbal for ; Sat, 9 Jul 2011 15:48:49 -0700 (PDT) Received: from fiddle.it (unknown [67.207.137.25]) by ietfa.amsl.com (Postfix) with ESMTP id 500EA21F8942 for ; Sat, 9 Jul 2011 15:48:48 -0700 (PDT) Received: from viento.local (localhost [127.0.0.1]) by fiddle.it (Postfix) with ESMTP id A0854406C2; Sat, 9 Jul 2011 22:48:45 +0000 (UTC) Message-ID: <4E18DACB.8020800@iang.org> Date: Sun, 10 Jul 2011 08:48:43 +1000 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110528 Thunderbird/5.0b1 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 11 Jul 2011 06:42:58 -0700 Cc: mozilla-dev-security-policy@lists.mozilla.org, pkix@ietf.org Subject: Re: [pkix] Policy OIDs in CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 23:13:42 -0000 On 9/07/11 6:09 PM, Peter Gutmann wrote: > Yoav Nir writes: > >> To use this in CAA, a domain owner would have to know in advance what OID the >> CA was going to stick in the certificate. Is this public knowledge? > > Nope, and the problem of completely undocumented policy OIDs that RPs are > supposed to use to make decisions is systemic throughout CA-issued certs. :) > (CC'd to the Mozilla policy list, which is probably a better place for this. > There should be a requirement that CAs accepted by Mozilla and other browsers > publicly document all OIDs they use in certs in an easily-accessible manner, > either via a central registry administered by Mozilla or a flat text file or > web page on the CA site). Good luck on that one. I've no idea how you get any RP excitement with an OID. It seems to be a bona fide breach of Kherkhoffs' 6th. EVG has an OID of some form, but it is interpreted by software, so in this case, RP-proxy role of Mozilla. iang From kent@bbn.com Mon Jul 11 11:40:35 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B1311E8153 for ; Mon, 11 Jul 2011 11:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dRMQrM5KsjO for ; Mon, 11 Jul 2011 11:40:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB2511E80A8 for ; Mon, 11 Jul 2011 11:40:35 -0700 (PDT) Received: from dhcp89-089-024.bbn.com ([128.89.89.24]:49201) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QgLPG-0004mQ-Tx for pkix@ietf.org; Mon, 11 Jul 2011 14:40:35 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 11 Jul 2011 14:40:27 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] Agenda, slides 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, 11 Jul 2011 18:40:36 -0000 Folks, The agenda is now posted. All speakers are requested to submit slide to me for posting. If anyone wants a slot and is not on the agenda, please contact me RSN. Thanks, Steve From wwwrun@rfc-editor.org Tue Jul 12 13:25:24 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513C611E8071 for ; Tue, 12 Jul 2011 13:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVUBopHWpeNm for ; Tue, 12 Jul 2011 13:25:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id E3A1811E8073 for ; Tue, 12 Jul 2011 13:25:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C8EE098C510; Tue, 12 Jul 2011 13:25:19 -0700 (PDT) To: rhousley@rsasecurity.com, wford@verisign.com, wpolk@nist.gov, dsolo@alum.mit.edu, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20110712202519.C8EE098C510@rfc-editor.org> Date: Tue, 12 Jul 2011 13:25:19 -0700 (PDT) X-Mailman-Approved-At: Wed, 13 Jul 2011 08:49:39 -0700 Cc: pkix@ietf.org, hablutzel1@gmail.com, rfc-editor@rfc-editor.org Subject: [pkix] [Editorial Errata Reported] RFC3280 (2858) 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, 12 Jul 2011 20:25:24 -0000 The following errata report has been submitted for RFC3280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3280&eid=2858 -------------------------------------- Type: Editorial Reported by: Jaime Hablutzel Section: 4.1.2.4 Original Text ------------- Exceptions to the December 31, 2003 UTF8 encoding requirements are as follows: (a) CAs MAY issue "name rollover" certificates to support an orderly migration to UTF8String encoding. Such certificates would include the CA's UTF8String encoded name as issuer and and the old name encoding as subject, or vice-versa. Corrected Text -------------- Exceptions to the December 31, 2003 UTF8 encoding requirements are as follows: (a) CAs MAY issue "name rollover" certificates to support an orderly migration to UTF8String encoding. Such certificates would include the CA's UTF8String encoded name as issuer and the old name encoding as subject, or vice-versa. Notes ----- there is a duplicate 'and' Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3280 (draft-ietf-pkix-new-part1-12) -------------------------------------- Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Publication Date : April 2002 Author(s) : R. Housley, W. Polk, W. Ford, D. Solo Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From era@x500.eu Thu Jul 14 03:28:01 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0C821F8AFF for ; Thu, 14 Jul 2011 03:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_DK=1.009, 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 JUgiG2+TUHR5 for ; Thu, 14 Jul 2011 03:27:57 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id E167521F8A7D for ; Thu, 14 Jul 2011 03:27:56 -0700 (PDT) Received: from Morten ([79.138.244.92]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id XRP95353 for ; Thu, 14 Jul 2011 12:27:53 +0200 From: "Erik Andersen" To: "PKIX" Date: Thu, 14 Jul 2011 12:27:51 +0200 Message-ID: <004001cc4210$b3cb3210$1b619630$@eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01CC4221.77540210" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxCEK9Vlsgy8ZwjS0aS75DVcipwtg== Content-Language: da Subject: [pkix] Certification path 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, 14 Jul 2011 10:28:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0041_01CC4221.77540210 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Does a certification path go from the end-entity to the trust anchor or does it go from the trust anchor to the end-entity? What is forward and what is reverse? Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik ------=_NextPart_000_0041_01CC4221.77540210 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Does a = certification path go from the end-entity to the trust anchor or does it = go from the trust anchor to the end-entity? What is forward and what is = reverse?

 

Erik = Andersen

Andersen's = L-Service

Elsevej = 48,

DK-3500 = Vaerloese

Denmark=

Mobile: +45 2097 = 1490

e-amail: era@x500.eu

Skype: = andersen-erik

http://www.x500.eu/

http://www.x500standard.com/

http://dk.linkedin.com/in/andersenerik

 

------=_NextPart_000_0041_01CC4221.77540210-- From pgut001@login01.cs.auckland.ac.nz Thu Jul 14 03:39:59 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F44821F8589 for ; Thu, 14 Jul 2011 03:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.657 X-Spam-Level: X-Spam-Status: No, score=-3.657 tagged_above=-999 required=5 tests=[AWL=-0.058, 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 OCG7mDB4d7fq for ; Thu, 14 Jul 2011 03:39:55 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3C26321F874B for ; Thu, 14 Jul 2011 03:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1310639995; x=1342175995; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20era@x500.eu,=20pkix@ietf.org|Subject:=20Re:=20[pki x]=20Certification=20path|In-Reply-To:=20<004001cc4210$b3 cb3210$1b619630$@eu>|Message-Id:=20|Date:=20Thu,=2014=20Jul=202011 =2022:39:51=20+1200; bh=AJeQk1YPjWCYehClv8COuFy0YfT7EgvVfgDFIVkJzXA=; b=JiX39k8ZqCwc0Y6pvPpXb0Att5HsaZ6FWj3Rsyc465yuTIDoTF+xDLDl VQcGHP0FGGF6AKGLHyo6sY5AFCdtUxJe/saEse/ZTXFAnuFZ29ZZBBnky mqRyvMfKyXR4ewORKnXjRyyCQQ7cMySS83WoLleBxFnl/+8Exas18JbqR 0=; X-IronPort-AV: E=Sophos;i="4.65,528,1304251200"; d="scan'208";a="71744098" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Jul 2011 22:39:52 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QhJKi-0001wY-GF; Thu, 14 Jul 2011 22:39:52 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QhJKh-0007vA-WC; Thu, 14 Jul 2011 22:39:52 +1200 From: Peter Gutmann To: era@x500.eu, pkix@ietf.org In-Reply-To: <004001cc4210$b3cb3210$1b619630$@eu> Message-Id: Date: Thu, 14 Jul 2011 22:39:51 +1200 Subject: Re: [pkix] Certification path 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, 14 Jul 2011 10:39:59 -0000 "Erik Andersen" writes: >Does a certification path go from the end-entity to the trust anchor or does >it go from the trust anchor to the end-entity? Meant as a tongue-in-cheek comment: You really do like to ask the minefield questions don't you? This is a bit like asking whether we should be praying to Allah, Jehovah, or the Christian God. What's next, "what does the term nonrepudiation signify"? Peter. From carl@redhoundsoftware.com Thu Jul 14 03:50:15 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A3321F87C9 for ; Thu, 14 Jul 2011 03:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 S-ZfAgSXphUZ for ; Thu, 14 Jul 2011 03:50:15 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 241C021F87C7 for ; Thu, 14 Jul 2011 03:50:15 -0700 (PDT) Received: by qyk9 with SMTP id 9so926975qyk.10 for ; Thu, 14 Jul 2011 03:50:14 -0700 (PDT) Received: by 10.224.17.145 with SMTP id s17mr2000382qaa.357.1310640614480; Thu, 14 Jul 2011 03:50:14 -0700 (PDT) Received: from [192.168.1.6] (pool-173-79-132-155.washdc.fios.verizon.net [173.79.132.155]) by mx.google.com with ESMTPS id d12sm54288qcd.26.2011.07.14.03.50.09 (version=SSLv3 cipher=OTHER); Thu, 14 Jul 2011 03:50:13 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Thu, 14 Jul 2011 06:50:05 -0400 From: Carl Wallace To: Erik Andersen , PKIX Message-ID: Thread-Topic: [pkix] Certification path In-Reply-To: <004001cc4210$b3cb3210$1b619630$@eu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Certification path 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, 14 Jul 2011 10:50:15 -0000 > Does a certification path go from the end-entity to the trust anchor or >does it go from the trust anchor to the end-entity? What is forward and >what is reverse? See RFC 4158, Section 1.3, Terminology: http://tools.ietf.org/html/rfc4158.html#section-1.3. From era@x500.eu Thu Jul 14 04:49:28 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088B021F8789 for ; Thu, 14 Jul 2011 04:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_05=-1.11, HELO_EQ_DK=1.009] 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 yvP8wBtL19TK for ; Thu, 14 Jul 2011 04:49:23 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 709DE21F8783 for ; Thu, 14 Jul 2011 04:49:23 -0700 (PDT) Received: from Morten ([79.138.244.92]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id XSL96920 for ; Thu, 14 Jul 2011 13:49:20 +0200 From: "Erik Andersen" To: References: <004001cc4210$b3cb3210$1b619630$@eu> In-Reply-To: Date: Thu, 14 Jul 2011 13:49:21 +0200 Message-ID: <004b01cc421c$14f94620$3eebd260$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxCEmDup7ohZMatSpmoDgrHNzj+eQAAZi1g Content-Language: da Subject: Re: [pkix] Certification path 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, 14 Jul 2011 11:49:28 -0000 I would pray to the definite, absolute universal trust anchor, if we can identify it. Besides that, I like precise definitions, not wishy-washy ones subject to interpretation. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] Sendt: 14. juli 2011 12:40 Til: era@x500.eu; pkix@ietf.org Emne: Re: [pkix] Certification path "Erik Andersen" writes: >Does a certification path go from the end-entity to the trust anchor or does >it go from the trust anchor to the end-entity? Meant as a tongue-in-cheek comment: You really do like to ask the minefield questions don't you? This is a bit like asking whether we should be praying to Allah, Jehovah, or the Christian God. What's next, "what does the term nonrepudiation signify"? Peter. From bruce.stephens@isode.com Thu Jul 14 04:55:57 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B0321F85D9 for ; Thu, 14 Jul 2011 04:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.745 X-Spam-Level: X-Spam-Status: No, score=-0.745 tagged_above=-999 required=5 tests=[AWL=1.854, 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 8+jroHSK4BkR for ; Thu, 14 Jul 2011 04:55:57 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 20B9721F8698 for ; Thu, 14 Jul 2011 04:55:56 -0700 (PDT) Received: from tinier.isode.net (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id for ; Thu, 14 Jul 2011 12:55:54 +0100 Received: by tinier.isode.net (sSMTP sendmail emulation); Thu, 14 Jul 2011 12:55:54 +0100 From: Bruce Stephens To: pkix@ietf.org References: <004001cc4210$b3cb3210$1b619630$@eu> X-Hashcash: 1:20:110714:pkix@ietf.org::sZYGdHMODIDi7avX:00002k04 Date: Thu, 14 Jul 2011 12:55:54 +0100 In-Reply-To: (Carl Wallace's message of "Thu, 14 Jul 2011 06:50:05 -0400") Message-ID: <80tyapdqk5.fsf@tinier.isode.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [pkix] Certification path 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, 14 Jul 2011 11:55:57 -0000 Carl Wallace writes: >> Does a certification path go from the end-entity to the trust anchor or >>does it go from the trust anchor to the end-entity? What is forward and >>what is reverse? > > See RFC 4158, Section 1.3, Terminology: > http://tools.ietf.org/html/rfc4158.html#section-1.3. So a certification path is an ordered list of certificates starting from one signed by a trust anchor to the end entity itself. And building in the forward direction is building the path starting with the end entity (i.e., building it backwards). And X.509 (2005) offers three data types for representing certification paths, only one of which (PkiPath) is a SEQUENCE OF Certificate. (I don't find the other two to have entirely clear meaning; in particular Certificates seems non-obvious as a representation for a certification path.) From pgut001@login01.cs.auckland.ac.nz Thu Jul 14 05:07:51 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67FD21F88A0 for ; Thu, 14 Jul 2011 05:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.653 X-Spam-Level: X-Spam-Status: No, score=-3.653 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 3kKPKJTU706H for ; Thu, 14 Jul 2011 05:07:48 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id C55FA21F8828 for ; Thu, 14 Jul 2011 05:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1310645268; x=1342181268; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20era@x500.eu,=20pkix@ietf.org|Subject:=20Re:=20[pki x]=20Certification=20path|In-Reply-To:=20<004b01cc421c$14 f94620$3eebd260$@eu>|Message-Id:=20|Date:=20Fri,=2015=20Jul=202011 =2000:07:40=20+1200; bh=v6NO3+Cd3u4JffivX9ZIxnfBTcBw/KyfaKLVjaXF2fw=; b=kZ0fo3w2mC4NMdmUPWbHJte+4sgmq9GC/atfAQP+SYFFkU5LSaWRi1HT vsUmOfwwQ+ZBOccJeHodxLZk2OgxIpiBw51vtTZlPgq8VZ/mcAOwu824K Rq0wpGLLtqyDwrZHQM7DJ/dA6lgdm5anzhfIgcfKTtmXD654xy0LeOIso Y=; X-IronPort-AV: E=Sophos;i="4.65,528,1304251200"; d="scan'208";a="71748592" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 15 Jul 2011 00:07:40 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QhKhg-0004PZ-H1; Fri, 15 Jul 2011 00:07:40 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QhKhg-0004FB-7i; Fri, 15 Jul 2011 00:07:40 +1200 From: Peter Gutmann To: era@x500.eu, pkix@ietf.org In-Reply-To: <004b01cc421c$14f94620$3eebd260$@eu> Message-Id: Date: Fri, 15 Jul 2011 00:07:40 +1200 Subject: Re: [pkix] Certification path 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, 14 Jul 2011 12:07:52 -0000 "Erik Andersen" writes: >Besides that, I like precise definitions, not wishy-washy ones subject to >interpretation. In PKI? It's nothing *but* wishy-washy definitions. Try getting any group of more than about two people to agree on what "recognise an extension" means, or what nonrepudiation means, or what a signature indicates, or what's meant by "trust", or what anything with the word "policy" in it really means... Peter. From era@x500.eu Thu Jul 14 05:20:48 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00AE21F8589 for ; Thu, 14 Jul 2011 05:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 sFE4r7mJ7AoL for ; Thu, 14 Jul 2011 05:20:44 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 0462A21F8590 for ; Thu, 14 Jul 2011 05:20:43 -0700 (PDT) Received: from Morten ([79.138.244.92]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id XTI96641 for ; Thu, 14 Jul 2011 14:20:41 +0200 From: "Erik Andersen" To: References: <004b01cc421c$14f94620$3eebd260$@eu> In-Reply-To: Date: Thu, 14 Jul 2011 14:20:32 +0200 Message-ID: <005501cc4220$76382740$62a875c0$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxCHqWAxdRA89wKTQ6OOmMNGqDVBwAAUTmw Content-Language: da Subject: Re: [pkix] Certification path 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, 14 Jul 2011 12:20:48 -0000 At least there seems to be agreement on what a certification path is and what is forward and what is reverse. That is propress. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] Sendt: 14. juli 2011 14:08 Til: era@x500.eu; pkix@ietf.org Emne: Re: [pkix] Certification path "Erik Andersen" writes: >Besides that, I like precise definitions, not wishy-washy ones subject to >interpretation. In PKI? It's nothing *but* wishy-washy definitions. Try getting any group of more than about two people to agree on what "recognise an extension" means, or what nonrepudiation means, or what a signature indicates, or what's meant by "trust", or what anything with the word "policy" in it really means... Peter. From kent@bbn.com Thu Jul 14 06:54:12 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608C021F889F for ; Thu, 14 Jul 2011 06:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyP4wxiiktSl for ; Thu, 14 Jul 2011 06:54:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0D76121F8786 for ; Thu, 14 Jul 2011 06:54:11 -0700 (PDT) Received: from [192.1.255.210] (port=49164) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QhMMZ-000Gn0-BN; Thu, 14 Jul 2011 09:53:59 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <004001cc4210$b3cb3210$1b619630$@eu> References: <004001cc4210$b3cb3210$1b619630$@eu> Date: Thu, 14 Jul 2011 09:52:32 -0400 To: "Erik Andersen" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: PKIX Subject: Re: [pkix] Certification path 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, 14 Jul 2011 13:54:12 -0000 At 12:27 PM +0200 7/14/11, Erik Andersen wrote: >Content-Type: multipart/alternative; > boundary="----=_NextPart_000_0041_01CC4221.77540210" >Content-Language: da > >Does a certification path go from the end-entity to the trust anchor >or does it go from the trust anchor to the end-entity? What is >forward and what is reverse? > paths generally are built bottom up, always verified top down. So, in part, it's a question of which activity one is performing. From paul.hoffman@vpnc.org Thu Jul 14 08:13:01 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BAD21F8B3F for ; Thu, 14 Jul 2011 08:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.679 X-Spam-Level: X-Spam-Status: No, score=-102.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6VdvH6kqKaP for ; Thu, 14 Jul 2011 08:13:01 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BC4BD21F8736 for ; Thu, 14 Jul 2011 08:13:00 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6EFCnXY078721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Jul 2011 08:12:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <005501cc4220$76382740$62a875c0$@eu> Date: Thu, 14 Jul 2011 08:12:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <166DABD0-6CBD-465B-A75B-F3F853CA6A08@vpnc.org> References: <004b01cc421c$14f94620$3eebd260$@eu> <005501cc4220$76382740$62a875c0$@eu> To: Erik Andersen X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] Certification path 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, 14 Jul 2011 15:13:01 -0000 On Jul 14, 2011, at 5:20 AM, Erik Andersen wrote: > At least there seems to be agreement on what a certification path is = and > what is forward and what is reverse. That is propress. You sound like an optimist. Note the definition that was posted: Certification Path: An ordered list of certificates starting with a certificate signed by a trust anchor and ending with the target certificate. In fact, many people assume that the certification path includes the = trust anchor. Thus, Peter's skepticism is warranted, even in this case. --Paul Hoffman From era@x500.eu Thu Jul 14 09:45:08 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F9511E8078 for ; Thu, 14 Jul 2011 09:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.011 X-Spam-Level: * X-Spam-Status: No, score=1.011 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DK=1.009, 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 Bjpmr80fjnhZ for ; Thu, 14 Jul 2011 09:45:03 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 628C411E8071 for ; Thu, 14 Jul 2011 09:45:02 -0700 (PDT) Received: from Morten ([78.156.218.152]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id XXG61854 for ; Thu, 14 Jul 2011 18:44:54 +0200 From: "Erik Andersen" To: "PKIX" Date: Thu, 14 Jul 2011 18:44:55 +0200 Message-ID: <005c01cc4245$5ecece90$1c6c6bb0$@eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_005D_01CC4256.22579E90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxCRVwWxRNIx22oRiexFtAeFYcf8A== Content-Language: da Subject: [pkix] Trust anchors 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, 14 Jul 2011 16:45:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005D_01CC4256.22579E90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_005E_01CC4256.2257C5A0" ------=_NextPart_001_005E_01CC4256.2257C5A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To prove I am an optimist, I have produced a first draft for a subclause on trust anchors to be included in X.509. I will appreciate any constructive comment. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik ------=_NextPart_001_005E_01CC4256.2257C5A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

To prove I = am an optimist, I have produced a first draft for a subclause on trust = anchors to be included in X.509.

 

I will = appreciate any constructive comment.  

 

Erik = Andersen

Andersen's = L-Service

Elsevej = 48,

DK-3500 = Vaerloese

Denmark=

Mobile: +45 2097 = 1490

e-amail: era@x500.eu

Skype: = andersen-erik

http://www.x500.eu/

http://www.x500standard.com/

http://dk.linkedin.com/in/andersenerik

 

------=_NextPart_001_005E_01CC4256.2257C5A0-- ------=_NextPart_000_005D_01CC4256.22579E90 Content-Type: application/pdf; name="trust-anchor.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="trust-anchor.pdf" JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1HQikgL1N0cnVjdFRyZWVSb290IDE5IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDEvS2lkc1sgMyAwIFJdID4+ DQplbmRvYmoNCjMgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwv Rm9udDw8L0YxIDUgMCBSL0YyIDcgMCBSL0YzIDkgMCBSL0Y0IDExIDAgUi9GNSAxNiAwIFI+Pi9Q cm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA1 OTUuMzIgODQxLjY4XSAvQ29udGVudHMgNCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNw YXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDA+Pg0KZW5kb2JqDQo0 IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI5OTA+Pg0Kc3RyZWFtDQp4nJ1a 3W/bOBJ/L9D/QY8SEDPihyjpriiQZtu7HrB3i7u8tfugOk4irGMHttq9/vc3MxQlUvLYuiCAY0sz 5HDmN18kr28OXfvQrLvk3bvrm65r1k+b++TL9d3+5ffru58vm+vfmsd213Ttfvf+ffLhl9vkw93b N9efZFKL2iZ3D2/fyCSHP5moqhaqSMo6F8Ykd89v3+TJI3787e2bL+kq+z25+8fbNx+BHYcYuGol TB1yfUkTlrYQuYxpJUOr81zkxbJxda5EUca0nLw6L0St+XGTj7/eJsn1b6jQX28//5Lkkd5UIqXI TaS4wgprktIYUfsRS8FMb4FIxbQFQ1qChNNxOQ3Aaqya0N5lJj18P3bZqkiTZpdJna6f9ocjM4SE ZdQVP91MMfISoHq9KCuKqh/wJpMSRl2VJu0O2UoW6ffMpsdMpyCmzPtXIKxJ1/BAp0/weo8rAGrd v26P8LqnJKIdELnfm+F318KIVfpzeNVx6wY95zYW8wlnbDpkLMLppjJv7rOVH/8bvCphPll52fCf TdcblJzE79psVacPWZW266bbcF5SWVEVsUC89+VCyZj2OwqP4rW7bGXSx0EDR68Q+tKhrlT6nJW8 Xxkr5EQS4kUFvOA09DHap4Mpq2DGXgX0brOl+X4iMZCVQIbAJDoapjngp8MBqZHzIVMYUUwWzS3B FKUoJ0v4jOLscDI0hZce7PqcyTrFWEmmHFHVgG1LR4grR1xUIG9GgD09b499WQjpp0XwqBE7MIis VIDg9RPgLMK6rHT6NZ3McP1Jz11NSi2K6Xwc4KUVOiY9gEADbALJCqcmkMyvHyl7yRy8HjCuDK+e G3QI0iAuair5qawD0mCcH8VJwB+N1snd+kv6NWNzidKi1DEfsXh3RRG7n2hRQhd43NYj0Pr36z0u bIBCS9h79HZ2sL1HknHJZdrtcd1+hid4smEdCNFXx7qO4sFDu0ZQ8MFA1w6/4QhcMDC5FFLGtKeD AUoeRAM9BgPe46ZS8B5Xi7yMaUlv/bwN/XdC7bkxqkpUduGqoQCZLHrdoHa3W7RdMRP0pAMVKp86 BfirCbyiz09n3T3Xwtqe/Zz7KDckAQkfTa1/0lNkXpKPj5Ogpzg/EZxgUipRxjzE4BOx+v/zk7RK 6CpeLGccaQtRThTjI6DzNox8PhOocylqJQ19cwGzd2JFBYJ79AO+ufzv1jXx7UdU9ujWRHg/TOyD 2eV8oGbpwFcuvYD4bEvPuvaFgAjxYeURRLOPSaChiSj8n6h3jh4uXleMC5T1RMvJCqCRV1VFxu54 P5tDijhY565dsRTac9QOrnOawozT4vjQm+icI1n0acPkzUBls4wZOxY8ax4zXxXiG66kkEZi8RvN e7b4VdPiN3LVCmroCpZRVuB8brR/cpW7pCo/JP3XHebUj/O4ZSbTOOcOWN/l+Qf5/kQsmbCVQtlo SjZ8KEgpEWV3+I6ueexYFlBlriKeBmyww8JgDV+e8MsePw5ngoZVy+SzNagvIm2PCDuo2zGaQUWS FWD/Pl/X9BPFocLdPefqC+gpdTTysS9NVe5WQ4ugbz/B7Z+xZKVH3/GDa7OUrbAHXrI4VQIoI/um f2YAfexstNMj32lLUcasUKmA3bwqoCrvNhjlpBOcrWBUieVZONBhPyyeKzE1YKCMF8n249BvRqQu dLm0dntzprDKw/UtSIXaaiHriIcYPu/6Jg6V0oz6OXaHdt31P0jb7ebQYALpYQxhjcBwhXHHK5VC 3tOILnp6e0NfNA3vhqxOGGSPD14CaUjJVGF7koDn9Cp96AGYlT6SnRLeOtlh3ML2XkGpl1KtUdjO DkuAn2t8i9JjEa3phe994W20FPgdQgRzn0RLSgvhlzTFV/SqiCX/u0suBPsNzvEDy23c2LjqI75x ubsaVuK98NCLU7iwQ8/oLSl4uyFn/q9bb+GWSkDAGdoDmWI38Axvu6u++Md5u1GGExrcRTowZqrS l+H98QjcLVZk35xsSJD3eOjnuvca3p1zPEzoRsU6bB/8poRRTsaTRgIBByNJPrJ4fBWVqPsJPvKb UkUek3rzeZerrbPt4DDBi0G9+B2Del3MdPYNPkhdtRnVhfSozPto0A4fjbqoB1+HbxNV1BUfeRRE HmhOx0WNkeeKRTZUzGXMQwwNSw9VUB0pjh+6FpWMSNceKQeXASl+YJ8JeKf4w/aaeTEdi99Fraak Luu1VHA/OieobZgzjx15MNdjaij9dLFo0RpaTFNGpANYZF47lw29sbaxN3L9cy7qWO07D6E1lZHG wQ61eGi3/Yaf4ttCY7Soi7l1xsrh2FIPQuZiq3sjykV6MWUpKhXrBVHPr7gqsM8OGUanCCo9dL0m oyp/cRVXaCvCpVNer8+naB9cTOX3oHtP+Q9adx+F46Ftwz7x8JzZMSm12Lz2FC6mJRTTgiDtUp8f oIdmE2Q1SGrNH1k9TuVynE/gpo8Z2w3XUihrqIAc13KhpdDL9tOtltiC+T3+FUVP33tRrzU21u6b a0oRrPTadWVhV4UqTBq3ZXe6EY165JUO3vQ9MjXqLfVdQ59MA1N/vt3Sg28E9b9wCjM1KSxc31mF mUhhZq6wuoY+BzQmC6HUhQ5pvttihI5Y+SZE1ihxRMuFdglFTrFwWGWpkQppd94q3FaA775CJnZz BkpvNZHbtcrPw7ap347vTUrBinZY3V5RH+0tAcmhbbD6sHOqSOymH7kMtwlww8V5F/GOQPbwHPak z8Lzr2e6F3tG3TNIFQshVcD/4lWICjgvASokZTfzoUGHkB+SPp3BUxmJ3uv6xe9kkX9u2zVZ5I9h O22wfnNEm7uNW9zXpDi7GrfRIKz8SVUWxko9hE1v8Tl47LjZ7sGjL2CHNbUusQ7j1DuztF1q6UoL q19n6oD1oq1D2vOHClJrqAcihmb7mIXncFgN1e4Ukyu3ZKnwRGyZjGUhZEyKZQtURLvBmLTHijsK fbocXDcwJeFrQFOAjOm56oU9vuEERgUbyRiFhtRzYlMb1bLuAYtcLJCqCk8XWcXMkFQuRZKlw6BX ISlgvYikkHYRkkKGxbEgOLJtxpyxcZtK1bhz/TUlzT9kdR9DiHg8PIYp3H76dvM1Y0/EJZaOkaCc +VRF54Ksxmbmq5aar1C45fQq8wWsF80X0v6g4sm1CM6nffvaG2BDBnB1F1FxapFVjoc2yySpFNTs ESndyLjn6GvadGDHnqm8XqpyaCHUK2NvwHpR5SEtrHRVBmrej1UQJabDcGTkD5j6mEUFS9NSIewf sr1BroQ8I+T8rk14CynuBwoJTZ9X+7QfOHF2srDI5w7Cij7IcpnCEMxCmcJDO69V1wmM1cdhaCoQ 8n1yGROHPz9Wg3n6KDST00/VXdHgx8wdto3L9YUMV0UoPEKP5Of6Fa0NbhdEtOeNKJfiHuHxyvIy YL2I+5C2GfS12T6wDUNOjh7y8c0FHRFGtGGy7oHkjcwXKTrWxzxDnYlKepmsKs9xvy2inaY8hhOM b2XMObngQWO4Gwnd5ordLKB7XKz15lhSC7FkKiu0fBWWQtZLWIpoHZZ2QXAZYsiWjsJv0ejjFYQX 2pxYZNMKz2ejyXijStxOiGhP1DHMdZyrUzdHRmtpYQpeP3Nr6aXWwkufrysyQtaL1gppnbXYOwJY JEKHGbGwTo9NWDR8QvcFcAvvG3ufxFi8hBAxEQcfWmpRVrFErwgtFZ4cR4MsDS0qd/ZfohKVW9wp j2hDGJ45e8UDMTthDeFKy3WLHu/swAs+yFgMMouAgsfUpT5tyT235avKEsuauSXPO8fSfbz+3uer nCNgvegcIy2uGYDiDmvm9zGK6cUKt2MXDUC8d3gP+2aH168/7x6mnnb6XmROB++LBFd5jfffI9rm mLjzrwcsqHaTgqrvxM+BzxZ4GhuNSRdnPyK/qzM/scxVjZccIuZ/Qwfx6fZMLtUyn8w4Qq6opWHL MECbPKF0rvjGGq86AwkC6P8AfqMaoA0KZW5kc3RyZWFtDQplbmRvYmoNCjUgMCBvYmoNCjw8L1R5 cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjEvQmFzZUZvbnQvVGltZXMjMjBOZXcjMjBS b21hbi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgNiAwIFIvRmlyc3RD aGFyIDMyL0xhc3RDaGFyIDEyMS9XaWR0aHMgMzkgMCBSPj4NCmVuZG9iag0KNiAwIG9iag0KPDwv VHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9UaW1lcyMyME5ldyMyMFJvbWFuL0ZsYWdzIDMy L0l0YWxpY0FuZ2xlIDAvQXNjZW50IDg5MS9EZXNjZW50IC0yMTYvQ2FwSGVpZ2h0IDY5My9BdmdX aWR0aCA0MDEvTWF4V2lkdGggMjU2OC9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9MZWFkaW5n IDQyL1N0ZW1WIDQwL0ZvbnRCQm94WyAtNTY4IC0yMTYgMjAwMCA2OTNdID4+DQplbmRvYmoNCjcg MCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjIvQmFzZUZvbnQvVGlt ZXMjMjBOZXcjMjBSb21hbixCb2xkL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3Jp cHRvciA4IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTE3L1dpZHRocyA0MCAwIFI+Pg0KZW5k b2JqDQo4IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1RpbWVzIzIwTmV3 IzIwUm9tYW4sQm9sZC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA4OTEvRGVzY2VudCAt MjE2L0NhcEhlaWdodCA2NzcvQXZnV2lkdGggNDI3L01heFdpZHRoIDI1NTgvRm9udFdlaWdodCA3 MDAvWEhlaWdodCAyNTAvTGVhZGluZyA0Mi9TdGVtViA0Mi9Gb250QkJveFsgLTU1OCAtMjE2IDIw MDAgNjc3XSA+Pg0KZW5kb2JqDQo5IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlw ZS9OYW1lL0YzL0Jhc2VGb250L1RpbWVzIzIwTmV3IzIwUm9tYW4sSXRhbGljL0VuY29kaW5nL1dp bkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciAxMCAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFy IDExNy9XaWR0aHMgNDEgMCBSPj4NCmVuZG9iag0KMTAgMCBvYmoNCjw8L1R5cGUvRm9udERlc2Ny aXB0b3IvRm9udE5hbWUvVGltZXMjMjBOZXcjMjBSb21hbixJdGFsaWMvRmxhZ3MgMzIvSXRhbGlj QW5nbGUgLTE2LjQvQXNjZW50IDg5MS9EZXNjZW50IC0yMTYvQ2FwSGVpZ2h0IDY5NC9BdmdXaWR0 aCA0MDIvTWF4V2lkdGggMTgzMS9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9MZWFkaW5nIDQy L1N0ZW1WIDQwL0ZvbnRCQm94WyAtNDk4IC0yMTYgMTMzMyA2OTRdID4+DQplbmRvYmoNCjExIDAg b2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9udC9UaW1lcyMyME5ldyMyMFJv bWFuL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDEyIDAgUi9Ub1VuaWNvZGUg NDIgMCBSPj4NCmVuZG9iag0KMTIgMCBvYmoNClsgMTMgMCBSXSANCmVuZG9iag0KMTMgMCBvYmoN Cjw8L0Jhc2VGb250L1RpbWVzIzIwTmV3IzIwUm9tYW4vU3VidHlwZS9DSURGb250VHlwZTIvVHlw ZS9Gb250L0NJRFRvR0lETWFwL0lkZW50aXR5L0RXIDEwMDAvQ0lEU3lzdGVtSW5mbyAxNCAwIFIv Rm9udERlc2NyaXB0b3IgMTUgMCBSL1cgNDQgMCBSPj4NCmVuZG9iag0KMTQgMCBvYmoNCjw8L09y ZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVtZW50IDA+Pg0KZW5kb2Jq DQoxNSAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9UaW1lcyMyME5ldyMy MFJvbWFuL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDg5MS9EZXNjZW50IC0yMTYvQ2Fw SGVpZ2h0IDY5My9BdmdXaWR0aCA0MDEvTWF4V2lkdGggMjU2OC9Gb250V2VpZ2h0IDQwMC9YSGVp Z2h0IDI1MC9MZWFkaW5nIDQyL1N0ZW1WIDQwL0ZvbnRCQm94WyAtNTY4IC0yMTYgMjAwMCA2OTNd IC9Gb250RmlsZTIgNDMgMCBSPj4NCmVuZG9iag0KMTYgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0 eXBlL1RydWVUeXBlL05hbWUvRjUvQmFzZUZvbnQvQUJDREVFK0NvdXJpZXIjMjBOZXcsQm9sZC9F bmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgMTcgMCBSL0ZpcnN0Q2hhciA2 NS9MYXN0Q2hhciAxMTcvV2lkdGhzIDQ1IDAgUj4+DQplbmRvYmoNCjE3IDAgb2JqDQo8PC9UeXBl L0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDb3VyaWVyIzIwTmV3LEJvbGQvRmxhZ3Mg MzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgODMzL0Rlc2NlbnQgLTIwOS9DYXBIZWlnaHQgNjMzL0F2 Z1dpZHRoIDYwMC9NYXhXaWR0aCA4OTQvRm9udFdlaWdodCA3MDAvWEhlaWdodCAyNTAvU3RlbVYg NjAvRm9udEJCb3hbIC0xOTIgLTIwOSA3MDIgNjMzXSAvRm9udEZpbGUyIDQ2IDAgUj4+DQplbmRv YmoNCjE4IDAgb2JqDQo8PC9UaXRsZShYLjUwMCBDb21tLiBFbmhhbmNlbWVudCkvQXV0aG9yKEVy aWsgQW5kZXJzZW4pL0NyZWF0b3Io/v8ATQBpAGMAcgBvAHMAbwBmAHQArgAgAE8AZgBmAGkAYwBl ACAAVwBvAHIAZAAgADIAMAAwADcpL0NyZWF0aW9uRGF0ZShEOjIwMTEwNzE0MTgzODEzKSAvTW9k RGF0ZShEOjIwMTEwNzE0MTgzODEzKSAvUHJvZHVjZXIo/v8ATQBpAGMAcgBvAHMAbwBmAHQArgAg AE8AZgBmAGkAYwBlACAAVwBvAHIAZAAgADIAMAAwADcpPj4NCmVuZG9iag0KMjQgMCBvYmoNCjw8 L1R5cGUvT2JqU3RtL04gMTkvRmlyc3QgMTI5L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjgy Pj4NCnN0cmVhbQ0KeJy9k81qwzAQhO+BvMO8gbxa/VgQci4EgnFyCzmUIHpqU1wHmrfvShtoCwX5 1NMwq2/H8nptLTpYDw6wAZFgI6gT04OcuASKASwMEVgKTpyVY3EsBXEO7MVJRh9LjrNyEOF8kgpc 8tILL72UEALDdoicIFQMFpuNGQrQYTQH82TN7oTuDDO8gEtxu12vfjNDQaiN2DbCbcS1Ed9GQhuJ baRvI2nB6JaMd8F8acGAacGE6c8Ry7Ioc8iXuX7Osqlj2dUqQSWq9Cq1p2xrFVLRPmYVp6IprCms KVxTznjc4Xh/z+YwT7fLfJxyHq/X2QzPU36rtqxxuWC5GWnfj9N9/px3+Q56ZO1vrx+n8qfx9yP+ 85XWqy+QPdMqDQplbmRzdHJlYW0NCmVuZG9iag0KMzkgMCBvYmoNClsgMjUwIDAgMCAwIDAgMCAw IDAgMzMzIDMzMyAwIDAgMjUwIDMzMyAyNTAgMCAwIDUwMCAwIDAgNTAwIDUwMCAwIDAgMCA1MDAg Mjc4IDI3OCAwIDAgMCAwIDAgNzIyIDAgNjY3IDAgNjExIDU1NiAwIDcyMiAzMzMgMCAwIDAgMCA3 MjIgNzIyIDAgMCA2NjcgNTU2IDYxMSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA0NDQgNTAwIDQ0 NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAwIDUwMCAyNzggNzc4IDUwMCA1MDAgNTAwIDAgMzMz IDM4OSAyNzggNTAwIDUwMCA3MjIgNTAwIDUwMF0gDQplbmRvYmoNCjQwIDAgb2JqDQpbIDI1MCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1MCAwIDAgMCAwIDAgMCA1MDAgMCA1MDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2NjcgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDAgNDQ0IDAgMCAwIDAgNTU2IDAgMCAwIDAgMCA1NTYg NTAwIDAgMCA0NDQgMzg5IDMzMyA1NTZdIA0KZW5kb2JqDQo0MSAwIG9iag0KWyAyNTAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCA1MDAgMCA0NDQgMCA0NDQgMjc4IDAgNTAwIDI3OCAwIDAgMCA3MjIgNTAwIDUwMCAw IDAgMzg5IDM4OSAyNzggNTAwXSANCmVuZG9iag0KNDIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGggMjI0Pj4NCnN0cmVhbQ0KeJxdkMFqwzAMhu9+Ch3bQ3HSXUNgaxnksG4s2wM4 tpIZFtkoziFvP9kLHUxgg/z/n/gtfemuHfkE+o2D7THB6MkxLmFlizDg5EnVFThv096V284mKi1w vy0J547GoJoG9LuIS+INDo8uDHhU+pUdsqcJDp+XXvp+jfEbZ6QElWpbcDjKoBcTb2ZG0AU7dU50 n7aTMH+Ojy0inEtf/4axweESjUU2NKFqKqkWmmepViG5f/pODaP9MpzdT7W4z1X9UNz7e+by9+6h 7MosecoOSpAcwRPe1xRDzFQ+PwlJbysNCmVuZHN0cmVhbQ0KZW5kb2JqDQo0MyAwIG9iag0KPDwv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0MTMzNy9MZW5ndGgxIDE3NzI0OD4+DQpzdHJlYW0N Cnic7J0JfBRF3v5/1d1z5JhkwpFMEmBmMhkIOcgQ7hDN5OQIR4AACYIkhCMgSIDAiouCqygGFFZZ ENcFPDgUXSYT0QC+Gl11RVRAENBVCAIKeLEe6Cqk/09XApL3E/4Q2Nm8K/Vt6qmuo7t/XdPzTNcc gRgRhUEUKs0c1q/P8tg3zpD02DFUzuuTmZU93jxpELF9LxFJq/vkDh42prZqJbEDo4me/rbPsOHp 2wNzQ0m6K5cocmb/YXnZ02In67H969hruwF5w/ouejzocSLnx0SmmwYPS0xqOfy2eUTsJ7QX5mYM yCvYe9dR7P8elLuPyByYP8hR8geiLj2JQpYXTysqXTS/4xPEFpZhG2/xnDJbrevQaWKPPUVk+Ghi 6aRpf1vflhG7L4ZI33lS0axSspAf9of+ZJ40de7EwsyCeGJPLSDyf61k/LTbds28AbFlvkPMvbFk QtH4Q/2e+wT7nqcdvwQVLb4xLUP5eZSjS6aV3Zb6IluEc88nctwzdXpx0ejqmx8htjmTKMIzrei2 0pbHgzeg/0H0t91aNG1CTHZ8BLEd3+N4haXTZ5Wp0TQe8eRp7aUzJ5T2+uwtE7EHMH7BWaSNvS7k yzeCnz48NjjlB2O4kTSeONr2NS1/67UuK38pO7fETMYgFP14fw3kBnttFo000y9lPx8204WWepRb tBrTSOpMEq+QyEyJNAKj5MRxNWS5G1tGOjLqHtV1wQ6cdbm8liZKLZhOkvSyTtFJslJDsWo13ZbG IwB5AzNs5Ca7raVuSW0262Kws+1uYqqqYuvlugHamZKi78Xa1B24DukZOiZn0kL6L8HQlqJ8tW8F F+DVbIcxNP27YxFcGoXUr5s7BoFAIBAIBIL/FGyjuq25Y7hSdJH/PbEKBAJBc8JI3WZEMpPwTYFA IBAIBAKBQCAQCASC/25MIw2M0aSSK9/C0nh13walxGsI6XIYfbhvwW8edvkuV9FVcBkYE6MpEAgE AoHgt49MMtPQyTKTcP9j0X0ZUE0/GVXMYYxqLfmRP9SfawAFqOcokAKhJq5BZIIGQ8+SmYKhIVxb kBnaEvoLtaIQaGtqAQ2lVtAw6M+YpLWGhlMYNIJrJFnUf1EbioC25dqOIqFWagO1QX8iO7WFRpEV 6iAbNBr6IznJDm1PUdAOXGMoWj1DHckJjaX20DjqAI2nGPUHSqCO0E4UC03k6qI49XvqTPHQJEqA duHalRLV76gbuaDdufagztCelKR+S72oCzSZukF7c02h7tAboP+kG6kHNJV6Qt2UDE2DnqZ06g3N oBRoJt0AzYJ+Q9mUCu1Dbmhfrv0oTf2a+lM6NIcyoAMoEzqQstSvaBBlQwdTH2gu1yHUV/2ShlJ/ 6DCueZQDHU4D1C9oBA2EjuSaT4OhBZQLHUVD1FN0E9fRNBQ6hoZBb6Y89SSNpeHQQhoBLaKR0HHQ E1RM+dDxNAo6gW6CToR+TpNoNLSExkAnc51CY9XP6BYqhE6lIug0rrfSOPU4TadiaCmNh86gCdCZ NFE9RrNoErSM62wqgc6hydDf0S3qUbqN61yaCr2dpkF/T7eqn9I8rndQKfROmgGdDz1CC2gm9C6a Bf0DlUHvptlqDd1Dc6AL6XfQe+k26H3Qw7SI5kLvp99Dy7kupnnqIVpCd0AfoDuhD3JdSgvUT2gZ 3QX9I/0B+hDXh+lu6HK6R/2Y/kQLoSvoXuhKug9bPUKL0LqK66N0P/TPtBj6GC1Bn79wXU0PQNfQ g9C10H/Q47QM+gT9EfokPQR9CvoRraOHoetpOXQDrYBuhH5IT9NK6DP0CHQTrUL9s1yfoz+j5q/0 GHQzVw/9BVpBq9WD5KU10EpaC32eHoduoSfUA/QCPQl9kWsVPQXdSuvV/bSN63baAH2JNkL/h55W P6CXub5Cm6DV9Cz0VXpO3Uevcf0b/RX6Onmgb0D30ptUAf07VULfouehO7i+TVvU92knvQB9h16E vktV0Pdoq7qHdtE26G6ue2g79H16Sd1Ne+ll6D6uiAK6n6rVXXSAXoUe5Poh/Q36Eb2uvkf/4Pox vQH9hN6EHqK/q+/SYXoLWkM7oEfobeintFN9h45yPUbvQI/Te9DPuH5Ou9SddIJ2Q0/SHugprl/Q XvVt+pL2Qb+iD6Bfc/2G9kNP0wHoP+kg9Fv6EPodfaTuoO/pH9AfuJ6hj6E/0iH1LfqJDkP/xfVn qoH+QkfUv9NZrufoKLSWjkFVOq6+KTz9Ovf0L7inf8E9/RT39FPc009xTz/FPf0k9/ST3NNPck8/ yT39JPf0k9zTT3JPP8k9/QT39BPc009wTz/BPf1z7umfc0//nHv659zTP+Oe/hn39M+4p3/GPf0z 7unHuacf555+nHv6ce7px7inH+Oefox7+jHu6Ue5px/lnn6Ue/pR7umfck//lHv6p9zTP+WefoR7 +hHu6Ue4px/hnl7DPb2Ge3oN9/Qa7umHuacf5p5+mHv6Ye7ph7mnH+Kefoh7+qFm9PRH6j39w6vy 9IPc0w9yTz/IPf0g9/SD3NMPck8/yD39APf0A9zTD3BPP8A9/QD39P3c0/dzT9/PPX0/9/QPuKfv 456+j3v6Pu7p+7in7+Wevpd7+l7u6Xu5p7/PPf197unvc09/n3v6Hu7pe7in7+Ge/j739D3c0/dw T9/DPX0P9/Td3NN3c0/fzT19N/f0XdzTd3FP38U9fRf39Pe4p7/HPf097unvcU9/j3v6u9zT3+We /i739He4p+/knr6Te/pO7uk7uafv5J6+k3v6Tu7p73BP38k9fSf39J3c03dyT3+be/rb3NPf5p7+ Nvf0HdzTd3BP38E9fQf39LeuI0+PE54uPP268fRV1+TpB3zk6ZuFp/8HPJ1/fG0aHRDqRzIpuit/ K8e/8eqGe1Cu/q2iy6L34b4Fv3mky3c5j8F3UVx3sIDQ5g5BIBAIBAKBwNcEWpo6twpsvLrhjEfM rQT/R2nC3Ep8d/3fhxR4iZ8iCAQCgUAgEPx2MEX4a3OrJsxXLjG3avgevy/nVuLTBME1IF95VzG3 +vchmSKaOwSBQCAQCAQCXxPcLhATIV0TPre6xH+11HDG04T9NRlxxyu4Bpowt7rE118FV4EU3K65 QxAIBAKBQCDwNWZbU+dWQY1XN5zxiLmV4P8oYm7VLEhmW3OHIBAIBAKBQOBrQqJMTZxbBTde3XDG 48vfRPn5cN+C3zxN+LpqgO+iuO6QQqKaOwSBQCAQCAQCX9OyfTDpSN+Ez4LMjVc3fI/fl3Mr8WmC 4BpowtzqEj8tFFwFUsv2zR2CQCAQCAQCga9pHWtu4tyqRePVDWc8vvx7E+LTBME10IS51SV+Wii4 CuTWsc0dgkAgEAgEAoGvsbhakp6MTfgsqHXj1Q3f4/flb6LEpwmCa+Dav/4quApki6u5QxAIBAKB QCDwNZHdW5OhSXOrS/w3NQ3/xIUvfxN1iT+mIRBcCU34umqI76K47pAjuzd3CAKBQCAQCAS+pm1y WBPnVpf4b2r+c3Mr8WmC4Bpowtyqpe+iuO5Q2iY3dwgCgUAgEAgEvsbmDicjBTThlyVtGq82Nyj5 8jdR5sv2EAguSRN+CtjKd1Fcdyg2d3OHIBAIBAKBQOBr7OkRTZxbtW282tyg5Mu5lfimluAaaMLc 6hI/LRRcBYo9vblDEAgEAoFAIPA1zv5tyY8CmvA9O3vj1Q3/fKAv/96E+KaW4Bpowp9ZucRPCwVX gc7Zv7lDEAgEAoFAIPA1sXl2CqCgJnwW5Gy8uuF7/L78TZT4NEFwDTThp4CRvoviukMXm9fcIQgE AoFAIBD4mk6joymQgi7xn1Y1RsfGq0MblMxXH9FlCfPhvgW/eZrwZ1su8fVXwVWg7zS6uUMQCAQC gUAg8DVJ4zuQicxN+NV+fOPV4Q1KvvxNVPjluwgEl6IJcyubz4K4/tAnjW/uEAQCgUAgEAh8Tfep sRREIaGX73keV+PVDb8/1YTPwZqM+KaW4Bpowp9ZifJdFNcdhu5TmzsEgUAgEAgEAl+TXJZAwRTS hO/ZdW28uuH3p3z59ybEN7UE10AT/szKJX5aKLgKDMllzR2CQCAQCAQCga/JuLcrhVCrJnwWlNJ4 dcP3+JvwOViTEZ8mCK6BoMt3OU+c76K47jBm3NvcIQgEAoFAIBD4mpwVydSSLO2ufIuMxqvbNyj5 8jdR7S/fRSC4FOYr7+ryVQzXIX45K5o7BIFAIBAIBAJfM2x9GrWmSMeVb3GJ/6YmtkGpzTWEdDli L99FILgUTfgzK918F8V1h/+w9c0dgkAgEAgEAoGvGV3Vl8KoXRM+CxraeHWnBiXrNYR0OTpdvotA cCma8FPA3r6L4rojcHRVc4cgEAgEAoFA4GvGvzWIwskec+VbFDRendSgZL+GkC5H0uW7CASXogn/ 9bTbZ0Fcf5jGv9XcIQgEAoFAIBD8B5DrUxtivDweJayxKaRQX9J+/G8kifQURQPRNlPvtrVUVdLm TxeV1aN1y1lPzer6/VwE09OFSiZJhP39rw5Iiu7KY3Y1Xt2nQWn4le/vKqho6gb/ttF0pw/Pc6fe eENK7+RePXt079a1S1JnV2KnhPi42I4xHdo7ox1Rdpu1Xds2kRHhlrDQVi1bhJiDg0yBAf5+RoNe p8gSo/gsR3ahzdO+0KO0d/Ttm6CVHUWoKLqootBjQ1V2wz4eWyHvZmvY042eE/9XT3ddT/eFnsxs S6GUhHhblsPmeTfTYatio4bkY/2BTEeBzfMVXx/I15fxdRPW7XZsYMuylGTaPKzQluXJnlNSnlWY id1VBPhnODIm+CfEU4V/AFYDsOYJc5RWsLAbGV+RwrKSKyQymhCUJ8KRmeUJd2RqEXhkZ1bReE/u kPyszEi7vSAh3sMyih3jPORI9wTH8S6UwQ/j0Wd4DPwwtsna2dBiW0V8dfmSKjONK4wLHO8YXzQ6 3yMXFWjHCInDcTM9Ybcfs/xaxM5bZOTfd3FrpFyeZZls04rl5ffZPGuH5F/cate0oAD78EjO7MLy bBx4CYYwZ5gNx5IWFuR72EIc0Kadh3ZOdWc3wZGl1RROsXn8HOmOkvIphXhgIso9NHSu3RsR4d6q 1lBElq08L99h96RGOgqKMttUtKLyoXMrw9228IYtCfEV5pC6Ya0ICq5fCTRdvDLhQhtf4921tZyh F8aVaRE5+uFy8NiKbYgk34Fz6qnJhJ5UXtwT3UABw1ae8Xg8Jnv8MgrLzcmoN2vbe3ROs8NW/gPh 8Xd89WXDmqL6Gr3T/ANpq9pVcuFCQ/v5dU9cnCc2VrtADBl4RBHjjbzcLSF+TpXkcZSabcgwfJSL sS0qSE7E4Nvt2sO7uMpN41DwLBiSX1e20bhIL7kT4wo8UqHWUn2+pfVwrWXB+ZYLmxc6cB0/z5/N rT3G9hf+BZtDW2aVJHtY6P+neUJde84wR86QUfm2rPLC+rHNyWtQqmvveaGtfo3VNWDAPYoTI9XP gUtv6Kh8rQL/dM5sR9bkwr54qiFGT8uMfDlSKqhbkyJlvitcv6Mv7Fkr5Adq+1Kcen79j68yGHEB 8xpmy/aYC/vWaYG/3X6FG1Wpp7WtePbrZvXn5EmOa1ju3aDcILzAchkBK+2lnLxR5eX+DdqyYVbl 5dkOW3Z5YXlRlbpgnMNmdpRvlfPl/PLSrMLzD3+Vum1xpCd7SQFOooQl49KWKL3CwRYNqXCzRcNG 5W81E9kW5eV7JSZlFKYXVESjLX+rDf7MayWtVqvUCjatQDkMzwqvZOT9I7e6iRbwVoVX8HJxFSNe Zzxfx6i4SqqrM5+vk1Cn1NW5eZ2G5hQZefkXXwP8iVWQgGtqK+XJX1bKsdbUtNbyMSqUT9Ia+Tgd RlLIjBoz1lKRSrGuIunUavlIZVZWkrsKeVwnnntjOiZt1Rq8EW2S/kc+Ij1LHciKisPe0Ejecsib nl6/0r1n3UplbELS4TR/+RB9gyTJh+TDFFO3VWVMp6TTaSZUMPlOCmaMrLRW/oQ8SBK55Y8qo9sn rXlFfgftb8s78AKpbbbDawpJwg7/Lr9ILcgqvyBvqW/ZUhkUkkRps+QHMGzV0N1INUinkRSaLm+g +UhLkTYjKRQMtSIlIg3WauRN8ibEuQ7bB0MTkaYjLUVSMITPoP4WTeWN8hS8hlvlJfJyao18sfww z59CHoH8CdS3Q/44ylq+pr78Z+Ra+6P19atQDkX+SH2+EvWRyFegrOV/qi/PkWfz7crq87XyLG87 qzmtHdptSC4kGWvLsbYcQ7dcu6eDMvlueSo/UgXyJOTT6nIM1x1eu4M/RndUhoUnrcWQ3oGhvwMj dwdG7g5S0DTvfJ95dX0S5HnoMw995qHPPIyKS56F483S7umgZiQbkoxxn4Vx1+o90Gqk3bz+Hugy pLVaSf4dxrEjorpfnuKNseIim1TZy52Uul2eiKF2yxMrw9smLf215OevXYjIg+rzYK3vBN46odIv UKudUBnRti5Hr1vSguRi+j2SRK2g0UhdkTKRFLnYG51o3SYPomlGcgdZ50vz5fnKfJ3iymQtXpGT KNeofQerhZxAKejQ0To2hfUo9Cv1W+Anm/1sfi4/t1+un266PF9eKstWOVFOlQfLY2VdlVrtNSR3 Qebuo0/usixgbYAnoDpgd4DOo6/W79bX6E/rdTa9S+/W5+oL9aX6Bfpl+rV6v2X6ZQapMKA0YEGA bA6wBbgC3AG5ATqrga1NWyiP014eoGakUqRlSArGeCzqbfLNSGPxaIzFUNyMeoISSmak3VivQa5D KRj9gtEvGLXBqA1GLUG1llykQqTS+lb9hZbz22j9T2stSB3QGoTaIIxtDfS0tobUHyUTSiaUTOi1 WzqLCM1QG1IukszrapC0ycDZC22u+vZCJD1vP837nG9za9tKZ91FHao7Mk9HtrYjW9aRuVNS05Lc UZAWLVqMdYx1jo0Zu06Z7pjunB4zfZ0y2DHYOThm8Dol1ZHqTI1JXackOhKdiTGJ6xSrw+q0xljX KUsHbB7wyoBdA5SxA6YPmD9A7oGHrtIb50rieZRTy7d4wyOSegSn9ZY243TGQtcgHUaSyQpNREpF mo6kSJuhVuk51D6H2udoMNJYJB22eE6zF6i1vk2rX8PbtDWtXWrQLuPEn/Umdxmc1h+WOxZpDZKM fT+L9md577q1zbzeA63h9YPr+6/l9Vbo+W1kGNwobnOj8PQbBfMfRWORSpF0tEseiReHkdqeoVak UqTNSIo8CstIeaT0HJZnpWfleLepc2srhWp/wLBFiNGcZpYCcQ2Y2Eauj3C9n2sq12h3UH/Tmf6m l/ub7u1v6oAVKYbS0LCcq90dkGZ6Ps00OM3UMc2EvYVhdmSSWnPVa8q+4DqIa7y7ld30L7vpO7vp n3bTX+ymGXbTDXZtuzZ47pqkVlwDNGUruPbn2t4dYDW9aTWNtJp6WE1pJraa4eiUzrUd10hN2bfP B2cGk9929i1lYk/Mm9LRipdknjHVm5KGrNab0gfZOW/KamQ/e1Metr7E/sX4Sxo7440+Zk1rzb5n /RSt/F19/k/WjzYhP418EvL1lMKcyJ/yptyl9X8S2z+K8hMUZdT6P065fLs1rB+v/0v9do9548fh qH/2xs/FUR+leH7Uld74Y6h92Bt/P7KHvPFTkS31OrUAp3hTYq1pIWwSRUta32JySlokA+qP2Bd7 noq8T93GWd54batM7QBVLMPr6IysgxblS8xBufxwVq+Dn2RbcvBdtCEHDzqSnDwPYsE8eBNF8dzo ddyFveifdx6z/piyXTtx+oEFe1dbj76E8xuB4qesn3eTdc9Wbbi81l3xVcz5gvU9x3brG9FVbITX Wh1fZUTDK/FVEttircAge9BXYi9YN8dPsj7n4K3rHGjFQ70mJcH6Z8co6yonyl7rXfEvaWHQNJzx CDQXxN9oHZCyyZrtrGJodqfgYG5/a7JjprUXqntWsX6Vm6ydo6u0UFzYx6YXrLE4YnsHD2V4j21S NzKw2e54Q5lhnGGEYYiht6GLIcFgM7Q1tDG0MrYwmo1BxkCjv9Fo1BsVo2QkY6sqtcYdp7390Upv 1jK9oqnC182Spto7JXB9iRklPHc8LeUcKWdYOvO0yKGcvHRPj7icKoM61NMzLsdjzL0pv4KxBwtQ 8kiLcCeZl48LVKtaGKnNP7cSY4kLH4jU8nkLHygoYDme6mLKGWfznBmG8/DHfbTOkW6h0DmpltQW N4b0ys5sRArrNe5XLHEXY2nrWZEzLN/zTNsCT5K2orYtyPH00WauW6UZ0vSszK1SqZYV5G9lt0sz soZq9ez2zIIL3ShKKkU3StEyrVslRWndKIpV8m4DeDdcplFZmRVRUXWdXmP9tE64fF7jnSbV7Ssa h8C+crUM3aR2FM33FS2107rheqjbWfDFOwskFsx3FhxIfGdttE4VTie6xDu1LhU9nOhQ4ezBmzf9 2uxw1oVTQE5+HCcr4Mdh7Nc+MXV9cBXU95GM6BP372RCehM6s8qij8cXa+8fFDqyJiAVehbPKbF4 Foyz2SrGf1z/xkL7wnHFJVpeNMHzsWNCpme8I9NWUVTcSHOx1lzkyKyg4qy8/Ipi94RMb5G7KMtR lFlQuX5+Rk6DY91/4VgZ8xvZ2XxtZxnasdbnNNKcozWv146Vox0rRzvWevd6fqycoeksJze/wkjp BZiA8rxSCvDH86Ew0l6QHmouvZE/OXrbLXdGblMIL1sBmLwHOtI9JiStKSEtIU1rwrNTawrS3iGq b7Lc2dseuY1trG8yozrEkU5xZMmanHnh36xZs8q0NHt2HLRstoXXleFJax+W48nW5rMpnpQsj7sw s4BpD8fsejLy3eZXUnalSNNT5qcsTVmTsjlFN3t2AapbvBK1K0oaGzU9an7U0qg1UZuj9FrD6PwX 3Clror6JkmfjamJlICuTH3M2cvzTimWzZ2kQDjALqe5wcbPjMvLToqgYd7sMd+YJ1BLJgdQFaRiS jv4G3Yt0FOk7JIXuhj6M9CRSpVYjJ8gJWZbJmdoRC+I007HISZWubkk9q5AXTazLh42qy7MG1eUp aUkW5N7ULv5pwbjxZrQN+jbSR0inkH5G0slJchLf+ey6q7ZgFs2KYwifUCjTZFZcGYvDCtOGu2xW XBxpSbvA8QigaxxreN0TmzWbMBR4QJChE6+dpW02W8vPozXAinUPIg0gK1IbPkMj9QjSMaQTtf3V s7pbyFE7Ra2Rta/HP1eftP9xZAWtoWg6zTrTa1QNJ1+PW51cWk59aBdtpiCay3ZiNB24w9gIv7DC 97MpjOloFX1Io2kmHacazJpz6BBrgf1kUSlmi73Uk9AcWqRuRS9/yqC/0jY2lQ2jRKz3leIxEk5a qlZTGMWo76oHUfoLHWfRagX1xdpnFIK78/n0R0yjp9Db6llEGk3jaAObx07i3qqQFitdlXL1FupN W+gDloO1gTRXd9BvC+4O/khPsjBWrR5WP6eX8Vo6AXv6Ay1CxF6qljrJGbq1ZKP2dAMNoiK0/p4+ ZC1ZZ9mtdlDT1VWo3UDfSnHSm7IBccRRPxpLD9DjGI39dAy3AgGsG+5wNmHZw77WHURsOTSbbqcF iHw9tn2WtrLOrLMUhvtDCWfYkYajbSmtw/EraTfLYQWsmr0qr9O5alPVVmpr9XNVpVjKR4Rr6FUc 43vmQh8cQY6Sy5R2Spku6dxd/H34x2g37UEchzDuP9BPLBbLEelOab46Ut2oHkcsRtw79KQhNIqm 0xz6HT2BR/U1ep3+yX6R/NBzl/KG7nbdafUhjG17Skfsg9F7GPa9GI+Sl6qw7MdZhjAbzqInG8SG sklsKVvBqtiH7ENJL9nxUnlK9sg75Y+V7jqdmow9hWozeVwlI6kEj8CdGO2HcL4b6Q3awVqz9iwB Z7Qf25+RekuZWJ6UdkmH5IXyUuWs7t7amtovan9Ry8mAq6wPxmE2PYNR+IaFIoaObAqbxY4i8mXS 83KQbJYdcjc5Tc6TC+RF8nL5Lfk9ZaaySflI109XpNtkKKq9tXaPmqPew+9P9IirA8VTV+qB62ci rqZbEF8plpk0j+6icnoQ18tDtBb3u1X0Cu2gD+gT+hKPADE7Yp6Mo0/DVbeQPYhlFXuWvcreYDvY EXZGW6QoLDFSdylVypCypUnSQizLpd3SfumE3EYuxvx7AZbV8gvyh3BpRVF1SVj66hbrNuh3GmIM fQ3jjO+c/epc7LmCc4dqqTai9qbaFbWv1n6ujlDnIn4nJVAnRHofolyFa3AdlmdwJb5Ab9I7dIDH +i2TmA5XvIU5cDXE41FLZX1wq9GPDWRDsAzHMpKNwlLExrESLPPZAvYHdje7hz3A/sSXR3Bu69jT 7AUsL7JtWD5gh9ln7BT7VsJFLMm4mp1SBylR6oUzzZD6SIOloVgmSdOxlEozpTl4hDZIldJWab/c UnbCbYvkGfIq+a/ya/I++V+KpMQriUqKMkKZpNyt7FL2KAeVX3RWXZauRLda95o+Ut9VP1w/Rf+I frP+hP6sQW/Ixe3qPMM+g2p0wq3+jvPe0uDjpkT9LjZL10q5TTqM54VFLtXdx4ZjxPRSnjxVflB+ XzeRnZZt7CNWLk+Wb1GflLOln+TpbIT0CouSrbpkeSItIZVtko5I30ufK61ZnnSSxSh/ZC9K0+UM zOg0X92rtFbu1p3Ane4BSpbuYNXSG/Ld8t3q/1CybjU7rFst7SGbUiO1pMN4Vt8nrcRG70mTpcWU r3TV/UKTMe5P627DeN8oLWKx8j5lNR2XHdJ3mF2tgGu8y/or0dLNUi+2CY57jrWjr9gMKmV/Ijfb zj5hVbgn3ihvYAOkQDxaHsnEeuC2+13ZzvbJ/nVfKGXtpdYsVzotDZdf0u+Wu2Has5vep9uZzFy4 ds5TS7fiGbBc6gBPy4Kb7GVJZKGV8Pvva1/SHFt3ULcY19njcjwNJReNkXZSMp4bx7Hk072URNtw DS4il/QIzVMXsPHw/YHwT4kwb6NEFgC3DENs8/F6ESpFwQvH4qg/wf/fhuvnsK/pd8yGZ1Y1xSha yxIlC85UCP9djGU8jUHpMXpIv0W3lwazMCLFVrsaV/nHdDNec47i+BGUgvhG0eNKPKK2wZlnYIvH avuSG8u9tJNJdAdivhHP81ylL5x3hToFZzgZr1ED8Jq4gyarKykDj91Q9W51MY1VH1dHY6Y6TN0I /52jeqk73acrkEbo4pSu8Ngd7HW8Hv2DLYZv96WP4EdOZqFTWP6K+G/Ubady5QC8M1Vdon5ArTEe URihcXgVPUbT6GuMW1+5mrrUDpIq1Gy5FK9Qh2mIukG1Mn8qUafCeV+idQYdvGcBtdOtw7W7WJko uRBvRwpliagdrVtD2iSrDa7ENtrbYfDIgRUS2y69DG8zSK94SadUSS8/L5O/QVvZwijcqNe9gnaJ ZNaR/Ngt7GayxJnPpJxLGWT+PmXguRRKxbr5LKSzyx5iD3FCWBuFztrk6rNuHf2CK7oa2x9Tj7E3 cecQiOukZLv0DIWTn1rt9uvesyu53Wldjdr7iK3a2bv6R/wUNKk7uWO7dd1ALyLeKrnfiyaDbHK3 DMB6N7eJyF8xu0O7+ruVn8LNZ776/quQFr0Sv6LUr1LNn3V2sRn8nieOZWcyh9y+W9fuXZJCW7cy yJrqHVFaDStpn6/PSExMU27tlJbWCYlNkmO7RaQOGJBjiTvrSkvQqhPStE/xF+IZ9hIiN+GaeezF qvC3wn8MlAOr1J8qHc6uPE9wdWVV6olKhExV6lvutlgJt0AiekJ+DGSGwLBAyb/NQpyYCVd4XqVB jghC7m0lE07peZPJXwnSzi00IiIsxH+a8rewaRTCQhZGtllun3I7Zp5nxpw7U3ea9ed6LiVVG/I4 NmNM/eRmJpM7XHS29otPXXJ3D5V6dorr1bJX7bgeod0S4pMjussOFj03PDw1Obnz8OLaf7CY2+Pd yb07d3iw9kPt9S6KSP8t7gFdbIf7RLCFBZExLCjcFBPcMThWcRla3MBuSCywTGcllmmJcy0r2aOJ Oy0fWU6wLywmk4X5h+ld2S65u6W7q49FDnV1sLR3yXqLzhUWJsdRR5R6U3JYL0u38G6u1KTBSSXw rzmWueFlrnK637LQtYpWup6m9a61SZ6kd8J2WKqTPg770LI76auwU5ZT4TVJZ+jnsB9dzr6sX1h2 4ihWEDYicUrYbeFvWt5w7bfsdx23HHcFBVsj/exRNmtkhD2qkzUyxh4lWSONdofZGhlqd9itkR3s jjCLJYpYK7KEEwu3WKqkHe4bXYmtXJYwV6IlkSUi9rCI8PAwyc9oJHK5OsQYXTfhsghP7BRls9nX 2j32avtue41db1/tTmJJTNJ2YTIH24JDpOHBqzsXfWyJw3MlTnuyDDSPOTNGW0kJ6ZVYi6dOipkv qVzDerGQXvcZO8Xp7jC/jtzCV+rfdsB1PWbMDEAzxmAC5I5MNP8/dr4GKqorS/fcWz8UVPErIv4A V0VBRCCCRA1t0BC0DaJNEBGRKqSqqFIooH6wqCqkqkTbsW1jpx2Xj7Ftx5exjcuxDUPTti/j8yXq pG11uWLaOIn6bEd9jq20bRvbGEO975x7q6iYpNPTa2bem7Xwru+cfc7ZZ5999t5n33utohI1L3Ji ETcrOTl+VnJcwiyiSp416kjg/M9GzRqVlziLmyq+GADLuZVk5XguPnFUUn7+yPEz8qc/XzgjviBj 8uSJM8Zz3PiREydEKEc+M8zJSj9/OHbSkrzBzLyq9KTEmFdexf3+LneD8+YuS08aN2lJ7ufH85ZN TPr8E7njaXtnWtakSQWCVdZek5mSMemzj+Ws+XRzaGDzZ9+jZ6okcEOuwHtGGpnGv/IWTz/TK56c WxwXxy+dokT88EuVqthYlBrapSRCSlIU7U1SC0cCD4vjExL4pYJmxAiUjBu9j4s1dIaQTGcI447K rpOUwPH+SLRS0hKOyK4Xx40ojozhl45IJJMmRUZkZ8tI7j3kjCtT7+UCXC6z8/ErU0/EHaf0WZyu sW8pmW4VCZhFBLVMRqeOa03hilN0KXxKmhpi1Ema6Gjl0iR5XJySaphIa0EeG4uSpyOCkJszhfGw zeHZRJmbQ8/x1LNTWYVlz8JJVJmVK8++eC9h1KwXr2D9sb8guYHj/zB/fkEuTY/zpuYU6HI9co9i s9yb+9Pc47kRxbneXJ7kJmWNnLpUsVRVOXVHBB4EOSH3+aj5UVVRO+U/ydqTG3E89/5UXhCIMP5o 4BpRB64Vv1wkLBbqBGNUk+ASfkx+LByI+EXEqSz1ZNWIDM3chNQRJSNTMpLmjktNKUnDNLU8eySz Wlo2l52dJlOnEfV4jXCEayxOGKlL8ib9NEmWlrQtiU/67ZQlSvp5QmZOAa1/Pn+G8qWcl7rEMzB1 0b3PrStxr6D/EP73rNhy/KhZcZ/ce8p9QsTqubyXOorHTJ4qV2VMmqyaIpCpchSZEZMELkuRLRAi vt/6fGTlTPxDAiRtnJWmweXLJynFBJ+QP33UjAKE9oSIjEn58YlJSYjnUYqJM+JzeBbniejg/+kl 78Id1x6/27E4VkgeMzWai58WOz5p7DT14P0cZVFDbvXLKw43rWgs/dZnJ09y8xe9+aMFY+Imtn52 5W/nj4uf2PZL7lJJ66zFpvdOf4hsibsS/3PZT0km9zMpnjOzimmAKtNGxWfIaWhmJKdx8SoarvGs Ha/UaFCmIaL7aBvEoz46DGKgOJ7GcVoijfS0GCoIvU+L1YyRi5MlJ43+HwjxZDIZkR2zOKMloytD lpEZkazBq+aLZ3MRSffiPj+O8JolRfbUKzTO4k6cmhp3Iu5EWHBPpOImY25LZFckHwkByUpoygI2 ngU11fFJH22DuNNHI5sSP6djaWlZU6QgvsLkk9wXz55difilayOGi1sEXoidzk+PLeaLY/3yiOIs TpvFpU1JTc6YED8lddTGiRkZwtzJqRklJEqdFZ8oxHHyZG8kFzkrTsNplsvwoJI8Kkqr5IqVnDIn De+pJD49LS1N4LzCNoEnQpxwWDgunBcUgm7KPgsLtZVtVmRbPJlYb7RZEWnIsPes91bG0xwLtaRQ Y2nV2kZWLl/OjRTvlTR+aIRE0EyYRDMhEiHLlFI0cWW2jucXFKRPXDYyYeS0vBHR8+YMTi2dMDpK ET1xTFpGFDdS9tNz517Kzih8OXFK3eC3yzLGpqenJ8VNjF/CNez51rjY9FbcXQMD3El5PB+Dp7CU X+CdKKM4ipAxCq5RPn8BHrBulsc9IrmL7kG98TPGy+M/uyKfyJ38NuYdxXPjfu4C5iX/I+b9nHCy f8Cz3JG3FFxu3A2kEHEKt38wgRvgJh0i4hzF2G+eoxj75MeK+qE5eG/9mjk3h9Yhg0e50qE5qj9j jor88agqbE7cnzEnjvzuaJw4h/57Qbp2con/ERc/799y0e9TfN0lf/e/6PW/h6/ha/gavv6fXJ/+ R1yKEcPX8PX/4TVNMV9RP3wNX8PX8DV8DV/D1/A1fA1fw9fwNXwNX8PX8DV8/Ve9CCGz+WNE/AUS QlazUsa+U5rKWpTmSQyXQIK/VGIl1yRaHsajIMncBIlWkglchURHkPYQj4rksW+UUTqSbOTsEh3N 93BPQr+zMUO+XaI5Eiv/pUTzJEKRItEyMkshl2h5GI+CaBSTJFpJ4hXfkugI8kKIR0WS5b+V6Ejy kqJcoqO5RYof0F9ekcuwlkZ5ldEK0HHKAUYrWf8goyNof0QUo1WMHsPoSMmGIi3aUKRFG4q0aEOR lofxiDYUadGGIi3aUKRFG4q0aEORFm1I6agw/dVMtyxGa8L66V+MaiJmMzqO6haxkNEjQCdEVDM6 MYx/JLODSCeF9Y9mc0XdxrK1RJkpYTxpYXQ643cyOovRGxk9jdH0b6Y5VZj+qrC1NGH9muBe3iQC mQ6LPAcIpJKYiAH1ItJCLICddJBW1vMSWlbQtKxHv5lx5GBkLmnCJZAK9DVivp3YWMuA2gDudpR6 cFZivJn1CqQc9VrG1YK+ekgSMEpH6gE7W0MPHjpmJWvQ10KMf5F+z3LO/kY9qOaNxIE90bVnkyq2 C5skUSAzIDWPPA+KfqvVTBow2oJxqqGdTAmTL0ofkr2EvIoZlV+hfWWIKmH6r4UMC7QQyGJINbJV 6Og04FXMo9Ka0NMh2cLKrEelZqOnivHbWb9Aytg+qDUt6BPg6VkkHz5fjnEH2lQ3KsfB/EWtb5J8 YWQS7cwrtN3KLNGMUTsu6lWBrGJz7ZJfXiZLsd5caa41bKSVWUmPVRqYRDOz5Vq2VgPKr15XbFPe BuzXwXahZ7wtKPVsvJV5qoNpaWGjrcweooQGSZa4exqvwpd23sKs2cE8Sr9RK7DIWxVa66v0snxJ 9p9vpSHp+pCfrSxi7EzzhlD8fvXuxdW/rNcLYTagOxH3YmfrBU8GlS/uVY+etWznLey0ffVORUvX f8GqBubZFqkUdyXSDrRaWSkwbdtDkSvKoZz0ryr+pI/eFKbnPZcnVJoMwqIWS4u9o9UgvNRibW2x 1tvNLZYcYW5Tk1BhbjTZbUKFwWawthv0OZXmZoNNKDesFSpamustgtkm1At2a73e0FxvXSO0GL9e XrBz9rMyKgyNjqZ66+wqg9UGRmFGTt7zQuYic4O1xdZitE9h/GBn3EteXVQZEl9JixJr/VqzpVFY bDSaGwzCNOFVe72lydABLaxmW4slW6gyN9hbrEJZvVVvsNiF52blT1/e4hCa6zsEh80g2E3YhbEF I/U2odVgbTbb7Qa9sKoDIwbh5aVlczFqZY1Wa4ve0WAXzBZhrcncYAqbi9psaWhy6DHV3iLozbbW JixQb9FjlhkMDeDC8jmCEFy8xdLUIWSapwiG5lV01pAsS5D7K1Vi7Hq6Z6vBZrdidzBb2PKYHpL1 AtMg04xV7IZm6gyrGavqW9ZamlrqwxeF0vWiqgargP22YCmUDnurwy7oDe3UuOAxGZpan9kRMnAL O4v1iDoLor6FnkQuGpG2Gu1/ZVk4OB7Mq3oxX8p6ZG/J/lH2P4FfyI7KDobJotzmUPs3TLbhC2sZ viCNyZOnyp+TvyKfL/8WylnsL8ra2bkT7wQm7jD3t3iUo9lgLvitOEUWJkN8riSB8eD96n8y9ots 8YQLBMRfvlvE35rO099OIfMUijK0BTG0g/8C+EdeDAxWLiqvyMsjZKP4rEiIBtUZ7gNC/1Kb8FsI x3+f/29ExvfwPaD/hv8b0Lv4XaB/xO8G/WP+Pujf849BfyqDBrIEGZ7RZCNkpaDny14BXSZbB7pL 1kV4mVf2EPQnsqegP5fb8Nxil+P5S+6Qd4B2yV2g3fIfgH5d/kPQ2+mTrPyv5X8Neocim3CKaYrp RKbIV+SDLlC8ALpIWUI45ctKrKUsUy4CXa5cBrpaWQ16uXIF6FqlHbRD6QDdrlwL2qncQHjlRuV3 QW9S/hXozRFvEC7i7yL+jsgi9kX8DHS/ai7hVfNUu4hM9SPVAJ6mfqd6CPqTSEiOXB65lsginWo8 paqj1NFEpo5RZ4Keos4HXaD+Cej96sOg31L/L9DvqE+APqn+Fegz6rOEV59T3wb9r+q76L+nfgD6 D+pPQD9SPwL9R/UfQT9Wfwr6iRqe1RDNO3hye1dzCvQ/aX4P+oHmD4TXPIyOJVx0XHQykUWPjq6i f38v+ZMn45mFRduKVpXsiX1VYEeVKthKVa3CjlQ1qjrQ9aoGlEZVK8p2VQdKl8qD0S6VD6Vf5UfP etV60N0qPHuqvqv6K9CbVd8DvQ22olZ6INmEhzWmgs5W52Iveeo8tt87oH+r/i3bywmUJzUnsaNT 2BfdxUiUSdFJ2Muo6FGgk+m+pP1EkR3c20RRb61fRYSGDmsTmdNoNawh5SbDKiupa6q3W3Cyowi3 tKJEIIk4NQHYQE7UEoX3G2Ybwk4KfceJDmtzeE+ICbU5nCpIKqtcIJAkiYPHG0OsRMswGkfi1xis FmJipYWVdla66G2HeFm5iZXbWLmDlQdYeY6V15vXNK8hj1g5SEtOycoYViaxMpWQ0BvdsyUv/cZC sKZ/y0jf0hT0736gbxR2r8G+CNWWJJARsMtI7GgUSSajyRgylowjKeyvMoWvmfdVfUgvzFJDdSzk f11Nn4prkb+akNE8pJtsIdvJLvIGOUj6yNvkBDlDPiCXyQ3695TkKSfnNNwYLpMr5Eq4Mq6Sq+Ws 3A5uN7ePO8T1c8e4U9w57iIkqwjHbSb0PZaLL4eOqMfOhKaoUzaJdVqTeBYE0e9cwUaxnlEt1oX9 Yv38drF+eZ1YlxrFev5CsS7fT+T01ywWTydKmJ1bKSdKBBCnbRLXr59MtUH9RGyvmizVxVLdL9b6 3YxPbuw3njZeNT4QW426RnvjpsZdYssUZUo1TTeVii2zyjzOnGcuEeevVkr1A7Fec4ZxqZr2NR1t Ot90q+lpc0JzZvMc1htrSbfMtJRZdBa7ZZNll+Ww5YTlkuVuC2lJbMlsKRI1bmUl6hxRYmuhWLfF ibW1VKxtR0U+R45UF7KI4xwWwsUcZVbSkdPwHs88V8kZOQ93iif8bN7J+/md7NrL7+eP4jrPD8jk sgSURbLXZTtlp2SX5Un8gDxPXiovk59TFCsWKuyKdYpLiqvKdGUFsvVe5RnldVy3I3IiWiMOqMap pquKVKtVW1SnVJdVDyKFSFdkX1RW1ImoO2qVOkGdrJ6grlVvVPepT6sfaqZrKjV1mm7NXs17mifR 8ujC6OroddF90Q9iNDFzYkpiymOaYrbG7EJspwdeI88HPiazgNlAUaCP+33gNe5T4LPAazwHRAY+ 5qMCfXxsgP7cYSLKSCJj81LIrMHHmFeLeSVkecBEalDXAv0Yk5FYjMQD6RiJwJw+zCnBWiWYY8Kc fPC+Bl7qbToai1nxQDp6FODdAN5a8L4G3tfAewjnWQYtYzE7DjzxqFMCPSQVo+ngnI6xkkAbKQUW AGWBI6QC9VLUVairUdegrgViREnQn0lCnQJpqUA66BJosQAogw4VaC9FXQ3Uok+aiVlxWDcedQp0 TwXSMVoCPRYAZdC2AvVS1NVALWbHirtka6ZIa5ZgZok0Mx8z8zHzNczMJ6+ivxL91cBytHnybazb T9pgm1hIjAt8iNVfIwtZbxnNPQE3etzw0s+wD2pTE/b9GllGOUAr+GmBfL4QKAO+M9jFV0JuBOZF YV4U95iUcZ8OvgvPx/Dc4Lv8GNhLgVjYjZ6ziIXdiIMexEEPkdFetIxoGZEnEQ9cduAgNy1wkFcA kYE0Pmrwl3wskBSw8bArnx6wkZHgWgiuUVxOIJ/LDVRxzwXGcvmgPx08jFUI1j0MCQv5aCAOWiYg AkcAycAYYGygjk8BBIxloD0FO+CoXsjVMhZNaX+WJgrKDY6PwWHD/HnYyTwSg7k2zLVBvz7o1wf9 +qBfHzht4NwHnfr4UcBoIA2YDEyFV5WQ9yu68rOrMm+lwb5psFkp9qiDJfG8yNFoFcLiuVSK512I iF2Q9DH0+Bh62KCHjcsDngPyAeanQC1kVULWRLaLaCAOOsYDSfBSMvSC/2CrPuz5COxlw76P8JPQ zgSmoJ0FvcdJMfkEGlAteWhQCg1K/2JPJQWe+5Pe4mGzY7DZMRIF2Z2Q3QnZnZDdCTmdsOzH4O8E Vyf4O8HZiTnByEui+kq6Lfz3jSLY+AqJh8x+yOyHzH74aDXk9kNGP2Qcxt76IeMwdOyHnO9CzklY tx9yaCT0Q04/9O0nakgZgJQLkHIBEgYgYQDxcgGcF/gJwGS0p6CeGhggkZA9wCdi38moxwT+D+QO QO4/8xPRlwlkIUqivhSTwVikcUg1mMD82sc4L4StfgGc4StfkFa+QGNz8CYy0U3yZqCLHAicJb0A h1PUg6en/kAZPxcnfwFs/wpQhvYioDzQhezxS34ZxmoCN/kVgZ28FrQJ9RrUTeBtBiyBXhLHzwbH nEAvX4yRl5m0B5D2ANJuQtoRSPsNvxj938GMSvAtD7zN16FtwHgztImBhK4wCb3SzJqwWT/ErB42 qxljLUAbZo7DyRqNmB4dvjtIGw9p2BnJhzQjXwruBeh/BfVytGtA12KVOtDagJ5fBdoA2oi6ETBh 7mpo1AzagbodcGL1DmRCBZO6iIzml6HWoq4nNOLngno5cJOoJXvS1c5iH1ewj3+B/nfZqisgRQsb Ujs2Iw+ooOd67Pom5u4DJ90ttU9v0D6wTVDWosCHsOQ+cNzE2qOZX7TgrEdtglzRL72Qa+TXYqYC 3NRzlOsBOM4yW4u9WjaH9cCOvdB6NiTMAUQPIBqwwqLA9/ly1IuR0b6D/uWBZuh1Eyc0NkBgdYLn 7DI8aZeRA7DF7MEnkGCEhCOSNYz8AtRUUhmTdhZrX4G0FkjqgqTekB5rMb8DesSE9HiZ7fgmuH/F 1q6ke4EUavE1QJMYO9D+JmaPhiaxOOHxwJuI7AOYJUrqYrsRI+Am1r/ArCtGQA+z3yrQembtHkQA jXEjb0b/amANs2cP4q2Ht7Fo6AmLhl4yGaerF6erFzm1Fzm1F6vDGohFFoeDHdDgOUQE9e9odsrK cXdaxuJwNHzTBS1G8ysRb3WDv4E2UbwOdD2wCmgAvx61ATxG1I2ACbSZxWcZtIuCZvl8K2grYAOc QAfOQ6R0pspCfihjFtXDml1YnUrtIRFStO5EhPVCtzKmm4nFPp43mM1M8DjHNxP6yU4/m7sBT0iU mh3YjxVWw+NdkNOLlQ7B0ofCot8I/zVjxbHSnn9IojCjkkWZGCNdTLdy9C+GFssDPwhFPo3JXimi 2pgXg7tYHChl54Ry6tBnYNFuIAmwzE1Exq+g/U5ExiFIpTw0ynRM6lnY8S471y0AIp+3o68D5yJW ynM3pRkPMeMky1BGxKwJJ2gN+prYmTmKvHczbPZNvHlIeQize9h6BmhglKKbyueRJ0bTOMezNd1H DaG8N1nvGkQ/jWUL6GBmi5BOrshBpazBXQIjWPMmvFuHlg6go0ZkGBO0aw78Gpo9ANeH4LqCp/83 YYsaZN8VbE9npVwRzOH0BP0LZtBTdJjlDB7cD9h50mCFk+y06aRMbcTdimoqzqMWpPN+Rbmxw39G LgvuR+T+jcTJ9iPunO06eIrr2a5vhu36Q7ZyNKFPnPE0T0s20jHu0cx/iEZ+tZQDmtnZz2ceiA2d /xS0UgGak4Z82iVFAfXMvpBnLJJ3lFLUiRnRAlu2BX7J5GokGb1h9qN54aQUC730HgjuHli8l9mQ o7rCkk2sXw9P1gV2YOU+yP8YKw8w+S2wOIscjO4Mi86bzGpBDpqbZaGd0Z8hoc/yM9CagX2exT7P Shmnl93XeTKN/U8OIYm4OJJO6OerU3DJSC4uObyQj2eCGbiU5HlcEWQWmY34LcIVRb6NS02W4tKQ 5aQGvqjFFUt+hvePOPIuOUESuKncNJLI/Z77PRnFfcL9kSRzn3KfkrHcZ9xnZBzejzmSwit4BUnj I/hoIvCxfCzJ4JP4USSTH8uPI1l8Gp9Gsvl0Pp1M43P4HJLDF/AzSC7erOeS5/gSvpTM4hfgtBfx C/kl5Fv8q3wlKeGr+GpSytfAut/m9byefIfHHZtU8CbeRF7lV/OtpJJv551kBb+R30jq+E38JqIl XGRRpJ9+NkyukgJCVrcDHsKtSUbtBzaBTiWkTQd6Kxsjq7cDPcAeYB9wEOgFjgDHwJ+O+gRwWsJ5 qb4o4TJwXQKlb2NOFuoBqX2ZcMZasV6Th/qhhCeErIHr1ijRX4haAySIcxgtgmvbH6T5UY23TfdN N0xPTQmGLIYscwxDoaFchFlgqDHkMRSaJ1MYmgxZFKZyCYVml+mq2ds4YHrU+ND0tPGJ6ZGJQG6f 2c6gNPMmjVnF+ArNXlNe40UGJfg04es3nmfIA70XSJYQ5E8FDRgqGy9SDOlpIBKCejM9TUWgGSgN LDDPZCiXUEj3BBRJSDCXMBjBSxFsN4FuCrUXhuRTOqytf/inYVoAXYzAOv1lUzfgBG0FNoOm2KW/ zrAXe6NYZ17CEGz3QUZfmP2lfYfsccpsEqEfYDhjSGUI2u99amNgP/N1rekSfEMh+Q/1RtQbQ34Q YyLRtB9z94v6BH0b8nHQt0FfBmUGfR+UnQ5ZgEEHXXVf4ctnY/CbfP/188cwPOv7eaAZKE39FYqd VAnB2Mlm+Fp+83SGSsRPpRRPDPrbDJUSgjG2wDyHIcj/LHSIO11YDBZ+A4J886QzGYxRK/ZOEYph 0MawNo0XigTEV4KhcCiGv9gOxWol9loObMOcHUAwNin2G5IZQvEKem9Y+xD8QRHiN1cxPDsejO8g isT4/lKeqUGb4jhoiqOgjzIdsxj6EMuAocm8kyK0t6H8JLaD/IUUiNdyQxEDG6e8mFseNn+IX8wv Qb2/sW1eRWGoNFdR4Ax2M+TR3MbOVSpDuoQz5t0MUqybXzekUoTFsMBA8yJF8BxTBM/bs+cuiCIJ z/bXSBg6+8HcLOo4dH7FnBCsr2KfVw0JbL+0/lJ8GTYzSDY0bwnmOOyf4pTZgvO5xPT+kJ0br5vu mJw4CxTB+M6DT/OkMx1+b5DOfevlxvMUQ+Ot1xlCeQN0Xng7ZPsg/22GZ/PMs3kjeO7nwf5AW3pb FoVpQVseQ/BcPnOvCO0bZ7J1AHgIGvm+9Ykhq418uT10VqAjxbNnR7JVG+K0rXAoptuK0C4aaofO QDfuAxTrcB+gONU2T4RByXAGvqOQ7NK2wJDKoGy8SBGMzTYN2pqhGA/l2+AzwbP3Tmn/eGpSs8/C CfsUXMU+/45UFCgKSIxipuIFEss+pR6hLFe+SsYoq5TLiMA+n57APieexD7lzaHfH+R/x9+HlDTZ BPrjMbI8opTlywpJnMwne0gSFZmKbLJJUaS4QL6v+LXi19wkxYfKF7jJyjnKl7jvKWuVjdwPlGal mfuRco2yiduttCpt3B51pDqS26t+S93H/Xd1v/rn3E80nMbCvUk47j5fOPTEp+sGNrNPtIhuG7AD dDYhjRbQu9gY0e0F8FSlOwT0AUeB48Ap4Az4p6N+H7gk4apU35BwB7gvgdKPMGcm6qdS+w7haleL df0cQup5CSogBsCzen0J6jGAIM5htAiusT9EjyTZeF4vIeWkmqwiTaSdeMlmsp3sJvtJL3mbnCLn yUfkLhnkVESm26Tz6Lbq/LrtK48QXjdHV7KioO4JqALd7BVZWjys67J0eXWWulugBN3kOn3dAKgk 3TjdhJrToDS6BF1y3TVQvE6li6k7RnjtY+2gTl53Cn1E+1D7pO4A+h5p72jv1/WCuqu9pr1VtwPU de1F7eW63aAuac9o36/DU7j2nPYd7Xt1m0H1ak9rj9V5Qe3XHtf21bUTOSTf1X604igkPNDeWhmF nrvaA6APY6R/ZXXNbHC7tF7txjr4V9uqbdd66ub8u0Wpgn2ng7Bvc3DKdcoNJJJ9ryGefSthBOIq mfPjnUpDjsEHpI4CcVEHP0MLYkhCXSL1LQSWAFUAnvTrVgEmADFXZwdcgFfCRqneIuF1YKcESu8G 3pDoIA5IOAwgNureBt4B3pPG3/kSsle0s8ujX72iXd+6wr9i0wqPhHZg64rtuHpQb0W5B+hhLUrT crt00XH0LC/X38Y1sLySflMH9n9ACP+Q/wTvvX+EL+TMF0rmiwjmCw18MYtEK14IeSQOHvkOGaV8 FX4Zy/wyTlmjrCGp8MtBkqY+BO+kwztPSYZ6UE1/J/o/byWOFBM783UO3o1JLd7kam8DeIOrxZta NXJJLd7WVuJtrcFKVDULa5Ysex1lVU3VsrsNO+ln+fwf+D9A00c8coFitgKxq6xQVhAZYm85kStX IAIV6r9X/z1Rqj9Xf04i/qI5XMLACPqdcA13DLmA2OB7G+Km4SoDb4hDG/FjQ/zYEC82xIsN8WJD vOgRozbEhg0xoy8RYTsn9VO+D0Lg3KmEX7ZOBOKcN4xD/0eoJwz1fx0MmUDOn8FXAGDHhmLWZnox XJN0o7ogTzUgL1ed/sJcke8ufCLH/FKp78G/HbVxTHYIQbm2x4T3PSW8nw/tmdp1aP1B6DiTgbX1 2V8LNo51UPNXrBUdVm+VtbrD6a211nWs866y6ju6vSbr6o7NXou1tWOb147+Heiv69jldS01duz1 eq3tHfu9G62ejkPeLVZ/R5/3deumjqPendatHce9u8HZDf7WjlNsbrf3Dcg/A87tHe97D4C+hLV6 Oq6CZ0/HDe9h676OO95+cN73ulBeRXmw45H3bWtvx1PvO9YjLt773tJdLpX3nPWYK8b7gfWEK9H7 kfU01vVaz7vGeK9ZL7oE7y3rZddk713rdVe294H1tmu697HUM+CaiVUeuuag5zzKcyhLMOu8ayHK J64l3kEbcVX55Dalq9YXBfkLIf+8a5X3lk3jMnl32xJcFl+cLdll9yXZUl0u3zhbusvrrRJLarfm S7YsajFbnmsj+AtdW7yrbEWu11FaXe953/lC6XSdC5VWWtLd+TJt61wfeD/6QtnNys2uj7x3UV5j 5Ue+HNs21rPDdcv72LYL5bkvlHtdd1n5AOU612MmbajsZuV+16CvwDbPtdM3wVrHtD3klvtmY9eQ 4Jjgfug7YVvg2o09lrOdijs65R7nK7UOuCf4ymx97ihYoxB7dIGT8mS53oAFRLrSdQC02FPjOuz1 SqVOovtRGl1vQ2Z42eR655nyjDsTHhRjjHnT9r47x3vAdsldAH9ddc/22peWu4t948S4lfZlxFyX 7SjT8Lg7Tot+d5Kv2HbDXeqrsK1zl3mv2e64KxA/iElfNfV+k99mdFdjxfs00myPGP3UXed9T4w6 O0/3ZVdRD9JT03yKxmez0R4DzU3WY249IjN0dnx1NEqXbhYtYE+kfrSPobuwC+7VdEfuVrojd/vQ 7qrTsbsbNH7sk6ln7dmMns68bGT2Z/61z3R7vFvsKrffO2ifw+gSRi+klrEvoZahp8ynZ/G8Glba 5K21V7m3+qLstdSq9lUsBppYfLKosJtgybdt96kl7RZqVbud0S73dl+r3evu8bXbN7r3+Dz2LcwO r1M72HdSK8H+ddBqN6XtbzD6APO+070Pq2Qx2soiuZKdESejH7lL6erMF4WM7qY0zTbNl+yH3QfR b3T3el32fvcR7y1dtfuYtsr+tjtJu0WMIsQDToH9HRZR4olgcYV+nBSaqSxv05hZvsr+nvuEd6P9 nPs0MgOyls9P84NljP0D93kty2C+TSInzWC+rTRXWMZI2Qy0b7v9I9cWX4/9GjtfzBf2W5SmmQ3S kEN8e+x3mf0fUPvbH7sv+vbZB92XfQfZGVklnjuHPIyOGrI/zYfNl2jm8fU64tzXvf2OJPdtZJKh SD7iGOce8B1bq6Kja2Po6NpERo9htMDoyeGz1vl9SdY69xNk2vMeAm17PEdBn/Acx4qI4fUbaQyv 3yKddJadxOhdm+1KXP/62umuN9bvlHKReKK7mU+ZndfODNq5eT+z3sa1czq61++mOXb9G9KJZhFL d4d+tjus9U5o18j26w9IeTVMZymriBmG6YYTRDNnzZDfnUlD8p3jqEznBCpTV+ZR+k47Lnoe+a22 /R6Nr8CR6UnwnXfkrEzyXXQUeJLRk+NJ9V2URmd70n2zHcWeLN9lR6knz3ddV+0p9JocZZ4i321w zmOzFoCzwlPuG9BVUM86qj2Vvoe2454a3xNHnUfnJw69x+hXOlZ7mvwa62WP1XvX0epx+hOgzzpt laPd063d4vB4NvuTHX7PNn+qY5Nnhz8daxn9WY6tnl2+Yknz7Z69/jxHj2e/v9Cxx3PIX4S5fchd yGP+ec7Mjve794h3K8c+zyn/AsdBzxl/uaPXfdlfqauAtvscRzzv+w5S2l/jOOa55F0FyVch+YTn hl/nOO254zeKd1jxXuY477nvb5LKgq50X0F7cleW30q16t7nzOnK6z7oLOgq7O51zu4q6j7iLO6a 133MWdq1oPuEs6yrvPu0s6Krsvu8sxr9F511XTXdl8V7tFPfpeu+7lzdZcSdRXyKYPdrZ6u7tPu2 cwI7+1nr9nm3ONvXHcTdGU8L6w+I8YOTsgWxsdd1a/0bTk/HI//xpeUu13qV009PsXNTV1P3gHNr lxVabe9ydj+kMmk8UJnOno47vvPOPV3rup8ghkMZVbw3OfexWBLvU+IdmeUo50Ea5+A/EIr5sHwS HvPO3qEMEJ6ZnUdoNnYeY9mYZWnnCUpLmdbKMm122KkPy9LO013dG4jzfNfmDcrwvOe82LVtg8Z5 uWvHhgRHe9cuXwH13YZk6rsNqXgCoafjDdd7G9LpyV3/WLrvFLLT0Q2tPgo/TY7Lnqfw7PVO3u9E qUJJo6tA6melbX9njK/YcbszEf3sHDkGOsf4Hjoedgr+dVL5pHOyv7uddGb7N7crO6fjFICfPVPB v+2azpn+be0JnXP8O9qTO0v8VvsHnQshs50+p9HSV9ye2rnEn9ye3lnl9bZnddbiXHg6V32hrGzP 6zT5d7UXdlr8e1m5nz7LoWQ5WSzbizrt/kOOrZ0uxO28Tq+/r31B50b//yXv6+Oiuq5F9/mYL75C cCSEIqGETIjlGuARHEeu5Vo48yUUZgZLjEFqjbWWEGLIIF4YJnxYa43Pco2l1vqM5VpLrOV5qdd6 rbXUWq7P57WGWGq9/ih6Cc/y/FlrqM/w4K21zjnDmVGjTfv6z2X/1trrrL332muvvfba+xxm5hz1 lzZvaT3h9zXntp7yL2vuBOxr7mo9469u3t16PoS7W4f8q5t7Wi/7a5p7W68CPtx6FddX6zX/uuZj rTcUvL65v3VCoQPNA61J8qzBuM5CvwnNg62T/vbmi228f3Pz8Iot/m3NoyuW+nc0jwO9q/kmnB5T 0XsJx2loo39v8+0V9YCnEAdEnIVAVJtZPkX79wfi25IVOx8MJLalVW8PpLRZ/H2B9LYs6H0RWPJo ILMt9/XTgXlAK3IInwjktVn9pwK2tkVAF7YV+c8EpDaX/3xgSVuZfyjgaVvqvxyobFvuvxqoalvp vxZY1bbGfyOwtq3WPxGoa6vHPeINP+0RvQ1FAThFwL7JBwcbXI3r2w7jybytE+8d2o4R3d9Qhmeh hqV0Sm9qbK/d3bB8Q1zbAJ6L2uj03jbYsBLoi0i/sb1hDdDD0DaubZS8d7yhFvadm1pPrq8NbA3W N9QHtgeDr4uBneDVe5UzA6yRhg24RvDeBOIG3AW0TSn8YGCPzIddFfjtItLtUXSnMKw9GzRsxPjT sIXiD5wNQOfODblvHCK6B+n2eDwhtCcqe1xX4FB7YsPuwJHnNxI/Bfnt6URnEj2voTtwPNjV0BM4 Gext6CX6MNJ4l9Se13Bsg7Xd1tBPdwp0hseTRm0Z+nN7IdLtEtJtg0Qvkf38tcuB08H613YFzgWH wSZI70W6oQjjTMMAxhk8jdTuxtNIu4foHqIrG84GLuDJJHAJToZw4m2vQg9vX9UwGBgJ9jRcDIzB icVF9DDSWL+9CutDnSK8X2sYDVyHOyOIV+1r0fNr8Z5xqO0Y0u112jhGe32PvNfPnGoqNiPdTvdW 7f6G8cCtYC/ofwfmCO4BX76Md1ttUw03Z84weFfY3oT3X7Vlr+W3MJjT2y16WEcyPdUS094KkQ3P DH14ZlgvzpxgMUK2b8L11b6V6O1IV1STJ+xcH9WS8EZUQ3JLEth/F50xaBdYH9+S+sbxjlMd5zvO NM71x3TsQBy8+dr+lr0Qu5pa9rf6Xt/acvCNwvUjLX0dc/2TAX/bhgY+0NQWXD/WcrQje/31lhMd +es8Lac6CtbfajnTsbiioOV8W7dywq9sGepwoOU7SlGf5+vX32m53OGT73CVe1v5rjb8jrVIvUtt ZC1Xw+9VlR2czg+N+pZrHcsaY1puvHG9MaFloqNajquvnWmZhLsMkuNPCPKtk41JQWPHalqzo/JK xH47apS7aTgbA4c8GTXpWKfE25AmHeu1EZLulIfxHrkjIMc0jBgd7fL9tRyXcC23+3Hv6NgsY5kj 99KYusHYZm7MCMZ1bJM9BHcN4GQHzR27lKcT9MSgMb9xXcde+elEY0EwGXxMfhZBd/2Ni4NpHfsb HUEL9Cg/cyC7yU8V5HNm4+pgUcdR7R2lQsvPK6BVx8HG0mDWy6sbfcHcmuuNy4LWtuTG6uCijj78 NQH69hfTfPuLp29/icbFxkqmo298pdA3vj5J3/jKMPqNTexZY4vxayyfvs31Gfo2V1n0M9HZzBf9 v6J/x5bTN9BW0PfN8J3kuSyD/S1jrIi9yJLZSvYGy2NfheRj29jXWQXbw95mn2P7ID3PDrBetoz9 iB1lK9gp9h77PBtm/8FeZe+zcdbAJtg0a+Z4bi77CreZ28J6uR3ce+yfuH/nrrI/iGvFl9mHYrf4 XTYtHhN/ygniGfFdziSOib/jHhUndAI3W5ehe4p7Ur9Zf4x7Sn9C/1OuUv8z/c+4ZfoB/S+5F/S/ Mui5lwwmw2PcW4Y5hlSu2/BJQwu3z9Ri2sjrTF81dfKxpm+YdvKPmb5tOsB/wvQD02n+U6Z3TRd5 u+nfTRP8Z00fRpn5L+F/Uvi26LjoR/j26ITox/iN0Zej3+e3xLwS821+R8ytWI7/eWxybDL/bmxK bDo/GPtM7DP8b2KzYrP4S4wDu6ylJ6Wp+J2ZklUKrGXMvpUll1SVrCpZW1JX4i9pKmkt2VSytWR7 yc6SPSX7Sg6UHCo5UnK85GTJ6ZJzJRdKLpWMlIxBHXxJtkBzy4yfMX6G8UaX0UXfVUvgs/gsxngr b2Ucb+NtjOc/zX+aCfxi/jNMpM8M6fkSvoQZ+Aq+ghn5z/HLmIlfwa9gsfxK/gssjj4tFM+/zL/M HuVf518HmQ38BjaLPjP0GNg7gyXpf6n/JXscxjTELtPIEvCbaY7TbKXjjpM59c4YZ4IzyZnqzHDO dWY7850FzsVOB3BLnT7nMme1c7WzxrnOud4ZcLY7NztOO7c5dzh3Oc459zr3Ow86Ljj7nEedJ5yn nGccl5znnUPOy86rzmuOEecN54Rz0jHm4h2nNemcki4o6VIojcjJZXRcd8U5brnMAFZXsivNZXFl uXJdi1xFLper1lXmWuq45FoONVe61uB3nAz/CNZMDPNz/O56HqsDr7WxRvD5xeTnbvDvXlYCHv4j Vgr+/R77LL0FrIxsVG540vAU8xieNjzNKgyfMnyKLTX8jWEe+5wh25DNnjfkG/LZMoPNYGMvGAoM BWy5wW5wsBcNLxiWsxWGKkMVrBeO7YKVhFZOx7feS3EAZgWSAdJYgRQvJUopUrqUKc2T8iSbVChJ 0hLJI1VKVcBfJa2V6iQ/lDZJrdImqLcV6O3STmmPtE86IB2SjkjHpZPSaemcdEG6JI1IY9J16ZZ0 x87senuMPcGeZE+1Z9jn2h32xcCbK+20Z9vz7QX4fTDjq8bX6Vt/UWHWaoSUx/4N0nPsCqR8elfc fDYGyWooM5SxBYYKQwWzGVYZVrGFjINVRL9WwuYyA2NlLoAyxnktkC8FWM64wnUANUJuWZE3rszl NRMgXeZNLlvqTSMaYbnXUrbSmxUqW+PNDZWp9bAt0liultV6rSEa+fXeRWUbvEVhOcpGGiHodRGo 9EZvWahMBVUXtR4CyldplLkFrrcoOmG/6jUClj8sqPpo9XpYUG2EOqg8rR5quao/8joVXTFH6IKx akHbXguoG44T890wB2ifTsXeah9blBznSHuN9lyqtEFdsU23kqu6qXJU2/Z4l4bNaacmV3Xp9S6n /LB3ZaivyBz7wf7VXNVdHQvKO+Zdc1e7zoh++721ZQPe+rKz3g0hPbsjxnIvXdXxaGVr7TWouUb9 UCc174q4Vn1S64vqOFTeRW+wbNi7MWzeMXfdZ/z30kl7ra4vlQ9tPHNlXmQe1nbUu6U8z3ux3OYd DpvXB+Se7IcrD6sXae+HyKm9eh1p50hbfFQ+GHEN475vXqTJNXI8+bKdHpR/pF7acdzL39S1Nu7t LLvp7SJazdW4rK7B297dobIpbzf6Srno7dHG6/Iob295vPcw2UzVC/ouT/QeK0/x9mv9rzzdO1Ce 6T1bPs87GIoPSjwoL/SO0vrVxhfsT/KOU9sl3pshPwf9yj3e2whkt1LfufJK7xTRPt8FzzLfJfRX T7VvxLPaN+ap8V33rPPdwmuK89DesxhioroH3WsuI+dmPfSlxGlPYKaPUHm7745ncwW7ay7u55td EWv7QfEqslyxkWdbhd6zoyJG1Rtt69lVkaC1VUiHsvvEIbRnlU9ECO1rqp+o5at8UeVrffEEdb7E cr8vRbufljf50sP2W80+W97qy4zc38o3+ebRXKigytnqy6N8u89WvtNXWL7HJ1E/94Hyfb4lCBTL VN4Bnye0hpW9tPyQr7L8iK9KG9PKj/tW0dhO+tbed19G3zvtq8Px4hjLz/n8IZkXfE1ae5Vf8rWW j/g2lY/5tpZf920vv+XbWX7Ht8fDfPs8et8BT4zvkCfBd8ST5Dsetneoa0+bq3tJZBy+Xx7pX2UR ucrHuN91D3+6314UuSdBW0+B4q/3qqfZT6meZi2Tv+K6g/lWczqbYP6gcX5UrMV8t3LWUHN13bgi 1lHk/qeeR+Da4wjPQ2eb4N3juGu/fVh9lfLQXhm5r97v/BE5n8raCvWHMQ3s/crJV07fdbbF/vZW JHlSfSc9Gb7Tnv0VqZ6DFRlhZ0aUi4BjRll9FXNDaxjtpT0fq+tPPYco+niOVmTjPuE5UZEfWvfI P1VRgOtP295zpmJxSL9I2SDXc77CQW2HNOtLE5/UWBQ6O6POlytKQ7a4WuFT47vnWsWykN0UnT03 KqrDzkOKHb18xbqwOUb/UPdEbDdRsdozWVGDd/HGN43/lbHoHPoFofHocYa/mGn56z5f0Qlsmp6j rKDnKJ/Xn9D/jNtOT1C66AnKXnqCcp6eoPyWnqBcMbVEmfnF9FxkiJ6L/Jqei/yGnov8lp6L/A6f iwjJ+FxEyMTnIsIz+FxEyMbnIkIO3NF2s56Zpwe2Auaw+WzLbNW21bYa2zrbeuuoLWBrt222bbPt sO2yFdj2Auy3HbT12Ry2o7YT1lGoccp2xnbeNmS7bLtqu2a7YZuwTS7kFxoXxi00L0y2LV6YttCy MGth7kKrrXThooVFC10LyxactC2mVAqpgJKDEl4tJkAaAJ8EGJ/Hz09G3NtugBlpZi1wV3sQ0gK6 z7WxX7LzcCc7COlvuX/lTrNF4jnxXVaIz6ugJccqWdXMeLNvsXR1pDDO1ZCvBgrHixwcM456L4x4 rzJqGDOMdy+M+BSkANRab9tLOq4CHR+j77Ix8B4L8DIh8XAvjb9jmgVJZPPYs0zHclgu3F8/x6zM BDoVsVgmQYpjDkiPMBekeLYE0qOslH0WNC1nHmYGn6tkifTrhsnMD+kTLAAphQUhzWFnIKXC2N9l T3BxXBz7JP3aVmBmrDmJQm5xf/FA8dniweKL2dbi4eLR7M7szuLx4pvFt6FkKtsqiVJUTqEUXzyF zzKK+2eeZuQU5thyKqXC4oEF3ZJUPIBPNooHcqro6Yb8bCMx+6bkz76NzzdAWr+0qfgiSgVZ82bS sydADqUF3Qu6c/Kk7ShFTdCrmrZCu505VfYMlAVSbksHQHI60BcJLqLupP/UTFrQXXwzJw9GsBb0 bi0elPbACJpgXPuKh6XC7E58ylJ8VrIh5BSCjvPwmUvxINCD+OSl+GKOrfimtKT4JkoCQHshTIFu UTBOAJKOT2jipTq0E9kKekPInpIKpRGUq/ZCElUAHRCkMchHQSpAdueCbtBrCeb4vAdoqXgcn/rk SM9eLu6366URewz2L+tgT6D+47ODat8I+GxISpH8NNpcolQAjtwaavbbT5Fud8G9+PZT9jP282H6 awDLUGf7kP2y/ar9mqqhFu7FR579hn1Cq31oFMC338BZlgH1QNuo+tvnOvOkvOKL9mwpjyDfXgAW HrQvtjukefZSu8++zF5dPGxfba+xryPPBj+1r7cHQBJIsLfbNy8Ylyrt29CGIGeHfRda0r7Xvt9+ 0D4XeoU5tPfZj7q2uXbYT7h2ufa69rsOuvpcR10nXKdcZ1znXUOuy66r6kxiD/Yk1zUE1w3XhCTJ LbDMNenmZf9RLKpYTp5x8K3QnMp+FfIl8C230R2H3uE2u5OlPdm33WkowX7GUUYt0D7xxRedNinP WeiUnEtyCp0eyeasdFZBWmXPcK6FVGcvdeY5/cUDzibocSX415IF3c5W5ybnVud2507g73Huy6ly HnAech5xHod00nnaeU5a5bzgvOQccY7ZM0DSdeetBYedd6RECEt6V4wrwRUjrXUluVJdGa4M5wUX zInzSPGUK9uV7ypwLXY5nH5XadEyLHH5XMtc1a7VrprsKdc613pXIHsUYg962wDM3qT9vIN3GB1x z57AFegwO5IdaQ6LI8uRbO9z5Kr2clgdixxFDheOPtuaU0l2p9XjWKquIsdyx0rHGkct2RXmpHjc Ue/Y4Ag6Njq2EHQ6uhy77QkQRTwhoLmxX3N0O3ocvY7DkZ4KUaMSQZ4f+2UExzFHP/qOY8BxFnOV xljgGHRcdAw7Rh3jjpuov+O2Y4rGoc4rxEen6IzCVemMt18t7s++jUCzCX7nTHSmONOdmY4gPSdu kuY551WnYbR1W9xZ7ly31dXu2uxe5C4Czc/mxkCcine73GXupRJEvJxK93KwaiXoKkfjVqnQvdK9 xl0LEuqkSne9i7k3uIPujcAPure4O91dwN3t7nb3uHvdh8G/k9zH3P3uAfdZ92COzX3RPewedY8/ e9R9E+Mfxlz0XdDmtnuKbAJ6L4mXoyXYKQpiad0ScUkU7YUv/Sc6Qa1hdfTMHH/zm+VuZByAObcV 0iZIWyFth7QT0h5I+yAdgHQI0hFIxyGdzL2TexrSOUgXIF2CNAJpDNJ1SLdyb+GvDBpXGKvp1xSL mR3s6mRuOFeUwOlAz7xgvWiw84v4DZCYsZibpBH9r+u5ScZZaxjL5yFfJ+Q+N2Fd/dykAkDn8wBG mabrOACzpixZU6bWm5RpLA+VpWlobGcByIrI4xQaIVcBlbZqylRQdAnVy1LkZ83IVPsknTT6UD3L nwC5ERCpy0dBskYHjZ4hPZJn9NbaKGQrXhmrBrTtw2TlKvVzlTkwz9hb2wfpYYy4jptpQ7paZvJQ PUtEvihiTrW5qkuRkrvu1iGUTyrjmgzXI0xO2T3GENnvUoDlACs1ekaO5V663sM+98tJv9yPyBWf DPNFPoK3BqD2/naIHP8DddKuL3XNpIWvvcg6lNcD9AMM3Gd+/4L5/ez+0HmEnR92vu6Z1z9krrWx YqcH5R/Zr+UB+itrLX8DQFChgzO+EfJlrLtRU2eLYqdOa3i87gLYbQ3FjJBvdAP0RPTdC3AY4Jh1 Jj6ofnjWSus3LL5gPqi0vWgNX4/DCgBv/hHIRxX6OMBJ2RfnnwY4B3AB4JJ8TXEe2ydr9qCHWZPD 1lCc1vahls8fARi729b39c0H+VpEvLpnXEJdrgPc0vDBtvPvhNsqUoe7ZGHZuALqteon6vVNgNsK TEEfojVsP50fpamr3ZtQx3jrXfvb/ERlLlRQ5aQoeTpAJsA86117kxbm58lAPqTybBr7Knvp/EIA KXzc85fI+s73aMYcAVh3fqU8Xhzj/CqNzFXh9pq/FqAOwA/QBNAKsAlgK8B2gJ0AewD2RewdWffJ 7zFX9/XPh41xxnv705+6J32kHpFrWJsnK/Mdkf9ZsVaNJZr8rvVzv/3/QfkDxvOx9f2oPfNh5jUr vH81NlUmhvu9mlsZ+N0BgENA6wFilH4nNf3wyphBljXBOrOG46zh52N1/alnY0Ufa5KV9glrqnVm 3SM/Q15/2vbWuRr9ImWDXGu2hqeuR218UmORZUYHa/5MubVgJr5bF2vspuhsdUT4iWJHa03EHBtn 1iK1KwXwWVfj557o1+7Zf557TW4b/ho6i+HiWCFjlh0AuxjL2C2DZS/k3ZDvBzgI0AdwFOAEwCnG UgcgP6PAeYUP9VKPzcDjrXI9qjsk10W+5TLAVYV/DeAGwMTHgElZjgqqvKd5Wf+njYpsgKfjwutG tCu0JFiSLKmWDMtcS7Yl31JgWQzJYSmFax+kUssy4FVTWm2psayzrLcEgC61tFs2W7ZZdjw18tSI ZRdizGXKspfw/k/UPp75eKblIMhbZnF8ot7SB+mo5YQmHcTPet79SV96w4NI73aYTe9wSKR3ODxO b29Iofc2zKHP+KbRZ3z/ht7VkENvacij9zM8R+9nyKc3M1jpzQwL6J0Mn/6r98dxCZz8qdmj7FOM PVXJ2GOnZHiqCmAVwNoZ3v3gqToA/0PUawIA/3tqk3ydYYwo3/pgGQp8KmM0Yzwi3Xx8bYi+reVn TKm0psY9E77tjT7JzegNHvK7O3T0Se4o+iR3LL27I4ne15FCb+qYQ+/oSKN3caTTWzgs9OaNTHrb xjP0no25/9/kcuwg65v5H9AT21lJet7sKTmlewBsoavCdEmhqIZckr5ELVdbAK5Mrwxx8jCFl6vy VFkoSZWjSABOok1tp/aMTw75HWALPb+H/zGE9Z/yP2ep/C/4UfakvkHfwD6D0ZMVRf8o+gQrpjeH JAEkKO/k+GSovQjtIQ7y+/ijTMcfA1nJ1CYFaiQSVuxhvsU483Vq923E+FYZZmWLNDXOs4TZZ2fn modm56YlmIfMl82XZ/OzefN581XzNfMN8wSlSZKBv6gRxX+X/y70/X3++8D5Af8DxvOH+ENM4H/I /xA0+xfQRgdjGmBGGk0UaPZjFh39E9AvHlbcJm6Ant152KPQu4+xtAyAuR8B2fct48wFrGR2ipzM ceY4lZ69afYmuo6fHW/OMmfhtVJrHPETN564Ya431z8x8cQE1sPrUFttgvbUKtecO7vVXKZN2Day PtbTpsjyND6N1+qYZkwzqrSsnayfuR7HkwZ6yf3fT5+ZcSn9o16TT0yaXWbX7Fao4cJ6cjIvAp5/ th/yRTSP+N4lRm8v4kzLTC8y3rTCVM30plWmVcxoWm36IjOZvmT6Eos2vWJ6hcWY1pleY7Emv6mB PfLQPsxxB7jbNN9+OLewhFUPD6kQVVMhqqZm3gPqZJhVA/laJa9jXCq+m6qSlSRUzzJievTOnOuz amU6NSE1Yc7InFsJkwkFCUnAqZ9VnzA0y5jgSxgC8M25NOcStkvQQ63rkOBaliG3T8hQ8mqQUEN5 6qxakFU9A9hDair0lUpyIcn1wmGWESVTX1CemiHrmDCJOs6qJx0V/WYtn9GP2l2fcwe0nFR1upc+ KIP4vlB5QULqnLGE/IT81CSokY/1ID8PMDchf1byrJWQB3CW+Dd5iNH8N/hvMBP/Tf6bLMr0vOl5 8IAqUxV4wBdMXwAPWGuqZXGmV02vsln09ilz9B+i/8Aei/4g+gOWRO+XevxPinGVAGUAtRTl0uk7 JsvoswwFSuSjd6+yDfSJA45Jmnq5bDW+KyVUj4No9C3waB7iEfVPvaVSb/i+UyN5OiNPF8nT9eTp BvJ0E3l6FHl6NHi6n8WSJBwDozHoaAxPUd/4viHUXO77SdJxPWnNsboQj2fLFc219WStOeZQeB9H sweN9d56c2yHYu8D1HcG8VoVvU9oeGcVe2vrHVX0rlN4+Ktff47PoLck3XcEepLESBJHkniSJJAk I8nAN/jq7taBeokm+XEfMYc72BHNHMq8o6xb43syr1axhpbXqVhD5f2lbPEwo/lzrHUvW3DsMDtD pwJ8XzKLS2Us5hhBScxQrDkuMfYYQsyZuETM4Sol5mBcIpQdk8vj0uPSY3vjUqC0F/J0rAO1MgnP i5uHXEwxQ5jCJarylBKQFCbHHJcSa8ba2Bv0RD2jJByL6fOmz8OY60zgkabXTbgaHnpvYodoBpX/ bEYPEJTEFsW6YstilwJeHrsydg2kWoB64BXFbogNAncDlG6M3RLbCdAVuxv4RbHdlJZT/TKqq03h ElV5G+C6COgtJGcN0cuhVj1cd4PcHuD0gB0QH449hivetNJU/3FHGDVKUIJvAoxeFz0ZPRHDxxiB noyJAzATJxnu2gtikiGfBJ6ap0GJhRKP18QbjklDIGkT0HpGYkgetC5QJYXk5EafiLHGjMZYgE6L ySJADIlG+JJpzZ+wf/Bw/r9AUUpehxb85XUul7OyfrjuCuNmcvMomrWGcVO5DIqJNWFcM5fMgnC9 NIwbxcXT9ywLw7iM0zMfXM/VcHk2Qedsc4g3M3sPXuEJ/F7+O1DjH/l9EOW/x38PTtYH+APQspfv Bdsc4Y8wA9jmp8zInwQLmfh/489B/DnPv8ti+ff499gj/BA/xOL5i/xF9ig/zA+DzCv8FYg5R6OP Qsz5MZzKZ8Op/CfgG3i2/zrhNwl/8y766xq6U0Nv19BvKTSMnfNxy+Dsl6WM/WniLeE8+OuNYbwi zgU8MYxXwC2GqxthvDzOBleXwnhZXC5cDYTxMji8J+wL46VweC7YE8bD2eVg/9byYrgE2sG1PJHD z3us0vLwXXSaPUPm3WJ3NHuGzBtnNzV7hsy7yq5pfOJp8nOcf0axm6PYzVPsFiB218BJoBYiuCFy Jkxr75qJTg3/H4heqaGrNLP1dQ395l30W5o6b2navqWR+ZamL5n+cpgHyDSON50+IYr3pPKIM2dq w+jk+1nEhwBHMR2cHKNC3LDYpW9nzJDLSvSdkLoIF+mX64OQXEAv1e8GCnnd+h6ge/S9AD3A6dEf hpJjlIqo3W5Ih5XUqSStRFVeJ8gKKpKw9DDVwLJekHVY308SgvoBoM7qMdqo57GHjc4jXCKNED8b y3QwQt1mgG0AOxR6F8BeJd+v0AcV6KO8RBeEtJFwrs6lq4VkBbpItwUo5HXquoDu0u0G6AJOl64b Snoo5VK7LZC6lRSk1A+SZiRalVpBkiVLkuUESUIRcHrgqpck1OoOA3VM1/sxz9sPe2cZx/nIeuvA a5gO4ooYNQN0PRYBCv+RLA3kKmAFWARQBOCCeqkz8MhZalsiJkJKEUXATWK8iH9RwkVIg8RrFTPF dDFduCjmiZvEeQBbxe2i8icMyDWhrk1JiUpKQSwMkERVXiLISgQZeQBYx4YSoBbKFuFKEnciD3JJ 3CNKf7Gz58eyvQD7Xmz3DAgBgIxwQD5/HWiHAqUAPgWQXgZQLdOxPTMQV0n8EnxXNOi2id8JYWU7 vlWE38pXQaoknh52x32QqvgjQgx/SIgREoQkqoVpiVKzkj+upJ1K2oNYkbgVaKy1E2Rt4g/BHntI tEJ+nCRg2RGgjvOnhVTinQYqgz/917Y9vV/1juY0gc8IjVN1UzFTiwgo/Qk7C97PcTSbGJMHpq2h GM3EXTDXR6YRjxKuwlJuG9Lsjh7uk7h+nRmxwrcSpwfxFJ5+RmXO1CC21V0CnEpysqbqUOZUGnH0 2JY4twizqRhsq9+GbcUA0beAdlFplT4OdSP5TIdv0WP6dSgHe2H4B/6Jd7jQNyO8CjlTeG+7g0rl MwidMMCPEW8jLJ9X5NPDTsLniT+LaDoFcLeIlk8do8Q5Q5hOhNww4XTCRwh3I+YrCRsJBwnTaZMv UiQUkMxM0iGTdEslrTJprpHfRD3SCYO/iliIIdpCtAOxSOOVTzUwWqaeZsBqWGc1YXqXM7eR8AXC 60jObipNIzlLiD5NeIzqkDVgl2bqiUY5s8mnKjqXTfcSrpblTA+inoi5W0RXEt1NOAuxwBO9jkp3 Ez5GnCNU6iBOkPB+wtuJX0q4jvAY4XbC1JcYT3gTaXtRsW0q+eo2wvg50zuGIOFK8hzkMJnW3SAO 1hwlXyKfB0+rQ/1163FGcEWwSwZcg32EL1HbPsKXqG0fYt6io9lBmbxF7yOMzxpGdeQ5yIeVwggT Td5epVtFHk40ygS+j/AtKmVUaiL6BtFY2kStmqi0ifhNVL+JNCnCUlhBPuqXaFkyteonukquL1pJ Z6oj0sqlCNCPNOsDX+D4L07/Hjjfm96N4yX79BG+NIX/I+gjPIoWA+v1Er0cVxyt3H5a+/0yTfwq OapQfEia2kurmGIC0tB2EcUHK3Gw1TDRw0RnUX2aKcAyjfWzFGtvo1YYJW7QbE7rcB3FiR/i7FOM isPYxX4mjgD+gPg3KJrNEifIAsj5AFux8/qnEevwOdlvdRh9U8WXcD2SZTIJmwkzGaOtgH6JsJ78 Kol8zE2cD4n+OtFniY6iVf8k4RWoFd6TTo8wqk//42LIEer0WeT/u2hOicYZFOrQJsY0tIN+G2Kd hHFV3IU1hRjEohV9Q4iRPRxnVrcF+bC+kB5AuxnHkK/fhr4kjpDPMH434e8g5i4QfQ7XJncF8Dtw h8rx52DPAslEv0p4AeFjyIf7TqC5NYSH+R9i1BUQNyBH2Eo1r/D/HVshH6T9D5RM9ALsXUjkD2PE wLbCJMQ8jr/N7cD1yIG3wO3YPwF9ivsPoj9EmrdTj+gtt/hX0KriXIzMHM57Ifc6cgTQn0vhfwEy U7hfUVsZy3J2E76CNZHPbcWxwx3hOPGHMJ7zCThq7iDS3GmMEvwTOEakoSa2quBx1WzGPQjG9Rtq +z2Q+Th/CmMURG5OyBPQ59cJsEMJG5AWVgtdGIGFrwLeizWFA8R5Qgf7sthO/x3/B92nYdY+K4JA sUS3BPDjhH9F/BykeTPhHTpYBTqZfkwHd836nyGtq9JJUD9NbAQ6UywBeoGIvbytKwW6i+p8DWld kw70NJTqoI7uZR3YVrdTtxTqbMA6wjf4fwY8S/ACfkHXDLhJpwN8Ek5unPC3woswuu8IcFoQ1grf AvqLuhaQ8KogEQfxJhr1WgFt8i1hPuCvCGj/Twhbgf9DAf3ze8Lb2JfwbcDlAtyzimPYSvcFst4X hR8AP0NYA/hF4ceA9wuwZvk/Er6OGE5rqOejwmPAOSWAFwnPIub8wndJQ5T5NtpZfET4GtR5RPgJ 1FkuYDQzY1QUR8R/pfkC/9G9pvsS0K/TrD2hwxlZLYK3iCfgzo0TR8XDZB+4SxYzdS/QvLxIM/IC jk4H0U8nYinE2xdoRtbSjMAdtvATXTzgDwn3krTDVLoTZ99QTj7QRW3fFzaShdFP0oVXAS/ByCbo hDcAv6z7O5qFN5EvgByuXbgKeLswTPzjOHbdv4Bkv/Aa1XmNZiEb51GZi1aaC1iPXKX4Ps3FT1AT oZfmAu7bhV8LP8L1O30W1yzuDvyrtP9eoZ2iguh3qHQBcapoXz5FNRntAvR0gGdUhyGfjVOdrVT/ i0QfJNpG540yWk2l1KoJI6TQiCcoPodknsHoJ7xN9XOm4fQo7CP6O4h130csfJfwcxhXhX1T4Ntc q6wP9fUdPDMIm0hmFP5PR4xHLMyW5SN/akw3APH592Ivjlf/R8DvGXJw1Hp8fvGqbgRpGRsSiI+R 6j0sFZqJ340cMYX47yCHOyVWEgYf4DMwXvEZNMtM/DxhKOV7KY79M3H+L2LuV3IrXSHW0eF/lqbF ccS0Z31gqME4TOPqpxNaBp4nYR+FMU7HIz11WOEgTqYz5xY428LoYBfCXYbOLWgl2NPxrJ5EJ6U7 hhSksRQwnS6wL8AptN89Tfj/IJ5+gc4zQdrr5X1fT5wUkmOjnV2PawHrwBkik07pqNsgnWDp6e4U nXJZD43ipHLOR3qI8FnC5DlTp5VWsgT5v4boLfJnKVIJm5U6A3TvgxwdSdhH9KOEE6mXOcR/h+qP 6cBnphYghtnXI8YVB/t4BnEgHrJHFIycs/geGyidh6cFmcb60+PyqQD9B2oSLZfyZD0xmfjxRFcT PoqWQQtPLTBABJt6G+lpu+HvSSadEHTbyeYVRH+TcDvh3xD+EeFfUZ3FRF8j+l3CTxL+Ep2HTVTa RZwtRNO9lZ7k6NcT5xJh+m8srgXAVwgfpzoi4UTGTdI90fT7ZM/HCT9CZ3LGYCeanqDS35M3Tih8 M3GAP0nnOjiB0/9JwU8Ryxy8IyjFkxu/UuyEdf0LA+wXuqWIxSuEX0PM9yAW5iA2yPhN4hAWGdVZ gFhPWJdFpYXEP0H0l4n/DtUnWnyPON+m0g+Is5AkmInuIrqDSn9OHJ44z5BMA/F/S5xNpM9qkka0 7r8Q/zlqJY9lP/FvEv/TxCkjCdVEP0ulInGWE6eP6K8R3kM9Pk38/0acO1Q/inAR8V8m/vuEm4mz iuh+wr8n/EfCZGHRQXQd6UPW0FNN/btUKo/6IMnPIX4J8b9CeANhmgXh10RPE/7fxNmCOIrmy+RD bKTZMaRQnXXEuUqcbxLn7wm/QW3JtuIgjfer1K/c+zziFxN/B3E+SZwlhE9R25cItxOm+rr/SXg3 caiOSPT0CPrb9En0N0a6CRUkeSU+o+Ar4b4TMax03obrWvcLfEKiW4pYvEL4NcR8D2JhDmKDjN8k DmGRUZ0FiPWEwbdryKtryJ9ryLdryNsRZ1HbQmp1gugvU6t3SBrR4v9j77vjqjq2/efs2TPnCBtE REVFRawI4qGoYBdREbGCxtilKYqAiF2joGLXRI3tKhKTqBHFXmKJJYq9Y+9KYu81RuHNfPf2xHff ve+9+8fv3X9+N5/73eusWbNmzZpZa8/M3mzP6ZohvwQyr8Gpj1ZcQC8APRGlB8BRwPGEZjP4t8CZ DJvj0Apo5g9+bdTS+7sS/BfgNwanPTT0Bl0LpSo43cHZBHoaMAstVgN/KTg4a2J2wBDwB4J/FzgG nBjQ+4DPgW+BGAU1FHQy7IFPOCT5WZTqvc6Bfl/w24A/CTgSiJGil0AXAh/rYye9SoEichOQTxKQ bRKQeSROl5J2GLsikZK2YJTNbtCTAk6+7iUpY4cZYl4IzihgGlrHWKh58M8U2Klb6wN+c/DngVMR nHBgLurGgn5Z5IKc7eCgFjsOzAQHkqpOd8L5XjuZh9lBeddmnSWqd4CDJSqrJNJyEs06zgAHqGJ1 pwRJ5EDmjdIm4O8BPQD8bMiDVs+BswSlr8GpDw0uoBeAnojSA+Ao4HhCpxn8W+BMhj1x0Aaa+YNf G7X0vqwE/wX4jcFpDw29QddCqQpOd3A2gZ4GzEKL1cBfCs57yNsBQ8AfCP5d4BhwYkDj9IM+B74F wsNqKOhk2ANvcEjysyjVe50D/b7gtwF/EnAkEKNAL4EuBD4GZ7pEO4xXkUiJFoyO2Q0yKeDkg7MQ nFHANNSFb9U89HcK2tVb9wG/OfjzwKkITjgwF3VjgROAkGfHgZngQEbV6U6gb+P8sCPwOlbpM0F/ wMmkk+SoWPupWDmocr1g4ji5pcsgP6FQrL7UjVjv5YKPVRzD2oPiGb3qCToAMiuBc/UzVZxcPcP5 Uj/UwrsCJl+5AqEdsVOoA3nsREwPoI2DTsM54ROUfpQ018+Ev4QMzkUV/azYW+pRr4EThba2SVRv F4yUVgE/SFQygaewZh4E//jAKibXTqYfZKlYUUv567Bf9wN2Xgp8a6ojNdNlkCkJ+TDsj5ahdd3b TeG3C/BtJXC+0U9QYdsVcGrCcgtG6gis/U3fx6EU63M2BWPRF707BtxYGCJKEfum87JdNRAaLqPF EbDzDizEnFTQLh0p3/FTg2GDFSd7PwB7wvIAiUpb0DWAR7BTewe6I1aGK4FPoFkDfwv2dPHgn5Mo 7tDzsANNhnwyLJTyMwuOoK5ECzhbCm9LRLuXgYNQGiKRYlfFcLqu7JCaqQJrU9DuAJxP9kO7O6Ft P+hbkIR+xQ3+LBDrXzlesnQuNFxCW7mgtxm01LYBMuP0pyHQ+QGWlARGQDIB3i4D1HfKxWCPGXW7 Q08Y+N2B74BDgSswYy9iRNLAiQfOAh4F7oXlczBeFSB5C5xThg8FMjz1YF0Q7y7o4wmUokX5dx4C o6ENecZ0ANpi0a86xv1F0g/B7wDJKbqd0OOHGYh8q/wEDp7UKMMgj2crzBet/IzSIKMt+Bz0CGA3 4HrUmqDvKyGzBxrwHIdtRERbIbMb8h7oox80w2/0Btoqj/4eglWtIZllRP23Ivfi2Y1lHSLlGXAa 9J+DHswEM57gcMxG9T0siQAHT3/EWlPq3ICILoLSOjLWeC8jU4lWlGmYMzcw+r2Ru/CMRnGAnQNQ OgPzYRjoSHmKouLZlrjThcpRhj2YXUpLWIhnZ4obvvq+BH2Hr6gZiDiieyBfFaN2EDJ6DG4GJwul k4zxla03R+lqSHZDfy8CvwIGQzIHMgGgc4HDIF8dNJ5PcawoxOySs+gO7KkPa3cbe/Z07Nmz5L6S vsA+fTF27vOws3YCJxA77kDs2XF6LyXFnl2nsf+VK3y8nSH27ygtCiSKBfQHyITLaJK7Y2Uo8Alw J3AqMApPQh+AzgVukEjjgAo4zqBLAjVgHviZqHte7jiEhvfy5AT4CnuQoZJWnEE7g+8K9AbfIpFq KLVAQw5wNDBMPuGiCugCyNQDfRP0O/m0S5lqri1zIOgnEmlJ4EzY9g6luYakBSc8tYG6fG3IS855 PH85z3pJy0G/Au3K1gJjYG0v9GIVUNKEVxaYrdsGTj2UBsnTM3odnnFVmwsORSvTUBqFdmvolsj3 dITHJP8UOFdA54LOAT0L9EFYdRq0qzkE9siTVQWcB5Aciv7WAydStxP0T6gbJp9TUw2cV/JURMmE H6LgmZvSfnUyLA/gVQT2kee6yju+S2Z79G4v9J+C/D5wpspSxZlXRFvyOQhhl2TrqPUAbXljLAjO D/PBL4BvC2ChFTKjQQ9i8+XpK9Pk6EBzPny1Au0+0Z/jY+Ycw8yxw7llOJAAs3Ge6S+/w6dUVIVv 6SycZN7GKJhQOkyW0oboqYscQVMnXQP3kK2D80z2iIbofFmXbsQ56n7oWQh+JDSX1muxL1DXA3ZK zd0hE8emC/TCTMhVWwClhlKSFjbLUhP4OZJv+hF4ANgJJ6tPIF8VdC7QDR5WIeMmOZSwmTJXo/Qj /HxDFesxZRnqhqBH+jntOr2/qFsa+BL8heiFp9EX+Q7kLdQlsPOOYW0+IhGWQPIO2vKWfjYFyjlj 2iY56mEm7vuMS6Se6kd5X5anfHQZM4vSeHZG0F4o9ZCoOMKTj+CxsWh3M3w+Uo9fzPM8zATFoC2g 5Sx6gOhbqccFZlq+nuswt1fquQ4z9ltkHswc5TL49zEuB/VMJc8SlR5AZ+BLtF5bzmoRL7LWBsxe V/m8ks6BPaGwJw72aKBLSm0iKi2IX2QMWJKgxx1Op0cDw7A7voG6CyBfIJ9VibbGIDYROzxD3uMQ WR/RohlWUcRLF2m/pb/kmDdIDrsmkedJT3JHRHELieZt4NyRNHOQqEYgvrKlhbQsdFrQSgjadZT9 tUyW77EIzS6i1iOJIuKk3xrKWDAtQjxugyWXoaEL6kaDnwJ+E0jO1aMGEdSfy1VBiIwXinsBLQX/ P5Hn84qHnCemhcjzrdWfELlyRoVxqcHPiAIp3wcz0BtzeD7078VovmIjBH0SbRHoOS854m4yAjNW 1m2HWquktsL98qybzpH3GjUc+AZ4ArgY2FkiKw+cJ1HcMYcj0iXHDzJlJPICcFbhznUPfCfQeaBv o3Q6MF2iuS3oRJTu13XKk3ZqhrcbSVrl0OAO/j1gqCwV9yApXxWlEzBGw1HaETgBuEyishN4SqLI 8y7SWkmz95D5gFYCQa8GnSrvFGwVsBHwg0S+CXZ6Slq9C76Ge0ozieJOITmlgRfAD5KnjsISiQPw ZGqlOl9GmUS6BPz1wB3AxxJVZDPWGZaMB2cwnl0S9Z2w4SY8dhA9cqZi/qgV0FZZnHAWBf0WdDzs 9Ee7r3kpwWmK0inQeQLzswdk7sCHTdC7bpAxQ+Y2+vUSkYUnYmotdlmeCMFXX0OmtXx3gt1CrTmQ HC3vYhRvhSmD5Amtinsf85F8JUjdi5M0R/hf9jpWznnR6wE4oZX21MfojGbucqUqe80OMxNk5ElC G+kNZi9L+WB5L1NXMQfIyxf/60HyjmxLyEtLRtIYeSqFp7SDJYf3kLW4s6TZdanftFPeU5RV4Ixm 8Dbi64nk09bqa3nmo+uUz7X5KSnDGsL/9/DMfbN8R4Ufhf3fYex6oL9D5DNf5YPsI3sB/b6yLp8K +qa8A6qV4f9gGgsU1tJ8+idQ+meznA8qnhOplSBTDDJngU0kKqvEXsdEO0nbhIWSniFRbS1R9KKZ wKvSWiVIcsQKrZk8JZN2cnDoe+BmqY3Z0bui9A/4zUP6R3hG+qcX6q6CntfAVXjKv5i2EnhXL5V2 KovR6yA1HjqlJWuhf5isRfvL3jFfiaJfVHCe6zbj+XiwjtKfohdSfrTUr9aR91k11OiRPMdIBh/v ifEB6Ms+YEP4fyJmaQ789rvqJfiK1KlOQulIYD/MqMp4syJMtsUCMaaBmNvh+mgCy2DGzsQ8P4B5 Pgb0SUmr6zDbdyJLFEByODT46zKY53mQOQV+BZzolgXHC9peoJVYRO7PqPUBki0Rv+1xX2sOPS15 T8wKucpqKiPLDpmqSKQsNc+QaCHIrm6I6BSJlnzk5yDgGVhoLyXtkKtF3TKoK30yCpGShujzxBy4 B84U+exbtDsd0SHXUQcl0oW4m+TKVSubjTw8C56fw35FnP6KWj7I/5Jei1XfKmSwearsywE5pmyC ntWlNtWEORODWZGCGXUHM22GfIOLRcgIEvPqPVZ9sZgP8j6eC/staB2rx8I3pCueYJaX+RmnW0OB TwrvyvECPRUYZfDxRgTwa/3UDrgB52NxQEWXLBA7TaWe1EM18PPA74K65yXf9ABYgLYsoF+BdsaO 3hmSrni/Yjg4FtAPjdalfJihQWquh9POffoZLGQK9J27/qYENGcD8XyWXjdsk1gD/LbY70/FedRQ aAuDZB5KM2HD78ZZpZTcgJ2+AtqC0nwpSR6CMwg2uOn9gs56sMcRfH/I30HrdtAZDtofbVUEPQuS tyFpgp5OsGcYShuCdtH5RlsSn8EDIZAZBnojNOwHLkRbQfINByUS8vr7JG4oHQSd3SETB04XlObC qlJoKwf4I/AAUJ8tVVFX9y16TaHT9BHabkBmGTAE/E6oG4ln5c+A72HPD8CX+ihD0gm4Vm8FtW4B 94H/J97WyAWtnyR7Q7IyZstl8LfhrPgw3qjhOOk9LGtRT8jPgc2wTY0H7QX7PVCqj9cj0GPhk83A NTiJWgR8gPFdCZl8cArAeWLISPmVxrzKg7xEvPmj7MQJpwUIa5X7sPkB6KmgDxp0MqJjGTAZ+kMx u/IwGyV/rvFuqs4JBS17FIfzq5KQsYBWjLNfKeOItxQeolY92Py1Ye0yREEeWkEsgPNKj2XQ+yDZ BXWdgV0wOjjls/SXkmbkB3ZNIh8gS9mv6NEjieYmksNXYFxOAyMwb8tKvmUy6sL/pnTUagKb5+rz GdgfIz4I9ujnz/tggx4FrsBSkHxXuBx5bDFy3XL0VJ58YqxNrTFPwtA7P2joiV5rmJ8P0W4B8Dww B3gR6A0N81F3L/AkWsTMVNpB2yrJF/ZVF5zear5EzLqhaluBe/E0cy/OBvfiOb4XIXgDhRA7kmla RViflD5RxD16REoCieybEjuA9OwXG5VC+if0SU0kw+Vfo3XqGOIu3xgqLJT/ZiApQuxJMVKcOMhf gif2kUJKI0WJM3EhjuK3fDNelhAbZZLfbDFohXBCpd7wyFB3+W0XlKtGGSNOpER09MBkMg6YAZwO nAfMBK6MSYjvSzbExSf2IduAv8QnxqeS/cAj8YOTEsgp4Hkh2IdcBd5OSIpOIPeATwbGxsSTV8D3 KaLYRIB4lkX+QgpKvhgn+8D+E+cvykTwJpbwzl9o9xlaPkOHzxBnx4Ye+89QM7AYqUy8SQBpQEJI OIkk3UkMSSCpZDS+vjCXLCY/EC5fSyaT4WGTyVm/4l+GkCft8hvRYoVuqUzkO1amIkf033ZWgr96 scuCvSa77cb1kH510vRr8SwhL66l3PSra7Be33WRaEvod11l/P7F6IWz+L8H2i6Kv0UPJ20Iwb++ qfzff99KrKDEjDJ5KAG0hdqFuJF6JJiEkY5ilRJF+pMUMpKkC899TRaQLLKSrCNbyC8kl5wg58l1 kk8ekVfkg1gcaeYthJpXm9eYt+KaY96G61rzz7iuM28X1zWC2oHrGvNOXHPMu3Bda/4F13Xm3UQR 1z3iV46Q3ovrGvM+XHPMv+K61rwf13XmA0I6x5wrfq0V0gdxXWM+hGuO+TCua81HcF1nPiqk15qP iV/rhPRxXNeYT+CaYz6J61rzKVzXmU8L6XV/5xH5pfPhZNz/yiNn0PPV5rOGZ/IMz5wzPHPe8MwF 0c5q80XDP5cMv1w2/HLF8MtVwyPXDI9cNzxyw/DITcMjt+CR24ZH7hgeyTc88pvhkd8Nj9yFR+4Z HrlveOSB4ZGHhkceGR55/D94ZB7JJMtJzj/1yBPDI08NjzwzPPLc8MgLwyMv4ZFXhkdeGzPmjeGZ t4Zn3hme+QMz5r3hnz8N/3ww/PLR8EuB4ZFC3SMi0cAjFpPuEYuie8RCpUcsqu4RC9M9YuG6Ryxm 3SMWi+4RS5F/wSP7yTGSR67iL7xfkPdigWlnsdM9YrHXPWLRdI9YHHSPWBx1j1iKSo9YnHSPWIrp HrE46x6xFNc9YnHRPWIpIT1iKal7xFJK94jFVZ8xltK6ZyxldM9YysoZY3HT/WMpZ/invOGfCoZf qsieWtwNv1Q0/OJh+KWS4ZfKul/+ZY88snmkquGRaoZHqhse8TQ8UsPwiBc84m14pKbhER/DI7UM j1gNj/jCI36GR/wNjwQYHqlteKSO4ZG68Eig4ZEgwyP1DI/UN2ZMA8MzDTFjGhmeaWx4ponhmaa6 Z+S3OqXduAPNFncCjSSKW4BF3A3cSFViFf4KIW1JF+2MyPTNLB3U2dpZg5qj5YHqKHjnDGqOdl5Q zSF3waDmaBdBSblLBjUH32upTHxIoBiPcNKZ9BZZPZV8RSZrl20tXbG1dNXW0jVbS9dtLd2wtXTT 1tKtTy1pDwTV0tJM8B4a1BztEajmgvfYoP47i27bLLpjsyjfZtFvNot+t1l012bRPZtF920WPbFZ 9NRm0TObRc9tFonYN/mYfMQCpowizwAqKZVwLxYrNwd/rAJSxaiNI6X/q81kkVhf5JBt5IyYx+9M 8hsRJU3uphqmAFMjU6hpqFy52e8jCr55oNr/aqP2f6KU44JaAOqEjTppo07ZqNOg5OpQU85IWrkj cB7Kztqk8mzUOVBU9MKRuCjnUUNaMkORVnwLmQufyZRUpE3zlAOECsl5ykWbpks26rKNumKjrtqo azbquo26YaNugmJi/F3EnPcg1RVxf1aWiLbE/VnJFNeDQmKJckhgpnLLVu+20W+zMlP5WoxRlrJc yK9UVhM7JUfJIUWVdcp64qRsVDYRZ2WLsl3op1iNuhC5hmuCtZaT8VXE70RBtpItdG4S8lTZpewS 6zMx2spc/IW2/OadHHuR6bGWtZPf45J/A07KKYuVxaS80LGbVMBfXDfGX1xL/YliVD6PZGE3bSl0 vgUVaqNa2agwG9UaFMP3Fl3FPqIyar5ArZeo8QrSryH5RmYS5YWoQfDVPMon8QxF7gwoRbepHbWT +yeqoR9Cgt7n5aic5SZegVeU9UxdyE/0AXWn1ak39aF+tA5NpxNoBp1Mp9KZ9Gs6l86ji2gmXUaX 01V0Nc2h6+gGuoVup7/QfTSXHqEn6Bl6nl6m1+lt+rvQ9Yg+oc/oC1adebOGrDFrypqx5qwla8Va s3Ysgn3BurFeLJr1ZQNYEhvMhrFRbCxLY+PZRDaJTWHT2Aw2i33D5rBv2Xy2kP2NLWFL2XfsR/YT W8PWs81sK9vOdrI9bD87xI6xU+wMy2MX2FV2k+Wze+wRe8ZesXfsAydc5RaucSfuzF24Ky/Dy/NK vAqvxj25F6/Ja3Ff7s9r8yBenzfmTXkz3oP34bF8sP0G+032WzRF45qd5qg5ayW1Mlp5zUOrqlXX vDWrFqAFag20JlqIFqqFa+21SK2L1l3rrcVo/bT+mvyXFFdSC5VLiwq0ghiDarQaUagX9RJjUJPW FGPtS30Jo7VpbcJpGk0jZjqejicWOpFOJEXoJDqJ2NEpdAqxpzPoDKLRWXQWcaBzxOg50m/pt6Qo XUgXEie6hC4hxeh39DviTH+kP5Li9Cf6E3Gh2TSblKBr6BpSkq6la0kpup6uJ650M91MStOf6c+k DN1Fd5GydC/dS9zoAXqAlKOH6WFSnh6nx0kFepqeJu70HD1HKtJL9BLxoNfoNVKJ3qK3xMz8jf5G qtD79D6pSh/Sh6QafUwfk+r0KX1KPOlz+pzUEDOgOvESs8CbeLMGrAGpyRqxRsSHNWFNSC0WzIKJ lYWwEOLLWrAWxI+FslDiz8JYGAlgbVlbUpt1ZB1JHdaZdSZ1WVfWlQSynqwnCWJRLIrUY3EsjtRn /cXOpYH8lglpyFJYCmnEhrKhpDEbyUaSJuwr9hVpKr9JQoJZOksnzdgENoGEsAyWQZqzyWwyacGm sqmkpfyyCQllM9lM0op9zb4mYWw2m01as7lsLgln89g80kZ+0YS0ZYvYItKOLWaLSXuWyTJJB5bF skhH+UUTEsFWspUkkq1mq0knto6tI53ZJraJfMG2sC2ki5i5O8iXbDfbTbqxX9mvpDs7yA6SHuwo O0p6spPsJOnFTrPTpDc7y86SPmJeXyBR7Aq7QqLZDXaDxLA77A6JZXfZXRLHHrKHpC97yp6Sfuwl e0ni2Vv2lvRnf7I/yQBWyApJAqeckoHczM0kkdtze5LEi/KiJJkX48XIIF6cFycpvBQvRQbz0rw0 SeXleDkyhHtwDzKUV+aVyTBelVclw3l1Xp2M4DV4DTKSe3NvMor7cB8ymlu5lYzhftyPfMUDeAAZ ywN5IBnH6/F6JI034o1IOm/Cm5DxPJgHkwm8O+9OJvLevDfJ4DE8hkziKTyFTLZfb7+eTLHfaL+R TLXfar+VTNPELZRM15jGyAytiFaEzNQcNAcySyumFSNfayW0EuQbrbRWmszWymnlyBytolaRzNWq aFXIt1o1rRqZp3lpXmS+VkurRRZo/po/WajV1eqSRVp9rT75m9ZYa0wWa820ZmSJ1lJrSTK11lpr slRrp7UjWVqEFkG+077QviDLtG5aN/K91kvrRX7QorVo8qPWV+tLlmvxWjxZoQ3QBoj9n/yK02Ba kXrSWtSfvqTT6Dd0Pv0bXUq/pyvoRrqV7qC7RbQdoEfpSXqWXqBX6A16h96V8cM86UvmyWrQaSyc tWeRrAvrznqzGNaPJbBklsqGs9FsGVvOVrEctkHMqG2sBtvF9rID7DA7Ts+K6zl2iV1jt9hv7D57 zJ6z1+wP9pGbOONFuAO9y8J5CVqRl+UDeB0WKaiePIrHsVv2m8UNwqzZa0W14lopraxWQauk1dR8 tdpakNZQa6o111ppbbQOWiftS62H1keL1QaKvqYgsxFkNhNymoKcRpHTVOQuhqzFka/MyFcW5Ksi yFd2yFf2yEsa8pID8pIj8lJR5CUn5KViyEvOyEvFkZdckJdKIC+VRF4qhbzkirxUGnmpDPJSWWQk N2SkcshI5ZGRKiDbuCPbVES28UC2qYRsUxnZpgqyTVVkm2rINtWRbTyRbWog23gh23gj29REHvBB HqiFPGBFHvBFHvBDHvBHHghAHqiNPFAXeSAQeSAIeaAe8kB95IEGyAMNkQcaIQ80Rh5ogjzQFHkg GHmgGfJACPJAc+SBFsgDLZEHQpEHWiEPhCEPtEYeCEceaIM80BZ5oB3yQHuxQqhAOiCiOyKWIxDL kYjfTojfzojfLxC/XRCzXyJmuyJmuyFmuyNmeyBmeyJmeyFmeyNm+yBmoxCn0YjTGMRpLOI0DnHa F3HaD3EajzjtjzgdgDhNQJwORJwmIk6TEKfJiNNBiM0UMV9/J8nUg9agVhpAX9HpdDZdQBfTLPoD XUk30W10J91D99ND9Bg9RfPoRXqV3qT59J5YzTwSsflKxKaXiM02rAPrxL5kPVgfFsvi2UA2iA1h I9gY9j1bwbLZWraR/cy82C9sH8tlR9gJmieu59lldp3dZr+zB+wJe8HesPesgCucczvuSO+xNrwk 9eBuPIHXEXHZi0fzvvbbNFWzaJrmpLlorpqb5q5V1nw0P62OVk9rpAVrLbQwra3WUeusddV6alFa nJYoepn0/6PyX45KGY/+iMcAxGMdxGNdxGMg4jEI8VgP8Vgf8dgA8dgQ8dgI8dgY8dgE8dgU8RiM eGyGeAxBPDZHPLZAPLZEPIYiHlshHsMQj60Rj+GIxzaIx7aIx3aIx/aIxw6IxI6IxAhEYiQisRNi sDNi8AvEYBfE4JeIwa6IwW6Iwe6IwR6IwZ6IwV6Iwd6IwT6IwSjEYDRiMAYxGIsYjEMM9kUM9kMM xiMG+yMGByAGExCDAxGDiYjBJLFv5vh3GHuTZWQ12UL2kCMkj1wn98gL8gHnH9jzkBpi51SHNKCv xdxNp28FTqB/CJxM/xQ4k08mCmvIhwtszEcKbMpHC2z2DzS8gYZ30PAeGj5AwxRoGAENo6BhDDSI PRj/SkqAGmujxtmoNBuVbqPG26gJNmriJ0r+65MG9RKU2LWLu/5NQthHVkAUcX8Wu1FxjxabFXGf tiMWcX+Nw5cNw3A2VJUEYKfvZH9MxK+oSR98osR8kOcHx8Wvl2Kvdg1yjnSsiHZRpl/pA+wH5R6C YDdgEjVvyB0gnj5YsK++K3aTq+XphpKl7xPJOfui9o7/5ZmEtEk+dfIg3sK/TYwTiKPYMR+znSTk y28bgvrNRv3+ieLDpPR/uwPXn7mZ8LRNw3Ml4SzlGS2r9lX7qfHGUzmTLkVIKfm3Vy7gklK9reml uvMiNTJCM946mMxKVnqpNoLVSjGZfO2tRTjzcqRKGUasfbidFzeppvS6iknNirB2sHp/xnFbVn6c G2mA/9qRKDJYTN8EEktSxf8byf+sFT9TprrMLOkzIXxfgXNAgYtP4O3UkRMu8hNZ6c6+1nRVWETD s6hiUhQ7n+xiV9sXdl9ydM+n2uWEKcm+XlZPTjup9sU9miUlj0iJ79sv1b16tKe7b1BQXfc28dEp SYOT4lLdmyWlJPv4lre66cIl/nNJUkqf1PikRN+K1gqynBZ3/au8Y1JSqnvTIan9klLiU0dYy5dy sNa1BvqJ//n7Wv26lnLw9RM/awum+F9X6wj4SijhxZVOEb7FrcXkD0txuy/6DO4Xn9g3VTTjZHWU THNxc8fYmIFJiTGfDLP7Z4ZVslbUDSvzeXlMrHtEfN9EodW9fbOm1nSTh9XBNoAmEyM03VSUCL6d km4yka0jxpzvsbF50MqA1b6X/6hSu9WwPX9WyDzYfNDT0y3u5U3/dUB4x6hXC5Vf21xslVCrcqPY 3ScqbbUP3Tp2yLXmu1bNcmx/oIrXi6y7DpUqnG5a+X3UwpOlm/84J6zCwuMba3n8GlZzdNKlEuXr Tw9yCrq2y/NVXP2aJr/CgmqhyzcnmCYt/nP7huix6X90z0qbMHHmuhfb5n5/MnB5+4mlqk1qe836 hjR8lftHw7RfMh4nBK3wCXizyWet3Ziob4bHLV4w2CFj7Yv9L91/buc8I/qo9yW/5qWf7AibV799 hOuJuA4jVq2ZdKhzo6Xp7ScnsvW1946qvKtjXMOFbY95feWfOKElP515KixDScwgP+yZdCNCkV8Q /j7tvTXtrbW4cGe5KqpmteMWMXUZM1NqTVsmuSY1bZE1bf44p26nkp/Gp2RW6vCVy4Y2MwuPfpfy fz/f0ouSvWRagwaTi51u9Cb60Y0m1qLSxuImU6HKrFRcrOUkw1EtqbocK3diKEnutvb55f1tF3UI 8fk+JPqZ1V4WF1VVEUYZn4UOlTNiVHbOV2FVX5zY2TZ1WZdqqTWGbMz4mB0+dzhpc//IQ9er8Qcc l41+qTTLPTLp2LuIY/uW7uqc9Cw65KcQ8mTeoUXn3LbZLy3tMPfC5fJrPMc8fbx88OpZ14NmNlzQ f2fgwDOT11b6eOP++fgi30zeVXCL7Ah4+Xb0H07OPuyh57w5wQOqD9oaOOum2eFwj37Hd41rOiBu 5Y6tO2YGHHlBnUaPfH3mZvCNUQW3bq0ueHPjnMPG5POz77TbErhsdM28hlcC7KPqKkvT+lea8qZ7 9Kx1XXcEXeg9vdOEMv6v6y/ISteW9Zq20Xvrdz8ezb7svmW3tfREdxeHGjs7vmp6s6f1zuzq8ZP2 Jt9+uSL7xLjglKGOIseMFDkmysgxfUwnGyEXFv08jpjIM//GqJYJJ0jkmLp+fgFWvyCZcHyt/raf 1rTx/09sc8DEEVNXbdOufcdP4vSfiP+PuWeXdcqfzVNWRgzInNKOVNrzS165huu/bBL4cvA36VV/ n+dMIi65pTs2OFFux663wTPm530ILJP/8x93Hp3tQ3dnnT0/pE33Fj897vnszO34bmUGP9joNkM9 7hmSFfNlrfILeiQezHYNSo/dv2Jn9pDJpR9Mmu9SdePYqkN/yAsMmnBnY9Vzrn943T9zuGTXyIov 5s+YlOFZ8KqV9+/T3qmNxxw/Pm92hsMgevtUgRZcu/DCtsbXZja3G/PmQus13Z4NTSk3rNKYKbX3 u/XY0J62bjnQvKLT5AV83PK0NZFtL6adf787eI/vL50cFp6LaOVsffjbj5NH99w/sqvLJMumuvFZ D/0qT7c8/CPPZfvND8cf/FDCyD3vrGmv/3Hu+SuKA4ezwYfK+v2t1+yMTmunbM9duD51JoavXFEZ 9SKQzeOQN8pVUl2tJcf947APkQIV1IbW+tagrLpZtTP8+6WmJterVSs6JcFn4Kcx9IlOGlgreUC8 5NZKTkmKGRKdOrhWswgx8XwEyxr6yUKTSW1grWcN/PTbqmR4GwqHDRv2jxTGpnymKfXvAgrZpzod n13c4XlBsaTgoRebZW/LDX5fOTYgZ8i6QdaZ87aMf5+SX3C87t16yQs6uDtuH7Tp8Ktz+VPvVU8e fO7xrX2jnjzvHNB1XPpDpwsp9IFz20fXHKaPCmmn9RnyMXGx+doJr66uDkHren+8XKiuUr6/+H7m 9zt27e0fWd+3V7534tHnbWq4vSg/dFTG2txJ59fXeLz6mOOe/KVj7528NyElMt01scahzG83lSm/ N2nOlajle1sPWHP4ccPZdzbUyh45LKhvfzIqfQl1uh79bauqwde/9dg7yf6Uy/e9rg72S6lTvvCQ 54HKHdvFhR4uV+6nA1WD4tu3XfFoH0/wSSn7vOLlgZVDx6WVaDJ66bHUwLB2IvssEdlnop59nPrb L2y3h1TJLnaleYUuI/su+/sc9O9Z69QRyaeO1dcaEFBXpp4g8fPfsNaJjB8YOzi1z8Dk/+1a52rd xD/XHgoOG+R66ERoo4g977Ndtnv77XBu1/HQ+MeN/C+18p1dfcs3MTcrtJ+wfV/r02PZu6dDfpl2 cOW5nPjkuOHV4u5t2fp04s/Hn6z66PyD/ZcenrVONrnUWS07dPPAmIFhkVeuPb++e+n4g+NujA1X 6s59vSfT0rl8v5bHL+0Z2r3WmC1V1E2du/V3iy4cN7rBk3NqlTZBw1LNPfZ1v5hR13vIYccH5YOK jB5asCQhceTNR41mzc/8jxXyxWv5SyQlGM271OynrRST4dp9T79FIGDTz61SvTnvVGcL/zgtcL2V 70tTWbHZsalVi84ksL1h3dBmvP3HlOgWx5aI1il5G+R1PM7kz3F+kPWiXq0vG1LeNDFqAENEBVuJ wzE0WjsCbJzQnoUoI6gJw4BUUOa/8LOfvtNktXdb/545r9ZYOzofu2AgCdcgwsTCI8fFEMxQCuyF ODM4oraEMJpRWAqoKb6ChodqAnYL9i1MZGfk6ylw7X1fHLLXnpNV9/+OwOBWmbeWE7cvDuO+17PN Wvri7zXLT27fGKgonc+RWZfNvEjJ7W3OltwapR1ul1s+9/LvY+8yO/i67mVBrOv8SZfOnLvbd+Dh fq2zNW9OrjO62r7zdPIRs4sSivvL7lnP2ixdPE+x48aWLUIhPV/mHEr1mqWhNiehi9/6uHBqhcfu 82ubrfw3JEXcM3j50lL2ceenW5aNP4UVe1IaktlYpn2axeSsX+3Wses/083Un173bjGXTN7Mmsdz Zu4djcQaj4/icwQVLZhk2tewHZ1mtOOpw7Fg270rO++9SDPv/aI0bc6ZDeUhgVbXilw2KX8DFlCr gAXUJFjziHWRAbh5xDFwzSOMggBURlkAW0OmwKLJ0NAUVEYZQ7iGIK5B42Z6NI/UDVQhXLk858yC jNQiBZdgVwXXYD8rC1MXY11jA1NnXVMnZzdDVQNliJ9kUP2kGwzylEJwalFZZnIqweLtA4vupmkH pBrTVTeqJW0W9j5nsOuAkMWfxlQT9iNmm1QyvrGzHGCf/mX7x2q5JB23m95LAk22X855G2W9pXmh u60gh55ptuuzQzY9TGlMKyUyX3u9Vdd5Z1MeveRKwUzv8BaBC+t1f3TKPnulueX5+XlsScuLQg5Z Hztvv+PhhgiBnKdLrx8+VGq+90vrw8YXGjekP35a97Fp8bXrzIvmi7b8tv21+uE2oxMLmFI+P/sv pVbIEdwlyvSpWb3Ms6lw+fu1RhXHrueI+SulTk/yddP/r7y+9c2ygr3Mp2/dMGI9qj3BYdu8qzpt OdtPCxvV9h6rWyeub/QnbbfsBtfQH2t/6aY3p2tObrkUtVAZuTmFKBBeTP/2/X3Px2eZjyMz/L7P 6Kq6O1sPpaWEtcSgpKVUUlyQnEiVlhLMpBLshTVK+4/tALbSite+PH6izb6lpktus7K2yId9ej9z 2XGOXv3NZ+0Lr7bVlMvffS2+aW/N458zP3G5eqwV2Z2p88kuPSnk07t6dcFJlm/O3Wz36/ie4K5c rS7qwDF/P68hS9MN0208cxgud6+qSDy6tcNxrp3ZnYgl6rOtbu1lixVZtonf52CfTfenpJk/0t5e /SyjscHo9ilDzj2/lTLcfH5dLlZ6rtmnxPA7bD/busYFortMfmr0yXslsS7s/Nro/pJ3Isf1COt+ uWzOzJUHPGpCm+zjGSyc57Cdsb+hv9+/mNP27664L8ffmB9KSVzge8W24Ez0BuHGg1cWG0rtTbk2 7VKVvVa0WzCnzVnmn/aRDGc6gxMNwc0plplMjIwGje0D2GVD6UgihroWNJ4A1U7QaONkNuRBHkcD 2ovgcRvyGSDLigJLDbhGFkNgUl/rVfn0WP8uL8kkdvUHz3RmGnNKvDXIQNLCYxhlELFAr0GHIYQh kyGXIZWhmEGBwQ9IlwPpIIZ8oFgiQx6Q7clQAmTlAFUlL1RrUMGZVksqC/LTixILMioV0MomliZg 6svQXv/D7YZ+14dtrMlzFNm9DtmdvnHE9YJRkynHNEauT5eWxhuu5zgr6mv596Nbe+HfkPkWL77e ebE28ffB97Pqt+bFz/54OJtn5nf73j3CpwolbTuavqwJVPa/NPeCrcbyR/7Fh0rFiyY/fl7eXLZn kbwC0x1tnthi+QsNa997Tb3C9F4gzfXRmnP3mn7n/q2V/bwzzHElv2fK+T/LPz2cNLFcWeF2hoyh Uk7Gsm0b7m+59rjrzJPTcy/b785d2P7spLlet4XQLUfe42Us5hcFb2tfPLEjk9l4zi533+ynJV9r f9uu92fktRFbJ2HHvJsxpvn2x1/HGTtZF2ZOizfRyH5ToHbymvtu3RL7uQubmOQNmpikEfHEZtjE xAMU4qB7gkSvJFGqbnZoglwQayCBnBq5EUO/jEA74TKshvzAOtXAwNLIxNDC1MzUIgojMc5Y8db2 jpbK15ar93zYV7RcSNm6eApaCQVKIgULbDcnHj53unP1963vfxzmWMX3/udmpzP9/3tk/kw4GrVy vXXP1Ptdj05M2vtwx0FFbr27SwJj9JW33kz43q570bBR3zLtytItb4OO39zO3rmh34h9ocwB91D9 GLtowa4HGrWXj6e8590dei0vsNvkbt0bs4vNK1k2FLpnyDInach9Ty47F7Vb/9fh81fsLq/TZq7q ak/M28Vwefmr623nfxosNr3wVKJA5kSNVI2+2FHOBvENlp568rfk2NZPde15stMsxN7q37e5/07a PO6YvcblnBLfXFb7N8dLjR6V1B3eq/Bu/enPbo8K5OwMAuwE+qz2pR/o+lyqW7TqwAHerb1MOzSq NwSV386IzQUAk7Nj2A0KZW5kc3RyZWFtDQplbmRvYmoNCjQ0IDAgb2JqDQpbIDRbIDMzM10gIDE3 N1sgNTAwXSBdIA0KZW5kb2JqDQo0NSAwIG9iag0KWyA2MDAgMCAwIDAgMCAwIDAgMCA2MDAgMCAw IDAgMCAwIDAgMCAwIDAgMCA2MDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYwMCAwIDAg NjAwIDAgNjAwIDAgMCAwIDAgMCA2MDAgNjAwIDAgMCA2MDAgNjAwIDYwMCA2MDBdIA0KZW5kb2Jq DQo0NiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzMDgzMS9MZW5ndGgxIDY2 MDg0Pj4NCnN0cmVhbQ0KeJzsfAl0VEXa9lv3dlYS0mwhIZDuTpOEbHZkpwmksxEwYocskLB2IGFR oJFVkCXOiEtciKMo4kJ0UEEcuGn4nEQR47iiMCKLoKM2js64D6DghuT+T73dHRKUX843c+b85/ze yvNU3Vret9a3qm4CJIioG8hAmfmlYwpvGx+jEP3zFqK4BwvzC0Z1D48sJ9rwEpFyZWGxs9Qbfg5p DxiJhjxcWFqeGxG99XdEBzUIedtZautvfGrK50SiCVJd4/PHVgyqcC6HrFqiLvfMmFe14NyQ9GKi jO7I8/WMpYvNm6+5JY+o6GOi0M4zF8yat+eVlSOJbKFEIS/Pqlq0gKIpDPp3QZ5x1tzlM90fDQkn Kj1N1Gff7Jqq6sMpiY9BVhbSB89GRHiL2Ij3xXjvO3ve4utsn0Y7UfcYotiZc90zqp567/EpRNe2 4H36vKrrFvQ40uM25N+A/Ob5VfNq1sU+vp7otr5EkfMXuBctbk2iv0L/PTJ9wcKaBe83PDwaqg4Q 9ehKsu+Ceqcc2/Xis9Oiss6EhqHaeP5Y7s6R/ssPj0tuXfbjuKCHwl5G3jDOLx/4wVvP3Y9O39+6 TM8MeqgtJfCoMiZCo9Gk8LtCRrJRJXqpGXo5xrBf2U1BFBq0MWgARPbx+WoVzVS6BgUpIcFhihKk GAzHKVVvoevQy7InicrG5pnJTBZaEtSltUzWRJnlIKHrOkrfbtgtW0oGw36aJXPDlxXeLUJpBT1O D9OH4kOlD32NcIl4hHaLN2krbQHm0810P91Ix2gD3o6K/eIe/Z+UQmV0kHbpBymOHNSH4qmacigD JeYjJl9/Vz+JPCuoH9LWUAlF62/pn2PM0+g+0UpP0jl6Qt8hNlOl/gUtpJGUS+uBXlRLGhXQDfoH NIDG6yfQT3PpProH8kn/CaXTqFFUKEKMo1X6QWh3UDxrikYfnncLIcvnav0O0tpcvN89J5JRk5E0 QwyiVRSr/wi3TWwWfSlFPwKJk6gELS2Dzj40lfIohsZQiOgioigB6ZfRFrFbf4dupWUoXUCFNJtm cp1S9Lf1t1H2RXqUDohW0Q/tf4Dr/iB63ChWoHeO0R70ZD86QP1QIl4CbovfpbCLZlcrTCJCJAir +Id4VNwvLGK7MFE+2rQGPXMfNSpCfw91lfJXoMdKaJ8oFZcLh/4IzzE5LrmQKXM70DMSI/UdykvQ WSmB1o2EhHjkksinGwJAzw6QQF3GI9dchpRTghGRiEYJCdSCMRLj7aRxmClv0VJ6nibqO+gB0RX1 UMSqACRjlqTQJP0dJV4I/ZTSR+kj2YeAE6uUPjK37+1i4Ys7ZRb0w5faKcqP7bSSkuRIoyY51IRe VNCmTRjTiRShH9WPKp2UTlgNryE9XaTTdjGI+yjQc4FekshphwzM3QzqhH6u7YD5mM9xmB2XB/oT s+gq7s9An/r6c2VbX/qhf+6f7+t5nI7wjLxM7JfxAch0rKZ/Qv9ErK9/6V/q34vvxDaxiQ7h/dx5 Ry28UiN4rOQqjYNEuUbnoB79sE7HoA5pWKU/UG+kpmEM36KFsPZj6RNKFYPR8tvFa5jnmahznjCj 7ttgDcaiTwrJJVSExgMu1FtHSx1o1Ra2BQpWcjhkd6JkrgFsA/TFU5j+LY9CCQXp76JGKcAKlJM5 09HSCKyxz/VD+nGsFPSf/h7aX4nekuUL0N5I6O0CV0WhsKkZ0J6Mub8Q5VOxVtNQ3iHLY0x/RJlc /SMayPYlH3nuY4ug6d9h1veChFRKRnw+JaJtlUqiuEKMEWOUvuLPcBvEBoSKlL7KYLRzg0JqPTWL fVRPU2D/Suh3wk46Wm4RQ6iUFmNNpNOVIoZepx60lvbQi3Q7LaLfwzbMoWthS0bQCHE/+taOOVZK pXoLTPhapPlcPbv2ks/LvZJl7qLm8/KQYwrSXqRqJU/cLlyir9gj9tATAIlDYjZwSKwF1okjYpMY LYz0V7CJvoCGg/Q5LUHOLcpA8RfYojg6RX8XEee3KpQ6ye4F0SIaRTlmAUHa1WIMRtT3BPn9D+iP 7N9CM9vtdL5nCNq8FfXdCjcL7k9wT9EPWG8T/fGzxUroWidmiHX+kqrfT2P8hx6xUTzBO5wM70F7 PxQ3i+X0Kr0hHhJvcD1lynGE/e0T88XwtrYG/A+o4Zd8sUQkSnAftO+H8/2hdvAvfHbQ3zr4gb6d R75eCSXfIaSOkljfRDGR32sx9+X7ftRVPmgPt2UIZrZ8RmDnmof1OA9WGRBfYLQxL7CalmE0j6Df 4zAD1orZsNhxPOrr/KOxEnPKLdwoNU8cxix4AXvdLWKReBHWN0xJQGg8LYcl+UlaY3bjMDt8ZTbA 7aKX6WUxT8zDDvkqdpRI7HfLaKK4DjPwHN59rpzmi3D6ir7CKDwkzHRWFLfr7UAvyJkyy99/srVO uClYH17xBsbrLkRJewq7KerFVGAjXD1WQL24CUgT3WDNp4qp6jKcWR7RHxF3iqc49Wq4SLg0+l5E A5+0uXpR3+H9vHOKnkBaYP+8VHTYO34JgT0jsDtcKi7YOTog7bzjOgTk/0JeWIcP6DAgbWEYLGwJ ZpBEBlxAijzBJcBOy/0uG3WGLHEaY95X9BPNcP38Tq4iORMDs/HCVXSp/kVW26+twjaM9vtDzse1 rdCL4WLPxVbwhSv213y5ogMIaov1PYFVfqEf0Phrvt86XNT3W4tf9QP9CasiqoTvrgBfTBbz28b1 YhBok9+a+sffZ4mkP9HnsBvtp8n0PsZnFdbhm9hbulO4Eqf0FplYsYPFeqSMhuXoL3c0JU7c1NZD gd739zrSfXZQwM3D3u63c+2B0beKYTRC6arEoQ7jsf9+jTlcTlbs+A79A5yDCLeTEpxdCe1egTsJ rrZgCQd1ph44KeByiPPtBpSfj3CU/hZaKc848nR3A2XinEN8Ug7nu8oJSL4edmkMteLMFM/n5d5Y PXI05UlZ3lBW0R2QlQN3FdouxEBKEbvb2hnetgZy5coVxrZzYODMKTUHbMBCkYqTpu+RaSjPp/cL bc+FNiZwqg/YgcDpfhmcXOMDYHk3yxq3SZEr3tjB/ki7MAh9E4HekifhfnAzUIMlOKMR0u04E+WS G+PTD7dTG1wtzpKvsPU/iHru0/eRATmt1BW5LThFjqehcHGo14O4F8ry6aiDrNMc9Fw3vg8uwqlL 3gkzIfcOvBdhZJYidSlOWSkouwQaM+hpnPvyMVIy5cInXNpDEYQb3Q2wCt/St6I7fS26KJ3EMHE3 bFirEqwEixFiBN8CrWRVBuN2uBmcIH2shv2cYwO7BDFJdIaMPFECicNwa0vA7Q+Me668u/XF7c0i TCh9BL4VrlXqUJNYlpSQJZ48L022lst8hzvfdpTKkqXhZMkIlprg83Fi3opyKC3iRZNC8l4NF4Hd 9pCSLrIwq45AYgS7q8Wf/a1PhqwUkStSRWeRIVQRRO/BPvajb1B72cp02osbU77+GvpvPBmpmMd6 KvqxGs6K/dhBb2Ht7MM6noyeHon5fj1lYd3PpQXwt6PEXOTWUG4bznzxOInn4sTeiYbhxJ0qq4A1 RLiFnNJ/gHtXfx/lrsUNxDe72j898N4JbheXlvewKeiNaHFGfCfXPSR34buFvP+GUy/9W8w8M1Xp re1kjMQdzME3hBK+EcpdLPBs4f1uIA2X3114v5MOOXA3UYW1bReXq0+uAbnzoQTruZGKpH6uQ2BF yBtKJ6yKAKSkY8gxmG/I/fR/YG3GU0Wb/hzMVdQLN7ci8R5uIE3iMXEMM+8x8THwmDqG/k7dxXix GuOIGJxcP0L8eOT/GDHyO9lJ3FKMcMnAezjpsLVos2E+O7ZQ3vR/hl86iVRj1Z2/1XZEwIJI6xNA u28GfM99F/MiAP83hA7fEtpDjtkKtpdzO0BaogsR+O5w4feH9vfmt/zzKnBHjvafWqQLfKeQ6EX3 8A26Em0d19Hpu3SPfpmerofpIa17W/div2hzeoP+sN5Lj2k90/oNerSD0w/qB/RkPVGi9ZPWT3Bv 2oMVVyhBR+BIb9Vf0V9irNRXtvsmNV7fqS9pfaX1JZY7tqPTt+uqrra+DMvYwenrdVdrY+sOxpOt y7j2spaoC3bVzSx5LN/LXb/axl9pyyXpPi/9YMCJ72CDvpO2p53sj/TXcbfXKAP7/HqknKUf5fZN H8NhT8XN3AsLfDdSAn2wDU768hx7Cv33Oh2CdevTrj7N+qf6Zn0z9VZixBm6n65pW13ym2IUdhr5 LUweFB6F+xjuUdg5C1wELPlnfpcFN0Z8DHtqFc9xrhglGOO2A3ZWzlIZ/gRzfiFNgMvD+v8dfYSd PA+nki7o7Vygli7Tj+OeLnvfBqsyEHN1LO71JL//Yc410gq6DXYgX1ph5IiEzXmHtsIGqyJOKGIA LHIkdpOrhIJ78nt0EvGdRQGss0GCPoPltmDH+pzeRUoKXE+4frDlVtjwaFj0DCAVp6t+KHclzknf wL8DlmEcbkFW5EvETvUNxwyWMeeNpPIx7cDNr6sopzMiF/fCdeIb7EKBU3PgqYf97IcVZMegdaae aN9x8ggV6/lRnHjaPwulBcUecRn65CDboHzkluvvKvVOjECkaGD77psZuHmIbdQMWzZNbKA9IhZW 8Dm4fajHHsyAf/8Wwd8pOtwEAs+F9++Lneov8gTu4xfey3/mB07iF9w29Ddhi9dj3hD6aS5sUlda iV4KE1Ekf4fxCu3Uv4Ql+BKWPAGpxF/JP4RNPcFfyOXdPw2nNB1+PxZYiNbvxnxchnAR2iv3+EzM k7F8V+uB0Y0Xy+CsOIHn4bzxPs+TaPoJcycFZxgHz55heOtJ32FOzMA6iRVXIN/74kvMsv18fkjF aSGFcqTFxejuvtDK0I8+h3nG7kLLRp/C/QQXeJcndvl1LhanSd9eK7+g9sEsC0I7LWhjLp+db+Bb asC2z8dpDzu3mOBz9AK9IOrk2kWtXmj7pr1Cft+jK3gXk7uWnIWVvNNPFK/gxnoNr/4sisE+FSPK fV/R4edgLZajRybBTvWj0byrWOlxrF3fyO+nU+JDOPkFZDc7EyfgpiLkE6SqWNWCYoK+7NRC34fq 8lann8MJIgyMcz4YpxtwBFr9E+yB5M7MUeCzOBFFgrvg1nEW88II7gb+EXcmee7owRxNXXF26knd wTHMsbi3fI+2RoPjqCe4N3MftPA79G0s2MRs5jOTBeeEbzG7JONmpJ+hvthPz1AicxKZwcmUoJ9G L0hOISs4lfrq32AMJKdTIjiDkvSvseIl2ygZnIkzz9c4f/XTT1F/SgEPoFTwQFjzk7g7pIMHMw+h DMzoobAWJ3DSk2wnG3g4Xa7/C6dKySOoP3gk5v5XOIkNAjtoMDiHhmCN5DLn0VBwPg0DF4C/oFFk BxfScPBoysJ9bwyNAF9BI8FF4M/oSsoGj8Vp7TPcySQ7Mbc/xUk2FzyOuYTysAOUMpdRAbicCnFD GM88AfPjnzjZFYErwf/AbfdK8CSs3X/gnDxW/5im0FXgqeQET6Ni/SO5O4OrqAQ8nXkGlep/x35V Bq5hnknlWO+zcFL4EGdvyXOoAvbiapxLj2O3kzyXJoLn0STdizUh2U2TwQtoCu6n19I08ELslR/g 9lSF8/Zimg5eQjPAS5mXUTXuutdRDXg58wqaqf8NJ/tZ4JXMq2gOrPpquhq8hrmWrgHfQHP1d7Af Sv49zQPfSPP1Y7SW+SZyg2/GCf8o7J7kW7E7HIU9XAK+Dfw23U5LwXfQMvCd4CO0jq4D19Ny8F3Y gQ/TH+h68N3M99BK8HpapR+ie5nvo9XgDbQGVvR+5o1UC36Afgcb9SDzQ/R78MN0I3gT+AB2h7Xg R+gm8KPgN7FP3AreTHXgx+g2/a9Y77eDn6A7wFuYt9Kd+n56ktaBtzE/RfXY6/5Ed4G3M++gu/U3 YMHuATcye2Dl36Cd4Ndxn7kX/D90H/hp8F76M20AN9H94GbaiNvXM/QA+Fl6ELybHgY/R5v0V2kP NYCfZ26hR/RXYOkeBf+F+UXarL9ML9Fj4JeZX6HHwa/SE/pL9BrzXpy0XqLXaav+Ir3BvI+eBKMd +l/or8xv0p/AB2g7+C3wCzhH7QAfYj5Mmt6Cc+1O8NvMR+l/9OfpGD0Nfof5Xfoz+G/UpO/BWUby +9QM/oCe0Z8jL/Nxehb8IT2n78ZNR/JHtAf8MbWA/0Ev6M/SP+kv4E/oRfCn4GfoM3oJ/Dm9DP6C XtGb6Ut6FfwVvQb+F+0Fn6DX9SY6SW+ATzF/Tfv0P9M3zKdpP/gMvak/jfu/5O/oAPh7nPOfxtnr Lf1/sHsdBJ+lw+CfwLvoHB0Bt9LbYJ2O6jv/lza9879h03uwTY9mmx79b9h0y3/Fpl/GNt3GNt3G Nj3zkm36ULbpQ9mmD2ObbmebbmebPpxtetZFbHo223QH2/Qctuk5bNNz2abnsU3PY5uezzY9/zeb /ptN///epnt+s+ltNj2EbXr4RWx6JNv0SLbpkf+2Tf9PndMv3aYns01PZpvej216Ctv0FLbpqb/Z 9N9s+m82/Tebfgk2/fn/lU3f+1+26b7fk0v09v9l7o2+v8gVdWTAaiVYZyNigmFdc2B3xsJyVGNF z8b6XMLf1ixt8TM4fj7Whq5/9HP3s7/8Pf+lMJjO/8GwopD/L4HbZQAMv/K5sa/fTwcyfcEhHXOM KkRFizg4roSofPyECvp/5/mv9bbjyooJ48vLSkvGFTuvumJM9sgRWcPtw4YOGTRwQP/LM22XZaSn pab0S05K7GtNsJhN8X16x/WKjekZ3aN7t65djFGdIyM6hYeFhgQHGVRFUHqBdZTLrCW5NEOSdfTo DPlurUJEVbsIl2ZG1KiOeTSzi7OZO+Z0IOfMC3I6fDkdbTmF0ZxFWRnp5gKrWdufbzU3iYnjKhC+ I99aada+4vBYDhuS+CUSLxYLSpgLYmbnmzXhMhdoo5bOritw5UNeY6fwPGteTXhGOjWGd0KwE0Ja T+uCRtFzpOCA0rPA3qhQaCRqpfWy5hdosdZ8WQVNTSyoqtaKx1UU5MdZLJUZ6ZrIm2GdrpE1V4tK 4yyUx2q04DwthNWY58jm0G3mxvSWutubjDTdlRZRba2umlyhqVWVUkeXNOjN13qu+Djm/CuEd82r uLl9apxaVxAzxyxf6+puNmsN4yrap1okV1ZCBsoqiaNcdaOg+nbZizE2VERWXzbF16gaa4GMcV1t 1sKsudbZdVe7MCC96jQqWW7x9OrlaMY+3avAXFdWYbVo2XHWyqr83o3dqa5k+c5Yhzm2Y0pGeqOx i683GztH+QMRke0DNW1pHOLsMlRU0tadQtbIOgbTQDPPMKMmFVY0ZKikmqFUN2MosuGpFCilVWMY 5mhhea46o13Gy/JaUKLRaq47Qxh261dfdoyp8scEJxrPkAzKydE2wZAeCGtpaVpqqpwXIXkYSNRx JL8Pykhf2qTsty4wmuGh+6i4AsUq7Tb0ucUiR/W2JgdNx4tWO67C926m6XEectjSKjXFJVNaAik9 ymVKbSClrbjLium7i9d1Dy00qe0nyhjdrWC2XRPR/5fkGl96Uam1aNzECnNBncvft0VlHd586UPb 0vwhrVtehRqn+ENKnMqpmImT2zLLl4oIzZCIn2CeydVNIaGYihwjzKM0o2u0jyvDLZZLLNSkn5Sl 2DtfzF9NzZ7W8X14h/cO1YuoU1FhQ5JSVDaxri68Y9WvStMiErWwRMwKLTJR68zhbome6M7laWat sysRBiSqjSUJY3nF4ThLpbnCrJWlwrJkxZy0nczSirHctU6JmK+Sg1hWFHMkC+2RqPVMjBHGrJ+y ho2wxRw/KbOFJ0r1UcyhiZoxUevC4ehET2wXWYMurLtrG0uin9VAVsCY9et1iOKfnolabGIMGbNC fyJ/Xdg+aMLX+cUVrriqSrny5E9QYnmFFszda5Fm1N9fnVmFkX98YsuwbjVnGn6wSitv8K1Mi69Y uwcS1CRhHDM8I92KEHHInGTFD2LkpDS7sAwT64bGWS2VTbruklaVO0BxJZplcp0LQatWmipTk8xx MAeupEoUU5F3FLaSurpRVvOoOlddVZNeO91qNlrrmtVoNbpuQYErsEib9Gdui9NG3V6JeTlb2GGA FMpttIpbxjU6xC2lEyuajUTmW8oqPIpQ8ly5lY19kVbRbMY+yrFKW6x8M8s3KhLoBI8SyklxzQ6i Wk41cAS/z2gSxHGhgThBM5oUX5yR4/DIAckrq2i/KrlDKzOwyhsnmHJGGATZgExA5VA24ASmAS7g TcALnABCyezPuw7Y5E8JIpOqkw3IBFTKBk8DvG1v64BNQANwEggih9q6s1Pn/qacQrUVRVtpAbAJ MKDo+bcTHLPO/9YAqBSFg5ysdBCqGoSKBKFqQchlVn9CvFE9S26gAW/HAQOk/4hKSJwlJ3wX4yzw Ez0P/wBwEgjXW9Tvd44r7U85WeoPEPQDavkDFQMLgFpAA44D6AewTT2HFv8Awec4lwuoB57Hewv8 A/7cnSBH5jiHHOdoB6C1yyVznATCoP4Hz/B7+zdzILILB87stGf1P5DTXT2DttUzR4FtQDbgBNYB O4BgqDntCYvgcqc9w+z9c2STTlMWDdBr4ZfCx/vOcSXo93hEZANOQCYeAIIg9zQqeRqaTpMsaoC2 09BwGv1/GqOBGIj42jPYzlq+9lxV1j/nKhnChWgA+4f8/tN+/1G/f5PfX+v35/v92X5/vN8v9fsj /f4Iv5/l9/v7/cv9fqLfT/D7Zr9vYv+Up3RAfU6Kegod51I/w0h+huZ+hmlUDG4fUw80ABrQAhwA wqjeYCCht4BRL/U7ZQKVkwlyT7LcOPUky/0UUj6FlE9Z7qcdYuqBBkADWoAD6qeesK7mHId6I2bP jST9YsCAUhtRCpd2oB4w4F61EfNwI2bbRuTdiLwbkXej/JMZ9ShSjuKic1w9hPlzSF55wEbADGQC DiCow5uqvqhMw4XApG5WpniqTTZMAw+mgQfTwIO6H1cPQ9ZhlnUYsg6j9GGUPozSh1nW+TdVnehR q01N6l88edJ7Yael2hSVc7maB/F5mEl5aFAer8tcdFIL+DigYEblIjUXQnKRIxdNzqUgtVBNoySU zFLG0yD4w9U09u1qOvvD/P5QNc0zCHoS1ExIycTczJQ2QU3GWzLekvmtL9764q0vqpkJ7ouSyfAH wO+rWuU7BtHs6RbL89jssST6A5f17/+calHKaThnsewsKOzvyumk9kY9e6P2yWocHQUUJMZ5Lu/P xeI8owr9AdiPnC5qT2Uu6+qhnMFENKnd4afA7+b3TZ74XFOzyFEqMAqEeRSB3o5AV0WgfyPQNREY 5wh0TwTURmBGRGBGRGAeRWAeRaAzIzCPInZ27trV0aTs9fQdsOkZ5TU6obzmKFfMFrEp6ESQsslw wqBsUk+oyiblhKI8H/x8iGIKzg6eFuwOXhccZArJDpkW4g5ZFxKUrWSrTsWpGszx5gRzsjndXBhk jDdajAnGZGO6sTB4Ws4c5RoM4jTlPdyv31PcoYRm1Sp/Q5xZeQecCXYACrnACzhUC67nUANY41AL 55Zlavnd2FZO5jwAHAdUjueyyjvKXNZmVo5ByzHkPkaqckzZwrFG5ShS5DqQnAk4gGLAoBxVNnKe Lcrb1AQcA1TlbeUaLCyTcsQzMMqUc045oozn931wb8C9DrcX7jV0aBTjdW7VXtR9L+kA9jTEu4AF QD3QAgShd15H2xqUfXJ7AjsAFyDzv07rgOcB7LLIbUMom2VNAwtao6ykFUojNK1RrgOWAyuA67GA 1iiLgSXAUmAZxywArgUWAos4Zi4wD5gPuDlmNjAHuBq4BjFu6KhhHW7ocEOHGzrcrMMNHW7ocEOH m3W4ocMNHW7ocLMON3S4ocMNHW7W4YYON3S4ocPNOq6ADgG+DlgOrACu5/jFwBJgKbCMYxYA1wIL gUUcMxeYB8wH3BwzG5gDXA1I+XaWb4d8O+TbId/O8u2Qb4d8O+TbWb4d8u2Qb4d8O8u3Q74d8u2Q b1fcjQZ7jg4FdiiwQ4GdFdhYgQ0KbFBggwIbK7BBgQ0KbFBgYwU2KLBBgQ0KbKzABgU2KLBBgY0b YIN8G+TbIN/G8r0s3wv5Xsj3Qr6X5Xsh3wv5Xsj3snwv5Hsh3wv5XpbvhXwv5Hsh38vyvZDvhXwv 5HtZ/hplFibSNmA7JtcaZQZQDdQAMzl9GuACqoDpHDMJmAxMAaZyzASgAqgEJnJMKVAGlAPjeehn 0dXQU8N63NDjhh439LhZjxt63NDjhh4363FDjxt63NDjZj1u6HFDjxt63KzHDT1u6HFDj5v1TIOe acpWmghdcrHMAKqBGmAmp08DXEAVMJ1jJgGTgSnAVI6ZAFQAlcBEjikFynJwUIWmaazJCU1OaLqC NTmhyQlNTmhysiYnNDmhyQlNTtbkhCYnNDmhycmanNDkhCYnNDlZkxOanGiRE3qcrCcbeuzQoSA0 A6gGaoCZnDYNcAFVwHSOmQRMBqYAUzlmAlABVAITOaYUKAPKgfE872ZRKuuwQYcNOmzQYWMdNuiw QYcNOmyswwYdNuiwQYeNddigwwYdNuiwsQ4bdNigwwYdNtbhhY53WYcXOrzQ4YUOL+vwQocXOrzQ 4WUdXujwQocXOryswwsdXujwQoeXdXihwwsdXujwSh3KSvG4cr3ohVVyFqvlR6yaR7A2GrBGNmGt VGPNTMDKKMQKycNKycKKycS6yMD6SMc6ScZ6ScSqSMDqsGCVmLFa4pVZkDkTMmvobI4Vtf4RtX8E dWxAXTehztWo+wTUsBA1zUONs1DzTNQvA/VMR32TUe9E1C4BtbSgtmal1BEbf+/31aZbgYXAtcDl wGVAk+jlGIST0VmgASgEsoBMIBlIBBIAMxAPUHQ0rmZdu4Q6cnoqIxScAyhSPMe8jvlO5mXMVzIX MtsdPYsjnyuOrCuOdBdHTiuOrCyOHFUcaS+OfFa00mrk+MTRZ3Xk+tWRN62OnLw68orVkbmrI3NW Rw5bHTl4daQNYbP4UmQh46PM9zLfJZnOMn/PfJx5KnMWs5k5XmR5IimsSZzxWEag3ac9Fie8rzyW 6fC2eiwDTbvF42TBjdEkNnssUxH7R4+lBN4sj2UQvJkey+Xwcj2WPHg5uyyZph8tTQbhiDJ9aFlo Omi5wqRZhpkekXEe0yZO6mRaaEkz1VhSTdW+6Ak+L096T5tGWLaZMnwx6b6Y8m5h3cLqm0SzY0BI /ash9a6Q+syQ+rSQ+tSQ+qSQ+r4h9aaQ+j4h3UO7hhpDO4dGhIaHhoYGhxpClVAK7d6kH3eky98n dA82Si/YINnAYaMiWf7qQRApIlShK8j1jDICx4QRjcoQrZtapBSV5ooirWUGFU03a9+WWptE+LiJ WpA1V2hdi6ioLDdtUUyRFltapJXiwt6kjNBq84vMeLTYEn5tya/UkjjYJAjh/v6wA2G7P1yLcKE/ jPyV2pC0oqYQvUQbmlakhRVPqmgU4s5KvGnKLZBSVtEkdBm1Nk5+Gm4mIUxr74iTvr72jspKil6a HZPddWSXYaPyf4Fcfk47/8ScD0rdxcsdEabtIaaCENOAEJM1RMYXlSKyfntIfUFIPQbCFxnTR7u3 qLRC0/ugYf5AEUat1Dy5olnJVkYU5DcrI6VXWdEc26BkF5TI+NgGNLItHxZnNvJhbWb781GizEeJ F+RLUEbKfMnS8+VL4HwJHfI1FloK8hstlkCeQs5T2DFPQ8c8DZynwZ9H9eWxtMvTbShZOI+l29Cf 5Um4hDzJv5gn7WJPTe5Fk9o/oplKhLdx+FL5Fd9lLagBXNptS2fHaLXTzeZmGi68/g/8Sa7pM2ZL v6qmSXitNfnacGu+ubFk6c/TtaUyucSa30hLC8oqGpc6avI9JY6SAmtVfuVO56zsuR3U3RpQ15g9 6xeEzZLCsqUu59xfSJ4rk51S11ypa67U5XQ4WVfBHLn6iisaQym3Mm+yz9+pdArHrHfFWSpzo40L RvISGG6JWR33DK7+W6hTWqUWYc3VIgGZlJGTkSOTsPBlUmf5Kxp/Uszq4Za4Z8QWf5IR0V2suYQl 8LOnIP8/7xbzs+gSnkvJSYH0xTEFc/Lb//CiTluctgg/aUvaBOENgmmRP2LxojRCHzsiXMmudFeh 6op3WZRFiypl5HO4Vclbj7xfCcSJxYTJ5+8aFPQ/kOILkBRHMgayhc+TVYSoZ4jU1RBSKRYtXoIc S8jn/8ITSPD5kgEIDgSWpBEZPgH+QHHw49Xp/O+OvX78vXU1p/doPQfzfhRmfr8fvmcm7RfJeJfu XnoSXAncTDeLm0Qsx95NW8Er6Ea6Rzae1sjLoKigpygF8e9QGo3n/3/oB7x1pVeQvl8/Rbl0iMo4 fz/E3Yf3l+T/46OYsNXsNyTSIaEbvhBd1cdoqVgjvlGnQf59kNCqPK/L/4NmLT0Ymq5vpyRy0Dxa SXfRQyJKJOjz9XcomKKhu0B/TH+NqpDaSE3iT2qxYZW+CSVLaT79gXaJywwuw95zH7X+XnfrBymC bqXHRSdhkf/kMyhVn0C9aShl02R6w9d6YTaknNNb39cbIT+NciBpDbTeRfKvKU6JfHHIkBRErUI3 6W/o71IIjUTZ9fxvtYwiQYwS25Se6pvqj7hSx1AhSk+mGppFblpIT8A9hVqeEAPFIJGv5CtTlFuU 9cqL6t2GVYbVGJk19KwgYRCpwiGKRKnYJg6Kg+it5eqqVkJ9zGhvHhXQlTSF/7eAe+k1rvU7dE4I 1GCmcItV4gHRIPaLD5WX1DLDaMMX+kz9Rv4Xrl3RXxZKphGQUIbx3U47qRmlP4TGWNR9gMhG+36n XKksVQeqxeokdaVarz6mHjZMMGxvHdj6L32t/sj/Ye/Lo6Oo0r7vraquXtNd3emktyzVWTpJ793p hCQGugIGSCAB2RTHOAQSIBCSEMLmiqiIgoqKGzLKOA6gwyuKqEEdZZTPz3FwhuOCuAwyDoOiRhk/ wBkh3e9zb1WTRGBmznvOe75/4uW591d3q1vPdp/bdleSryQPJj9J9sF8ZpSHAmgCcHoaugJdC5K7 Bz0Os/4OfYi+p78r68Cr8UaIyP4LP41fwQdxgkljfsOWs/exL3CYk7j7uTcT5sSvEr2J75K1yZnJ s/B8s9HNaC1o26/QVtC43TDbZ3gcnogvw1fiWTDjGnw73obfwN8wHHMV8zzrYRez17DXsvezp7hC 7hruA9WyRFPivsSeZDi5BFa8NvkVfdeTA42AkGYauhq1gWZ0oWVoBaz5OuD5alj5rTTdCU/wX3DP F9HLwJcj6Bt0CmtxGjbibByGVIFHwVNdgXvwevwwfgJ/jr/APzAYVuJjyplGZh7I85fMPuY95i/s NHYH+wr7Hvsel8k1cNNBC7dxT6uQysyP1Ow/89HZnf0P9W9KMImSRFNSnXQls5LjkjuTbyQ/Sn4L lisiP+hlI9jUdWgDaE0vSOoPoIEHQNZ/Q1+ADqlA38y4AHtwA74K3wScXgO83ox/BelJ0JyduBcS +fXRXvx/8AHg/of4CP4bPoNBeRkPE4IVX8XMZa5ltjO/Zd5gEqyedbH5wM9qthV4ej17G7sVnuFd 9u/sD5yRS+c83CVcK3cv9xvud9xH3BnVOFWDajlv5tfzdyueY8CfkDiylonB/AyeCfZvAI4/z7zJ BMAi3vlfSLfjH9BbeDT6G+4HLb8d0k3oS7Cjy5kx+Bho0uN4BL4X/5Jh4eR0O96LtqBfsjvwQeZm tB6sP4i+hhwz83EQr2WywBvewzyH/gqa8Q7Yy9+ZcYDfAUnb0TvsO7gLzhLf4zsRebfaLCYDzcPv ogq8Fl+K2pkSlI968Dv0nRBIJXFY9TPwt/OI7+XuZ75i7sffwdnsMbrm9bgZbcEloG/v4J+hncxn XDn3W9DSsWClTug9heHxStDNzQyHtjFvgu4+C3bWCFbxIFjvFrCTGlh1MepBY/BlEO/+gLXIjG8H bb8aLPN2WM9v0G9wP5uAe41NvkTpSyYMen4//Q3hHlSAnkrehV7Fs8GOd2Md2oz+giayJ7kM2DFO cNmq2iSTmI0OJS9Db4PHEtjDaDz6BK8DvzEefYwz0SPJ9mQMtPGd5ExY5y1oPpquqlHlgDduhtPr 79Rb+MN8NR/hseoaVYtqimqCaoxqhCqiKlG5VQ6VSaXjvuP+zB3gXuWe4FaD7Qa5DM7AHgb/+Sz7 MLuO7WQb2DgbBJ3MZjnmn8y3zHHmU+YQs5d5krkRPwOr/CT5VvLh5OTkyOSIZHoikTiVeCPxdOKR xP2JuxKrEl2JWf37zv757Htnnz37a3y6/xD4r9/htxNnYA9YmrwyOTF5GuzNmrwvOTLxIb4bnrEQ 9YN97Qe/eh/I5Qng7RXg4SSGvCsrgU6hPuDQQWjfg7bTN/3NQjP4aWgSyNuDyLcnZW1sBV+7Da5Y kJUFdoA4cHwiyOQqOFmxuAh22n1oR/KX7HSY41lqLNuYP2Ex8StUBF6mA/anCeiveBT6CtJutLt/ E/kVNL8N7rqHfxKd4n/BnoEZ96B1TK3KzIVA5/uZTnxn8meJn9G3Luzh/oamI/JNMqJ581TkO25q dImUw6tPMBipuBMs0vGqEyzLOLVq7gRGDs2Ea+2+RuFkdUN/daNwurpB6K9G8er+akKRcKnZbS50 m93zOHRWZPeelVToDBK5veSs+Eryc5ZThWE/yEaXS3qtXmtiVHqchrhepk/KcY3J0FsWCfZFSMgV QkJc4AShSzggHBFOCCqhF7c/F9Zh3SuMDg7hjTiI7D7hdFNf0+KjwlEU7z8Wj4RR92LM8nx+nqeI 9ZTFykujmRlW1koq5CsmWclVeL0VXBV39djan3tGV1WNrrnkkhqutv+BcFlZmFkQMjX+fFad6cx7 /pEj/b6R1fIZdxv7MvcB0sDKR0t5RtUhpNNqMZyCdU/qI+YntX/CTzIRzZMhkC+DHJYle3AIUSY1 NZzsP3n6ZD8ssFogibAIu5U1DgAN1tSo3E6XqMItBIougNwHiUxPTk4h/louEQNxCeLOgu2XID/z oLTQJ5ly4h7fCN883w2+u32/9/H5Przd/Lb/IwReXDhoPuQ45PzC+4NDd7ljHtNmnutYgld4l/lv M6923OK71f+w9wF/msqc5tB6Vf4K8wiHhGuYMWk1wnjzDOYKc5rXDvObyU2svcnDktGVFRPyIDOT zNGb3CtVALA5ShiP2esodBaWeLxlQoXjNkFX7S31M948kzWOvL4S7Pf5GCkDa3V6Q5rRJAjml5hN zCPM5hdz6iSP5JIyyWSWNEkrGaQ0tTsvv6DQU1RcgmoEuR/sdHXJvcgJ5AFyAWUCGWCUIY0f+KKd Mq1khnlNUhoz8I28VEtaTh2Sv7DncjodA8vw+c0+hullFko6wWyFFTp8JSXkUnQ6rNDT7HfE7IzF m4cs/jxkgjCK8CUEZS/TD8qc53brYB2Od8y9zExJy8HRgfH5hBJypUNOwVng/LmTc77M/B12EYaZ +aJPGCu8LrBCL/P35wIbKkCbTzb1EbJUOkJN9r6+lM6cXOxrqu4bQw7z/uTe54SMuB+49RzcnZYT PHJZbKXlLmA5PQDMFOQxXnmMVxnjVcZ4lTHeIWPiR/tuUwV9t12/77agnRTIXCl/zqEWqqvV1dXP 8uSrFrt93jQhhnwzQZt9TYvlk0dTUxNa3OTDbjW1Oz7fTc3OhhXzU+GobVB9aameYZsTxmi0Ph6v T3xTHx89EY9eQy7wy/ih8bbgKFobr4+u+fVWXH99ZTBQWRkMVjFsHhSV+KxZcJeTqkAlrscPJBaQ j6S2g4UUgoXkoq8lG6iAU3JIhaBiWl6TUj5zjWWIUjkUxSpUlEsrK5dkMKntDqcrKzsnF+H/fMzA lz5TKuegyuiAtcgrOV8pdTl1RLu0Go35ZYb83F9gZryAfg4RGYOJZWgz0+LY6X7gW+JVToM6NPQJ RD/iRwnjQQjmISwvLTWneC5XM+/8iTCy/36S/4liZiHJ2e/OHpb5GqhU2FoBGXASziyI6wdORtn9 zyO7YGfsVGP8sWhv8ssXqsoi9qoygC9IjzhM8YgE2eXRt6KHoqzKpndk2FwOzmnLcHhthQ7OEpaK q2KIZGEprxAQZGHJKQKCzISw3RQW7KJdsh+wq+9Gd4fXRdZFH0OPhR+OPBx9Gj0d3hHZEX0NvRY+ Yj9hF1ojC6K3Qof7Ipuiv4o8FT0Y+Siqe9/2qf0Tx8eRz6IqlBK1aYjVK7IURXeqNgMEo5V0klEy ceBtvD5/IBgKvzZE0kYqVeZ8qZIpU3IUTINrU98KdoupWi3INxwZF8GR3uSR54qjsQjhZaxKLuNT oWQ+kbLsDqvd7rCh6PgojorQLSpBn6gEHaKkQ9Rugw42RyQcteGwNLXsMThsIFKC5tsiUY3Jngty smtsscyYM+ZgIjDse0mP/ZrioiItqBfI8MiuWWW0mCoXk+VirFxU0+K50WNipJRGVFTGOLvV3mLf aN9tP2o/aVdb7QX2afZbaMU++/t2TYE9BhWkB7lU20GWIfJYVkM8RJXXoo+HQvEQE+plZkhWcZX7 AJyq3YJbdIfdnFsqKXP34i8l8Cci8aowDEswBJPeDsEkja6NmSSvP3a3CeeaQibG5Cj9/VZ5ewXP A3EIuJ5qYhWLq/uboMJhqQx1gyNSPlWxp7be09XxkyePmitDTZbKSktltw/+YQorbwuSrosVt6dA 5fNd2ePtQXZ4lDS9C/QWMkQz4jHB+BY3oZQPpB4Xej6XPzYODFwlGd018bAEGSIZMSHJGLBBFWSI ZHIVOGKwEdgsSUYNzeSQm7INpMlAmiCL2vUWQJCFSUZ7pJFNVjKRbik//pP/ZsISuykzfE0/dRVm Dy1sGNtovdr8E0/C5mNPPXXR/68+PqqmfES8/i/Yhi1/rY9XlNWMgvrv6+Lxuglf72LD/b8YcCaq Ci94k/4HmQXgUrwVqrOHqwJyGzOn/wTx1VPAw6wAD5OPL5Hc4Bmd4LHt4CeN1Cj1JBTQD3jtlC2l 05ABerCyOUOwgGqyztlsveKRiXe2AdkVb21UvLQOSC+HDiiN2Ham4XzbHrjHwHf6U205OfX5yGwh u7+FMNyS53ISz+10SAYjjYpeBG/t+FJwZRHpGKAyS4KarC/xgHOXrPSN3qswK+AuvAEc/QE4qBO5 E0/fy6x+rpDouKzV4OuFk6DYNCNevxpUvrq6+qK+P0MOec0qswzKmLfvoBIUSX479fich4ppiP9/ nW6+G3BiMQGvExl1Jw9z69htyIe+kxo+Mr9n/bDgo6LjlmPWYwXHi85Yz+TrNFZtPlNuaTXPs7Rm zC0+Y+D1BmypszQUzbT82fpRwdfW4wVqpyPNgFR8usOVaUgTtIILu3qxe3ceuqbE2Mv8uFtwl6i1 vbhe0jJ8pjtPzzfmEOYJjrKunCM5zOScAzlMjjOQ3stMlyxdHow8oifs6fJwHof/j9cpzqChr1FI dDf5GiDc7oPUDycDoa/JDAYOhM0WWyWcEZrI57WCRkrLjOtIpiWZi0RBNmM8ZS0QyGB6fKCsLPJ4 ijz5eXyGNbM0OqJcPleoeTc0lMUQXLFbC4v8wERvdoY9eNkN9+zc/saqy8Iz8r0jm+5InP7u1t24 4Ovp97Lz8uN1t9SPsls6XeGnVq9Y5xQaRnkvHfmzObd+8QnOFck5bFTyM+64ygyK7MVdUkin1xhV GexJIxb0uRm5ouAV9aGMkCh6P/F84v3a87X3rLlfPFtgEiWdPual7haAKGlNNLKT7ABcUnqeSypO y9egAVX/7eBdDqwAo3M/YUlpuj2nTrdGk5meAwFzulqjK3an6W2ZmbnaXuZyyYQ6QXOZvfgIxChO fyGRjDNXmCT8XOiEY9tnwndCUtC8JmDB4au7m0pocROR0OmmJnJ2BJdMpAT/zJXCNyk3+zzYvRAj p4FdehJgEv86ZqVkzy8yWvIthbmoyAhZgTkvF3tMxblI/kT9pptQ3bSVklDi1Ru8+uJ8rsSQm4/1 OixUg8tLtYpua4aYkZevcluhNSPzXCsNXjHI/Jwp5ZeRgxmShWsrU4Kp9Ng5JSjnRubXSfH6E2Mf nvJF4hgu/mDypgn5xGryd920ateWe+95XGU+8woxq2iJF+v/7wHsiUSSlYFg5dlNNz7zzHWL77kH rOt+8ID3gbRLcYPkVrtsriLXCBf3sAczJsFSiogPvMARhoQtOvBO0MoNimoNQ+IWneLv9NQHcTSy iURLER4a3sjNFwhvanLqCqTacbECqWEqZGVVkAWisYLWYnc2srQESlFLwO8X7GEI2ibbZ9lX2Xk7 b2rRapkWjQ75wqdUvfgryUD2eMbtLPNhMyZqIzqFjBWGhEC2+U7hMWGn8JrAIWEyFH+CA78j1ovx symD9jWcPCpU94GqELVpOHqU6ky10BdfDHX9BPT1pTY5JBCdqiafAsAm575wPFwqfw6QqZg1EWeG 0pVpxQUDQfI1s0k++/evTf8sXlGS7rlx9twGXE0D59cSxpTLxN+TvHHNs7kV/tAlasfIQCOpAMk6 QbI7QLIV6BvJ8ZkW83wmX8SzZE9hBLMl3Zphg1DvJebDgaiRxp+hcDhynmnKvyfTQQA3OMyUf30m h5kD06CKEeXyb9SUvrtz6iqQ2IuflEz4VLabU5cUF5vNgs5hJ/IQNJO0uEu7U3tEy2qdVchNKo3h 8KoIzoVw1VE5aZ4iDPpJD5HDYmK+yuE03neyTw45iGfFwPhymb9m5axH+T6i3GaOUW6rz6tXBIPv k24es2DrokZ7eFT9V3XxsKOhIHTVpW0zJ9ki8frj9fGIvZHal8qcmOApHP/IssSNptxKIoaKXAHj JZNEX9kViVWD6tjliixKQRYPwR5WhjMkFxHEg9nsZ9rPchkqDZMsjsxM22A2euh5IBAMhs6TRurH fVrNeU1y4C/m5uYMEYnym8FQUBHJrpy6HCIQMz7lAoGU8bDBwBlCZ8sE7j+v0UrZZVr6gQhsf7Jo TFqsdY7IQblUPMHgqhDODeGQo3yoeIh8SOQ7WEJEREMCWUycq0s5vYPba8IZRGg2IrQB2UBkeGGR lZoViT1YcdukFxZMIyHgHhIZFoSuHrdwSkpeYfsk0sKurw2HF195b+LmczZz85jc4hEzEzebcqpk UZnw9yQ0hN1vBux+14KkTCgLvS5d/SLTyx/UfWT82PJBxkH7B46PXYeyvjD+wPyTT3vT8aaLsfSl H8045vjaxX1sP5h1nPmCP6b72njcom6xL8j6tWqbdqv+qbTtJnUbM5dv1S00LrC0ZPJWt0HtdHN6 gexYOojGkIiOIA69zJwCQdqY6S/masKaLg2r2QM12eQzRkI0pACGNcF/JILQu/JMWgj+IMvoTR5+ DkqI/Q7vgpIGEdQarDyXn1dA2AUM5jLVsaJBO8i1Nyf671yfRGvWJtetx+wt74xrfnTdS6/cfscr +Pllf775psMrr+1bu+7r6+dM7dq1dNa2baDJ7aDJ9wN/SvCKF+Gw9BCPLfTzgUJnmU6oF5idwk4z kytxgyJoVerY6877yQ4xNArmzo90qe6e+43roE8zDGkai1kMhGJmqWYcZO7CmNnopOFrOBqjZY6H li9YHTFcYtT34mzJbSTOh3c6dEgjAosna2YBm/kNGqxx+jCCmJootzkP0YPhZPcsd5ebdzu8g3YE JXBoFI51N5FAON7Q1wehHfBbzjGJ9X6q6umyqtMgwGISGFZgjPkqE2vOR4KZwZhYiRwIwI5DRGsV yKcZZpLRfcpMMkWoi88ZCw2tqX1cZK9hqm+6v6blammkzzPN7fvNqiHbCz1RsetXNY2qj8b8Iye2 tyf+MHRXIdH3g2AP1SDvcczvpDKthS9zWDLL5obXhB8IPxHcHXwjeFD7vu5g5Jj2i8hJw+mQWYfV KrVWXV4cLg+NKxkb0hQQ7ejSm8iZ0RTXIRPW5I9Ao0rGIj6E8guKy0JjQ+NuizwY+SdK4n/k6ywq PWvQhgxhm95qyLbnOpxhS9Wt+nXhd/WfhIzHKv9S9c8QK9pwuMDGlgYNOsT51AXuTIMjzARFkH2Y ZAbyCUIwGtMppYGEc1VlOrmgreWVciuUpPW5yVPJNS1pe/0kuR1KOnocGf2SXByR9GPKwnBzrgjV Vin3IKWkdRbFqqpZg07Xy7RLteGgNRwOsu4R6tzaG2u/q2VNtZNqmdxaXCvlF8ZqpfKy2oMjR1bz NskViNlWCKBvR9wscschYjno1BW5rXoJ9TKzdtU0+oizMHcJq4QNwjPCXuGIwAvOOvXLzHTYXQqY WZI+J7sxt1QsDZeypTQKd+fHSh3jJ8mRr6+p4SQ5xtEwBvwxDX37Fjcd9YGTBu/cvbgp3nebMei7 XtiHqCpbKuG08pNjfLdZPsTAv8Vku11MlNWJJF1afAzJxpKslmSXkiyPMBTKAqUUldItnxLS4mFy LNXRKzj6hPJMjngadWWOeD7ta1bmMNMxpCRzSDYAcENzfBzJxpKslmQX/D7KTEw+GyHnKQ9Yixqc ny2TJHqCIv/zg5ePqDQug2pywCoDP0kS3W6gtlw5itEB7KXRjurlY3O9Yuf+yW3dzesOz3wwbsqz hMF2CqPG0C0z7mwsLCvb+sPUqU037B93c3W62+itEMQRhRXM5tzcIjMsQDBlZRXee1lH/cLcnDRj vL62Pl4SLS7xZ9qLnU6Ls75uYUddiyvLCE3RMfZgkNjiRrDFl7g/Ij/ascuhcffiXVJuYSZyewoL s3ntKZXbrO9yYIfDGigpwV2GIwbGQFkLGu8MFhYgGv56snMykFW0hq2TrbOsXdZnrHutR6wnrDoB KknFKqvK6gi8hDEuQ8qhCU76xO2B1/vW12SuDIF+hMD7NfQfjctR8FF6RhIs6QzHejgLzkZMuiob yScjTJ6XMFU5tHL0k4Gh4fBADBxzedt/cWtpdvElYiTx2ZzXXqN+qp56pWuV6Ld1dIZ7jLPaV5wd mvTrFfgN0riHtO1R4q0c4NTD7HrYpTRSni7PmA5nbMh0RqexTdcmnhZVJcYK4w2ez/Ah05cmvleO nVInkIEjiAnOOdl4YF8aGm7lpUmZUoZkldIli2SmHx1lSdmSyTB4y/ow9fG6O6fEwat1bhJ26bSn ctwGvSYvD6LdWXCS7cI74RjLrgKuO33ulxktedErCbTM5lUWnGvBFod3aKB1jAZaRC70SAJBcLza MrDz7IbDmUmJsCDAIhvT4IMlUe1zIjDTaGBE6ppzkrDpjSu2jG/d6MulIe+JeM2ou9uUHaO/hsRK oeLi6RPKL8OU5f2P1oyMSPhxeddAKKqku8i7rv/niWkZmlitnFRVgxNv+Jdpn/pl9cua7Zrt2o6B pBuje48k/R/S7jF6jMeG03AaTsNpOA2n4TSchtNwGk7DaTgNp+E0nIbTcBpOw2k4DafhNJz+/yb6 O7yp7Fco9dfTF9Ccpa9EyaRXLP1NnYb+RUf5zfEtOKxgDol4tIJVyI43KphHHrxDwWr05rl5NCiM tipYi7LwuwpOYzbhb8+9v7yMW6tgjPTcbxXMIE5VpmAWRVWigjkkqEoUrEIG1RQF8yhddbWC1WjO uXk0yM59omAtMqoWKzgNN6jI7/sxx8K9jPxRBXPIw++nWAX1OrVOwRzK47+nmId6Xu1XMIdy1FaK 1YRv6noFA6/UUYo1UG9QL1AwhwrUUyjWKvyXscx/Gcv8l7HMfxnL/JexzH8Zy/yXscx/Gcv8l7HM fxnL/CdYR55dfZeC4dnVyyjWk9/Sq3crmENe9WaKDfQZDyuYPOObFBvJqwI1GgVzqFh9gmKBznNY wWQeuX864aEmrGDgocZOsZWsR9OoYFiPppziDKi3anoUzCG/5iqKM2n/LQom/ddS7KD931Qw6f80 xS4iU833CgaZaj6mOJvKtF7BRKay7Mg7HHRaq4JJ/7MUFxCZassVDDLV5lDsJfzRXqlg4I9WlleA znONgmEe7WyCNYP4rxnEf82g59IMei7DoP6GQf0Ng+RiSMnlSSSiKGhAGFUAmobmo1YoG1An6gDq QStRF60ZQ9/c0EXzZqhvoz2C0FKD2iGJaArUzYPxPWgJvWqFspX+3flW1AI9yQxL4bqN1oqoEcrl ULbR/s1APXTuFqhfBGU3Wgh1nWju/2BdIn23AZlRHjcdrtrgiqxERFMBNdMr+c4dUBuiM4h07vnK CufQFXfQdbXR3sHzVlB10ecaDfXtMHMV5UA3jE6trQzmiUASUTHM1wb36YaWJfRZe+jf/r5w/6F3 ku8zGZ4mcO5e5C9CjAe8nPKPPOsE6NUDqZ2OmUlnECl/V0K5lMpI5pMsh7n0nj2UL+S6i45bRLmX 4t9sOjbF21rg7kTQAnls96CWLvpcLeTv89AZZZksp/eaA/mF7ytfk75zYNVLqT600L6dkLfQ9i5o kZ9Alp58rzZlhjnKXK00JzoqnvfkpEc7RcUwrgRKonWzz93rQuvqOG/u/5xLA7O30JnmQV031SlZ u+ac090LP/2APg9d1yWDeECeRH6WHnq/lFWQ+eVnbaG6QZ68k1rahZ9U5nTzEK62KtbxUxshXO2B fkvpSLLaZfRpWs/NQ3q2Q49/KaMnxWg4XCFOm98qNnR2dPas7GoVx3R2d3V2N/e0dXYExZr2dnFK 27z5PUvEKa1LWruXtbYEx3Qu7W5r7RYbW5eLbUvEZrGnu7mldVFz90Kxc+5F5xLbOsQeaJve0dbT 2iJO7WnuaYXBHS2hzm6xE1q6xTmdSzt6YOolwdQEVYPvNbqzvaVqWWv3EjJbWTASEYsb2uZ0dy7p nNtTMmNQvTIIxkyeGiCjGqaN71ze3N0iTmjt6Wlv7Z7ZuVRc1LxSXLqkFdYEzzC3s6NHbF4idrV2 L2rrIeubvZKutnb6xBpo7aYXXd2dLUvn9JAnWT6/bc78QWOhbOuY0760BYb2dIotbUu62uEG8Hgw qg06zIFerR09QVFM3byzo32lWNxWIrYumk1GDczVkep9wSXR7i1tHfPE7tYlwK45hLuDbk/5rMx1 CV1BcRvcpad1ERFFdxvctaVzeUd7Z/Pgm8Kim+WlArfPSaRzaU/X0h6xpXVZ25xW0md+a3vXT57o op64kb55qJt6wuaL9upBS3EaaOPxi/aYS23xYq1jFU97kXZ2Lftbdh/7GuTP/tuVtv3LlU6EmvnQ vgzaSc+lF+05jtr/Eurle6g9Xnz1x8FKF6LTMOtxaLlYvxl0pou1joe7tcMMc/9lr8lQT55yKXhE 2eet/I84ctHVc7ncKO4SbgxXzlVwEjeSm8BVXnTGaf9WzhPIU+AI9Ll4D6JNXcCvi64Jm9HnbD54 4YtLsZPuBc3nzlkokU/fHITR+f+xSEPf3oSTSfkvcyEDHH8upWegqyE/CHUfQmLRIWY9wsydzMOI ZTYxmwA/wjwCeDOzGfAvmEcReZf4CcB/Z/4B+J+sCmGWZ9WIZTWsBrCWhRMFq2MNgNNYM2JYC5sJ NTbWBjV21gnYxboAZ7FZgLPZcsAj2LHQcxw7AWomstcCvo69HupvYG8ETP46AWZPsWcB95N34nOY Y8hZipxeOB05M3BpELWzXCZnA2zn4C6ci8sCnM3lAy7gPICLuBDgMBcBHOVigMu4csAjuJGAR3ES 4BquDnA9NwHwRA7OCdwkbhLgydzlcMcruLmA53HtgBdx10LrddyNgFdxvwT8uKoIYVWxyodYlZ+v QZgfzY9HLF/H1wOewE8FPI2fBng6fwXgmfx8wG38AsTwC/mFUNPOtwNexC8C3MEvA7ycXw59VvAr oGYlvwrwTfxqqL+ZvxvwBv5BqH9I8zZE8X/QHEes5it9GsJ6ox54rrfpYT36Yr0XsE8fARzVlyJG H9OPAzxeD2vT1+knAm7QTwI8WT8Z8GX6ywBP0U8FPE0/E/CVhgkQ9U80NCDG0GjYSV53qmgaIR2c Bt9HbHN382xknd86uxtF25t7OtAoaMHTp1wqIitCoHmMrKsUkRnIHOSKvDAVTnETp40XUeaUSQ0i yqL1aEiuIlszEmnupXls0cJFC9GVNJ997jMGZggywymWhxOrhvy9UaQHvU9DRrAEAVosKB1WlkGt gKWrkcscWPlY+tawq8EXdYBHugGtQXehB9CjaAd6Fe1Hh9Ex9C06jQ3Yj2O4Gl+KJ+Jp+Crcgttl ruBymAdD+Q9E/lIJNoiwCiiN1XIpOOV+wna5n1mCFUJpISdSNZSSXG+ZpZTvyqX1JdqPs7XbVtk2 2rbTK95+2P69g3c4HUHHaLnd+brzoPMrZ0Judz3j2uc65PomC2VZ5XmyN8plziq5zL2S9tSIMXG8 eLXYI94hbhFfEPfT2rSCVwoOFBwt+EehoVAsjBWOL7yqsKvwlsKHCnfIq/a0kBzKO+TZPPfKZVG7 XJZcI5feZ+R+/leV8k2qCdifgJL0jZ4p/d9PxBNS74Wo39JQj6UDL5WO9NQDpXE8xyML2HExSqcW bAXbnYRc/BSwYBFsdwbK468ACy4AO8tAhWAlM1BAfwXYShhh7aXax8nZHbxqFKHIGiDwqdFlUN4L 9JCCHwV6AugpoGeAXgB6Bdqug/J1oLeA/gj0PtDHQEcQCj8A5TGgb4C+B4JniCQQioLuRnVAAlAm ENhPNA/mWg1lMVAQ8FooY1DeJc/zE8IXqBtEjMvXFfhH4PvQm75lgQSltUHBd1cw0/dlUPJ9Gxwb YEIFlIzBiYT8o4MboX4jlJuAtvjvCH5KKBANhQn5DoRGB+pDo1Nl4P2QPfAxjEnNf51M/hMwDsi3 OsgB6fzjod/70O9kcKLvR6DV0G81XU8WrCcL1jMF7isFHoI1zIL5NwbzfJuCeX4Efd8G2gLXQH4e 2g1D1rkVaMeg612UxgNuBBoPuBFoWvCA/0qgWQptgPURekCh7cGTlF4K/kjpacCE9gImtD1koLQf 8P5B1+8CJnTo39B+WItMP8J9f/QfBnwU6DDgE2QOkIEGyApycAIxsKZ3ge8iYFJXMZT//hOhWUBz Az2hFYFroH196A5K9wZ/JARtG4AeIPzzW6D9UaAnYCwpHw1tTj0/yO9xIj8ot1M5fhkcC3y8AuSS B3LJ8+8PFRAKeGCcH+SgyFeRK5eSY+AtmOutAX4GRsG8R2C+rTDPDpjHDuvIgfG74JoQ6IG/AK57 g8Vwn2K479Vw3xbfq8Ggb18wCOteAHLvAsoj5PdC/zD0PwDXB+XxVI8+DcZ8nwerYPwyGJ8Fc25U aBelRkUPGhU9GNCTLUC9g65fBdp33viB9n1Ab/vngu60A00LHlToU6DPof5ToM9BPw/4u2n7l0Df 0r4rgG5Q6BalfTP0J/S4Qhv+DaX0VLFH/27QTUJvhhAQP6C/gF8C/p3TX7h+Gq63hyyU9sM1oZT+ pvQ7padfwbMSOg34LNHbofInegqUk9JTaMshFPCEvAF/yOs/rPgTq6y3oO+fUnpXocMygX5cSekn fgXq5Ou3AU8GUvQ+MCN1HRQCUfBhB0LjoX/jeeMvhWtCVwGeDRQNlROC9mpozwFcTUjpPy3Vn95v PlAH2NVXYFerwK7WwDPANdBFr8HG2oG6wQ5vCFwTusX/ANgdIRS8DuxutX8D4A1gh5uh3AzliXPt a2n740r9gL96G8otgafgXs/Ael6Aez2q2O8rgF8PzT1PNxRfe05HFJ0K/Dd11wEXxfH9Z3duloMR RUBEpcPdoSIciIINjaJRIoqISJQQFFRAQESsMVGxxljQ2GNBbFiixh67xIKKxoLGGAuW2GLUqLGL /zfvjvP0pym/5u/PfObt27ezb9r7vn2zt7scNuSy47XSjbkM81dgCz7Zp67vBJ+Gvt6mcsV+K2ud 9lsHx2Jgu7nWTb+dmEMhB/jtNPONE3xWoi05Yj4GtijyOfRrkME2hD7hl4zjHHDKryjgnO8Rkcva 61f0aqo5IeAy5mswT9dgrnPh+gAZsBUJvr9JzTEBN+D4DcM1DMpMAR4yjGkTmEfYh3OE7D74sifg yyaIfchlvs3oU8p8kMlHtHwd834tfZoG3EFsp0JfukNODXhgGvcyDBoxFPDMd4rIZf0ow1LZ/uvH 31UqGxdTO42++W37Jvm0lzbmV/Sy/7Vl3yci/4cjNJlUlm/DGpbA2hP2aG1YgTrQYbDGrAqrvHZk gioK1no5zIctIFPYYrZUKsdWst2SDdvL9ko6VqhIkjc0gEldFbViLSUqNoqDlKI4KlWl3oqT4iRl KS5KkNRXqa80libCKi9Rmqp0V5Kk+Va9rXpLC2Fd5iIt4p15ofQ1rBFWy+Vfxou6aMixRPJuAVtY 1eiSjHw65CzIgyAPhQxxpQ7iSu/WsIW4UjcDMsSUOogpdRBT6iCm1HaHLcSVuq2QIabUQUypg5hS BzGlDmJKHcSUOogndRBP6u6CrkjYwqjrSoGPIcQbonbvOIOe17L0Bpl5tiVaGOn6JBTWUTGwOhP3 dYaSsWQKrKHyyRqylewlR4isq6rL0rlBn2Sdky5F56DLAM5WF69z1ME6W6fWRevsYTRkbakuRmej iwPuvq6pTtF1Au6GLlj7TBcCXInOV3tX1xq4Wzov7TVdDeAu66pqz+mC8aiNtljnANxJnaI9oPMC 7pj2mXanTgbusPaudoMO1p/aWbpy2hU6W+BydOW1edpnRPY6aUjAFRnSf9w2Kd7nIEovWP2rcc1t AzZiKw3G7z9vJjUJ0YCdaIIhh0AOhRwGOQIy2I4mFjLYjSYJMtiMBmxGAzajAZvRgM1oxhHi1RS2 YDMasBkN2IwGbEYDNqMBm9GAvWjAXjRgLxqwFw3YiwbsRQP2oikxnPs3ck1NoeawplhzWlOiuaK5 qbmreaQp1aq0VlobrYPWSevhOUXrrfXVBmrra5toW2hbayO1Mdo4baI2RZuh7ec55c1JfDcdZgHW QPJ9+Xciyw9hRlQ4IwrOiBpmxJZY4oxY4YxUwBmxwRmpCDPShjjijDgp0TAjLjAXtsSV28OMeOGM aHFGqv8Xa5IAL0k4yzWIBYxeQ2MWI9kSchvIUYR4xBILjVbjownQBGtCNKEegABiId+T70EbH8gP iETtwBplpS1YHQV760BUaG+M23E7ovzt0i3Fr73/hlV3eXm8PBVqnS7PJJZ4X7Ec3teyVhepvyfl 1UfVx4it+qT6JLFXn1L/SCqpf1L/RCqrL6gvEEf1ZfXPpIr6mvoaqYZ3tJzwPpUrjNdKsg5HzVbc U3FfSMLdF7ovc492X+2+wUPlHuu+1X2Ue4F7ofthdzf3YtiLdj8NkhL3K5Buuoe433V/BPsh7qUi wRmFkNwgjfKwwrwQk7lGc31Cl0GTUQ+UWAbHrri7eRWjHrMk7nbI08STAHKuvA3GYpe8h7jI++Qr xFMZpAwizcQVgoRyV64lzfFerSNkW+OdNgfT+So4H1ArL5Y3EyZvBV1V8Rwn/LqSB46H+IWfeK6A vIlIbuXEHTG8gws6rHqjtTV5OW6ut4id6zXXa25Rbp2AxmNS3BTPPM98z5We6zw3e+50O+a517MI 2zADdFvKS+Ql0IavZbiKyavkVaB/jbyGUHm9vB5auAVaxaBvhUSNvbLCFnLwZmOkQrziRZKKUHPW v5QlTycS7uoLKRByfchNjLmFcev72n6gUVaW6huP/VGq/xZ5mc4mf3J+WfqzNr7evre16/X2BL6h X3+SxPMiiEKCKJQQhTKiUEEUqhGFlohCjigshyi0BhReJxX+shVLcgt5MthyOYgBqhLiPIJIZpm8 Ib9N/ray5rpk9wDchjtX/YcUDKmMD4H0jyWqOrtBquoc6pz0xqOGFOacbir56rlZJj7CeZBZXUOB RkN6u07zVhlqj/3DNrwtdf2bvf7j/pr30bx3Zemv9utfTsJfmK4f08H3zISriJX6oPog2OYR9RGw zRPqE2CbZ9QlcC25pL5E7PA6Yc/DeTipzNvytsQRrxlV/pb/jYEcATkdPXBlIp7lW0gmwF5Do1eu jOV2Q/aGfPplOcmGPBH/J85UTnjgrwBrEOUZ6sfaXLA28RyYGjFIEIMqxKCCGLRADFoiBq0Qgxyv hNb/Zk1iNAiOBsPR0LxjTWJcxW8F4J1IMY4hPsNHrkEWvzmUvpRJimGeJCczmQvOkiQFmsnqGuZJ am0mi8JZkqQUo0wm/F+yNWFljm+dGwU1EdQkoSYZNVHUpEYdlm89WwUtGw8tmwTtk7BlCtZn8dYz qDxBzjH2hWI7VW+do79T9o9b8qYz/lrPBcJmkRE4nwbkVMFZN2BOAvSVyWSI/WbgfJqXyzPMJtlk lP37cPXH+DU/+o+9/2tHRZ+KjTZv6FNVlN0lZ9DmzWSSFblvNkYGWaDR5s1lkVJDszEyyFKMNl8m +89a/L/PZv81PP17rPjvYOSvtU0iG0gRxuJidkjlK5BvQr5Lwu2j/leT6LP6uPo49O6i+iL07qr6 Kv6HtL8YFZI1ZPPLdYpdOixvrpBwu0RIKYI6XETetDUeSTHbey29LOmw3ZDNzjMdN9P3j7r+QLvA qPoH9el/toe24zCHVzpQ6YCDi4NLpQO2uba5Ys/ORdBKZwS13W7YGnhMF8v2xRnGkmdeygwJ9B0p 02im78xLTa9oOGCb/Y8Je1isvvI34iNZ8sLV9wqjJ6kGMirlSbMlH9ifYS6V1bIsTYb97Fek6XKS 9Ijg1zvNpMXyYVm8axFtLqX1aaAs4qwmr0hz6SxaA/ZrmEllFaE5Zh6umlnfbOU8eQH0bZG8GLzu Unkp+IAV8gpYq66WV0PPN8mbiAX0fBdRy7uh/5by9/IR8I/H5OPEWj4hnyAV5FPyKWIjn5ZPk4py iVwCOi/Jwie6cTfwiZ7ck1TiGq7Bmf8jD/PfbYtYuY9HOukd1j3zndQ96R3WPfkd1j3lHdY99R3W PRO9U4DwQ1LZ02pOKKsBPksid16ReeC64cwrsqqSiCILX5HZSuI+2rpXZFaSeLop9xWZTJ7B3jhz GawF75vFdU7GuO6mWVxnkN0gl83iOoPsIsZ/DV+RncY1kfcrsmMYR9ibZMKTC49DMA6RMA6RMQ6h EIecg2i4BKIRi1cQYrJY9ZlXrFfQL83kBr74pZWJGMc06+PN+EkvefMyxnOnmuk08GdfsR7RL2/i AdRBPBmIPXN+WQ56IcqtIYZ7oxKxIgyifivT/itX4fLdCeEKCbd69r+azFYKfzHOkPKlW3g/NRP6 TawyiWQ91pTF/usZ5dYjzHLOa/vTTLxk5WXKKIPzwy23v7tkFf8ua//n079tjfVXo8+LkgPafQtS HvAfCnYfBjniLTnauI19mdXpJNyi+J9P3PtfOfvP0j+5rv/nMAXxpUU5Uxb7r+dX5MqtN5RxeVlW OWLKZbJwJeV/OGUY8/9Y+q9jSjzv/MRsLSF+nVOXZjy/bJ7+xlVXRBgSolRcxwpfBJdd1+SxdBlQ vbIQ6UlBWSegalUwUhukp8BS7xuoAlGIVCTeKAAaJY4yb6BOorxUhGUWIi1hiUjFXdAipCVCm7SJ wrVHzhdUyjHwbByWGYc8nCXHsEKQ+BjlQs99o0TQHGNJAw+UlmMDsMwA1DlDUNVuPCraFqMSb5Vs RRrD7oC8QPQX+iJ6HaP4oCQTJVGoR7x5ojVQWoy8qFGr5CAVa84nQk6eiLYBFc/ixwmJFIetjcPa C1BSIOqVBmNfCvBoAY5GAY6eFvk47EuBsQzBs8T4h+JohGLtoaIkzRAl5VDDUdTvg/pzjDQYR4lg jUKzI9aYg3SwOJesw7oGo2ataAOMHvKC0mK0Aa2g0kLs+1akY7ENY5GPMUhwNGIMVM7HscW5w7Zp jRRnAduZI4ciXw7buVq0E89So7ZbL74SticsU9Y/nyJiPUHJtNI8pBkibi7dKUYbrbcQ+cLSYjwq aKKgUpgoL/kIKtuKktLKF2B15IpBYiwjaEnpNTE+Qo+0CWlR6QqUrEAexxY1PxEtkcpjGwpLQ5Av RirqysT2rCsV/cos3YBnbcCjIWI0sEcxWLLg+WnRd0HlsUi1gpInpW7iKLY2zlBjKY4w1hKHNeYg jUMNcVgyDKkP1p6IegqxlpXG8ckQfUT5FSyZYxgNQxnUFmY4iqPdD8+6gmeFIb2P418o+kUKsbW2 hvajhhw8+gRn54nQRpahTh8sqUZt4k96MRvpaqQXkR7G6Nqw4sF1xYt4QUvx7o6Ed11gPSXkTQ1x +IsHwCtYpjvK8X6NVIBHcaUDLRZ8LeRDBJVjUPI70h1IDeukOUinoYbByA9B2g/p5yhfiPx6pFeQ HkM6C+lKpEOxlq7IByDfT+mKiOiJfEegKUoqUiFPVdoDTVYABXIfJRZoGmItBcunKENQ/iHyEch3 RT5GUPZc+FjqjOiDeEuOVSlAFyKNpJFCG0sHmii8n5ym0gpe5Qo0SOUlePkRntsSaGeKtQuE0uZM 3LXfy7YjL7zZXmUUUvGM0F4VjLx8Af3kBaUJ0hyk4APljwWy5EyYJWE/wrsmIY2E8ZBoIMwSIEtQ miGo7PQ8Hy1nDcq9RJnne9EyRZkZgpcTLbaKNqtdka8jqLo18j8IzRYlov1iFSc3UcOVSB5icVfw lqJfQZafiZKWdYG2Ugur9kVJZ/VA0V8LT6Aai4pAZyFtwg6J8sp+wStUnKX8iiP5m5AzC6QeQCeh pBUT89WZxeD89sKSQkPac9HrzqViTBY8HwZ0zPMBQl4qaol8PlZQ1VG8sixDfxWC/ioPaQh6mNPo +e/gtYCU3UuQHJHeR5qDlh+M9vYE7TwPaUukgwQFLYJ3w5IpaJNapKF4Vtm9iARRC/Jeggd8OaBc /B50w1imMWg4XnodaNyLXVhmFfBfvHgoKIERfpH9QvzyFWBEs3g/b5SUTszfz2uJ7+dFm97Pc8F3 7CyI+MaNmlQgFYn48oeQiXjHglhCfGJDbAknzPTWnozr8lff23Mxe2NPgmjbsC1P7BIS0jJIFtJB SIcmpib3IGO6J6d3IROQTklOT84is5DmJvfplUoWI10BBbuQNUg3pfZKSCXbke5GeiCtW2IyOYL0 ZKbQeQYp+jN8A9BAZWg3wz2O1MKMWppRxYyWM6PUOJYEozWCkeBLamWk5WEEtMQXZuFNbxAazssw bvsZ3okD34cRoBRrfGOwn+ENQRqMbZLoXON2k2GrfmLYlouC8rCtcMv4BqG9Yb+il3F/sFgfQbk2 qD9LPH9HVBblLKwtyltUwN9pHgtrlVwlN3wLrwDOdiQexAda34SEkShoMcQCREVtxVOPyL1v4lqa uFYmLszEfYCcAjXak6rEDcbEB7X8hhru4tn38Mz7eNbveMYD8bUlsDJHGEUvClG5/IhWxrOq4lkO WL6KKC8ibFKOVkI99niu+AXuN6iVUAtqQSzwqUb8LhKhylBliIwWS3EiqRW1EtEVFd+0kaTZsMIL Jk1Ja5iveJICY/UZGUPyyAqygewkp8ll8cCcZC+5SN5SgNRQaiFF4O8YKu4NNc9ErrqJq1HGyYeA m4HcYRP3vYk7YuKOIife0Ybxko+JPXkXkXkb+RLw07DMcVPpYhN34pXzTuJ5BUDHy98BnYplfjAr 4yDvFvpghUOh5DT5lEnTjybutIn7ycSdMXFnTdw5E3fexJUgZwE+wRHnXOCgobwfapsD9e3HWufI +/ApxAOwNxf2D6B0rlwI0rnyBZOui8iJJ1UNv7XmyouhZL68gljJK+WVpIK8Wv6G2Mhr5XXEVt4g byb2xPBdMXvxDiY+2UhwvS+elJwPB5bLy0HnOihP5W2w1hO/2cryFFw7iqfgBCIsQAdDj+lpfP/d Gd98dwEdO4grrgUb41qwicGy6HXFnn4pLEtxUBzAfVZVqsKq3kkRd15lKZrkUxfqRr2oN/WhvjSA 1qXZdAQdRcfQsXQCzaFT6DQ6i86leXQxXUZX0JV0NV1DN9DNdDstoHvpAXqYHqMn6Wl6jl6kV+gN epPeonfoXVU7VQdWi/kxf1ab1WFBrB5rxN5jzVkr1o6Fsw7sQ/YR68K6sWSWxnqx3qwP68v6s4Hs E/YpG8KGseFsJBvNPmdfsPFsIvuSTWdfsXlsAVvCVrG1bCPbwnawXew7tocVskPsKDvBfmRn2QX2 M7vOfmW/sd/ZY/ZckRSmWCrWSkWlkuKquCueikbRKdWVmkotxU/xV+ooQUoDpZHSWOmkxCldlSTu yKtyJx7L43kiT+KpPINn8QF8MB/KR/BRfCyfwCfzaXwWn8vz+GK+jK/ka/gGvplv5wV8NxdvDOdT Z4i3CHWlEItQT+pJZKqjOpiNmrQmeJ9atBZh1J/6E4XWoXXAFwyjw4iaDqfDiSUdSUcSKzqajiac fk4/By8yno4n1nQinUjK0y9hNivQqXQqsaEz6UxSkc6hc4gtnU/nEzu6iC4i9nQpXUoq0eV0OXGg X9OvSWW6iq4ijvQb+g2pQtfT9aQq/ZZ+S6rRbXQbcaK76C7iTPfQPcSF7qf7iSs9RA8RN3qUHiXu 9AQ9QTzoj/RH4knP0rPg+S7QC0RDf6Y/Ey29Tq8THf2F/kK86a/0V1Kd3qa3SQ36G/2N1FRFqCKI jypKFUVqMR/mQ3wZJOLH9ExP9CyABRB/FsgCSQCry+qS2iyYBZNA1hAiyzqsCWtC6rJQFkqCWEvW kgSz1qw1qcciWASpz6JYFGnAYiCiashiWSxpxOJZPAlhiRCJNmZJLIk0YakslbzH0iG6bcoyWAZp xjJZJgllWSyLNGf9WD/Sgg2Alf/7bBAbRFqywWwwacU+Y5+RMDaUDSUfsGyWTVqzEWwECWej2CjS ho1hY0hbNpaNJRFsHKxs27EJbAKJZJPZZNKeTWPTSBSbxWaRDmwum0uiWR7LIx3ZYraYxLCVbCX5 kK1ha0gntoFtIJ3ZZraZxLLtEEN/xHaynSSOFbAC8jHbzXaTeLDrQtKFFbEi0pUdYUdIAitmxSSR nWKnSDd2hp0h3VkJKyE92GV2mSSxa+waSWY32U2Swu5ARNiT3Wf3SSp7xB6RNPaMPSPpiggdeikq RUUyFLWiJr3F/3kimYqNYkP6KPaKPRHvBrmQvoqb4kb6KR6KB+mveCleZICiVbRkoOKteJNBSg2l BvlE8YFofrDiq/iSTxW9oiefKYFKIBmi1FXqkqFKfaU+GaY0VBqSbCVECSHDlQ9hlTJC+Uj5iIxU uihdyCilh9KDjOaVeWUyhlfhVcjn3Jk7k7G8M+9MvuAf84/JOJ7AE8h43oP3IBN4T96TTOS9eC+S w/vwPmQS78/7k8n8E/4J+ZIP4UPIFD6cDydT+Ug+kkzjn/PPyXQ+no8nM/gkPonM5FP5VDKLz+Qz yVd8Dp9DZvP5fD6ZwxfxRWQuX8qXknn8a/41yeXf8G/IfL6eryd5/Fv+LVnAt/FtZCHfxXeRRfw7 /h1ZzPfwPWQJYP4M6Uk9qJbWoHoaSO/TcXQynUFn01y6kObTdXQT3Up30t20kBbRI7SYnqJnaAm9 TK+Bv7xJ76vaqzqyBqwxa8beZx+w9qwt68g6s49ZAuvBerJJbCqbyeaw+Wwp+4atZ9+ybaBDy/ax g+x7dpz9wH5i59kldpX9wm6ze+whe8pe0GsKpx6KnVJFCVBilXglkbvwON6Vd+cpPJ1n8n58EP+M j+HjeA6fwmfw2TyXL+T5fAVfzdfxTXwr38nFc/A90ZMR9GQSejIZfRhFH6ZCH8bQVynopSzQP6nR P1mif7JC/8TRP5VDP2SNfqg8+qEK6Ids0A9VRD9ki37IDv2QPfqhSuiHHNAPVUY/5Ih+qAr6oaro h6qhH3JC3+OMvscFfY8r+hU39Cvu6Fc80K94ol/xQr+iQb+iRb+iQ7/ijX6lOvqVGuhXaqJf8UHE 10LE+yLi/RDxekS8P2I9ALFeG7EeiFivg1iviygPQpQHI8rrIcrrI8obIMobIsobIcpDEOWNEeVN EOXvIcqbIsqbIcpDEeXNEeUtEOXvI8pbIr5bIb7DEN8fYAzQGpEajlhsg1hsi1iMQOS1Q+RFIvLa I/KiEHkdEHnRiLyOiLwYRN6HiLxOiLbOiLZYRNtHiLY4RNvHiLZ4RFsXRFtXRFsCoi0R0dYN0dYd 0dYD0ZaEaEtGhIn76DdJH+pONbQ69aO16T36BZ1Ep9Ov6Dy6gC6ha+lGuoXuoN/RffQg/Z4epz/Q n+h5eoleFVahiqT3VJGqaPoFq89CWFPWgoWxSNaGRbNOLI51Zd1ZCsthU9gMNpvlgtfOZ6vZOraJ bYVzjlMN28sOsMPsGDvJTrNz7CK7wm6wW+wue8CesFJ6ldVXrKi7Yqs4KgGsKXCdlY+VBHaMV+Mf 8S68G0/mabw378sH8k/5aP4Fn8i/5NP5V3weX8CX8OV8FV/LN/ItfAeH+BN6+v8LceKa74y4c0Hc uSLu3PCq7o7o80D0eSL6vBB9GkSfFtGnQ/R5I/qqI/pqIPpqIvp8EH21EH2+iD4/RJ8e0eeP6AtA 9NXG620gYrAOYrAuYjAIMRiMGKyH19v6iMQGiMSGiMRGiMQQRGJjRGITROJ7iMSmiMRmiMRQRGJz RGILROL7iMSWiMRWiMQwROIHiMTWeL0NRzy2QTy2RTxGIB7bIR4j8ZrZHq+ZUYjNDojNaMRmR7xO xiBCP0SEdkKEdkaExiJCP0KExiFCP0aExiNCuyBCuyJCExChiYjQbojQ7ojQHojQJERoMiI0BRHa ExGaighNQ4SmI0J7IUIzEKG9EaGZ+IR7OVgZx5tWpgdIMTlHrpG75Bms74zrZlID1j+w7qKwRoa1 xkOgI+hjoGPoU6ATlGFAXZRkIrNaSk+gfkoaUP83aHiAGh6hhieo4RlqyEYNKaghFTWkowZYtym9 RAnkMkxcbxOXaeL6mLgsE9fXxPUr48q1NnHhyMG6H7xOCSHgHW5DrXfZPaICL/GQKOApnhI1IHwn PvthSwy/1qnkq7DOWyHugsi5QMPwTSQtCcR7CDY8APAOGumNMk5xwHV8bdi7B2u0s1iuPB0C3gGO Gbb0Bt5NECsHgmsACc48j/dRwmAFaWO6j4L3KeSDuNIsMq3KL4snPJD72cRdKeOUQaL0H65cy+5D Gb/AVW0MbO1RSqoN1WdXG6xY1hjVctRDa8lCzs2ulgaiZFmS/LneUmE1y1O5KiP6LopVTUVSSdlB sqTKba9vp/cxkzjluQx1Ig0xtSVd8QOzqfhhvm4kRCS9u5kylX1eT4sfacQqt8idR09YZ7VO1/7a IjU32+F9fbbKVp8tP8mlsiTLFcgu8kXDhmMqHg15kHDzfBO9taml4gvY+gz/mvrqCu2g4nYezXpl DMwUH+10806o7uZfr16Qm+lDmfhJTl9/F72ToXClV48YP9bp7653FcepnePL45G9emW5vdc3K6lX ZnLWQL1LZet6QXp/f70+SA9/nSpbB+j9A2r7G3ffQYuyJQ/zYZEYodlSBQJyKzlbkshSeduujCsN 7rap5j1v+oA4/Y28peM1Hz8qndp6wcbSOXluIYPb5X2VNzE+oOfRpokDb63otz/q9N1fZo9ymjhv RPe1e3oO6up50rnhuQrS5GvTdu+o1X3WrCTtzCP1fXaUWx+j3dXiqlVI8DSfpd718m+2Gt700ogK W2alduiyInvw/Pha/Vtfn7kuscGsCCd/tZf9vKVXJ9V0vNJoRoJ9fAzrNs85KHL0wyW3p8h7qx3f 0aH52s+H7qh/M2pKm5XPlwxKy2qzyrFomqW3O+mYE58ctOUDW4uG0S86P13Y3Uq9+Niw6I63NzSI cxjWX3X6wfaVQ6eWrj405OSSqpmxDQ9svaNe4KFfq4zcv9atv93I8zIFw18wLF8/bJF+WB6MprOk GjZLP2z6UJvORzJuJ2fO9Wz3mf2a8AkvDs7P/O/PX/af2DgVczj1Gt85/t50xzq/bpK8TvWveC82 PmDeXH4whE0aM3F//Svud+90/NJnfe77hV1vP/uhqEGDTkvrRiWXeqU13l+07BwbfNZ/fKN5Nhkp W0pt2zom73x2pNmlip3c2t7o+smqZVUKawZpam3vNt92rKZCwoKHUU6P3fefrHQvckV6swCL59mV H/3cI9W63YNtv0Xu23Z1t/6Zm7/lGOep1auGn3CWF/02tISu63z/m7OFHW91a7UvMmrDOupt+yLn 5B31xM82Td+zPMjn8qDL+f0v9cslR1Ia7zpWd2zJe7b5dVKqpfxU50Kxk+pyfnNVYafawenhTtZd N1rljTt+Iqpxi0NOHRZn/GRbf/SXfectOZYLXiFen01bG7yCle/yimciXsTOObizzKc4vytnALgP DoA/8AAB4Az8A2C3TpkzGIgeFJQodnKH9v52+opiR21n1bFLn6Tk9B5ZUI2NvrwQWthZRHZLTOuV nljWMKu3NcxT725oWFXz44nd3Non90gXX8iNaPben3qFjQM/PfnR2ub18gNX+J9+rKnTqv/Op65z 9zXvfftoi2vF477r2Tqy6/2Z8nfhp1ql+nmFdNtx2HMjb7lxSN+zzbctm1g+Yo+m5t3cq9aerkff 83rSdeb3VZov+jLMdeahtX4e34XVGtzrx0ouDcbVs6l3dlv1+90b1JICXpTqWi5enyqNnv1085qE IdmPY3OHjRg5YfXdTVMWfB+8OGJkZd3oNmf1D0ij+3sfNxq2fdSvqfWW+AY+WOe7yurTrpMGdJ89 o4/1qFV3d99z+7at7fiEgz4/BjSvcmtL2LQGEe0dD3dvN3DZ16MLo0PmZUeMSWff1Nn1ide2yO6N ZrYpqvlZ7fQR7ytH5x4JGyWnjyILd44+397oFZ7ohz3U2wmnoFGV01sparigMWZB6f8PV1FBtNFO kl6omJ7CRu8sBOVVDir7IufD/UhG51W/nd7dZla7UN8FoQl39FwcrqAS/xl+lBl00Md8snzlZ2Ha u4e3tsnKi9Fl1ei7dtTz5a2nDCDh1w/84ngmeU/5vMH35GZ7D4wuetS+qGDetuhedxJCl4aSW9MK Z51w2sTnVbGe8sNpl6+rf3r718V9Vkw8V29CoxkpW4PTjo1Z5fn8/PWTyZaTxmwrvUC2BN57OPix ja0v+6X6tC+b9vTuvTF4YomF9f6Pkg5tG/pez+75WzZumRB44C61GTzo92MlTc9/UnrhworSB+dP WK/NODn5UtsNwXmDaxU3+imQdw2S5w1L8fz8QWzCxNWdttT7IX5chxFVa//eYEZudrm8j79Y67Nx /qKDy0+7bdihrzLSzd66xtbI+++VxOkvTfZOHr0r4+K9JcsPD22a2a88+JhB4GO6Gn1MF0U3DCMk tTmOGPiZd4hq4XCCwdMEBPgHBNapIxyOHsIP2K0tdvXDhv9H2maNhgOmqwpvGxFZVpy+pfif+p5t mes+v+o0b+S+rE3xsbRuo9nPZw6aVb2Fx+olo9v/eqtF/X2dGe+Yv/EAKzreuv/7GSPX/nzwfI+r C55n6b7sMe+HsTRUv/fh/s376zuro0PbVlZbP15XJWmZl9NT1nHk9T1tLNyDlvxy2MdvQ9ND7mzJ ySvHvTvuqzbocPW6Fofmdija8pvHL/meC62rFzw98l2nkIRG+3xa8U8Gjrwz5nbvbc06XVqw1vpe h6eakotux6/OipuyqHYt7yEdq3VIKRcQert7aq87wbNvy1/Pmn92hoVN+YaOyRcHtmlhX/LtuCN9 02avILNrNf293aZO9wc0H37dd3DNLR8dqtLF++spzaz2pDR9sT5g5cLqHuccrh03+p5H+mG/v9n3 vESx59E+NVpve/qz+5PeLjMrHa38ePfisTh9zhUE6gHIFkPRbzh7qhz1DkPfDPtQUcBV1UjfQF8v Nyi3zqjaSVlZGfX9/BIyU33TyubQN6FXml9Gz2Qh9TN+9b2PX7P2YHi+INK3LGshxCUN9fX1wWX7 enmUj1Fh//7936SwW6aZpqzXAIXep1n17xO2pV7qk/bdzB/Syo1psLdln0Gawz4Xgz6ZEzhvm+fh 7edPxQ6s2NOunZuU8G3mQ/WlvZ+2q+HgXXz06lc1vne0PmbXe1L1m9HbHp/cY+23qluttPDm1aMz R7RtfCzF+b2uSwfGTrizr//Yg7K375x9s2v+/G0Ny7M3p1/8edD4OJsx7eefjW/bf0bv+PzO9SYd X27ryq5/13zp8YJ2367adOaZMoLcz1rw04si51xPZnFZV6dgek6VZdnxumtPR9R0Oao6OOH7bOsf 8sObNel77NzZ/rfHxvasMDpx4rrNGzcv7xHl3nxZWNLVqLgv7GN7DLiZE0ttJqnneLlNv3aeVMxY +nhNZsbGlRcL5jnI4H3mgPcZafA+Nil8ZtudRLO84k/NXWMG9ch73Qe9m1inrr6ef129vz4wMEi4 nnqw+w5inajktG59srqkZfzVWOdMUPrTVYVNw3o7Fh5uGdJ+55Pl9pt9ArbYto0sHP5rSO0fW/lP 9t4wKbHENWLE5oIPjg5hj2733f7FvvwTK5Mzug/Qdb+2YePtkd8eurXsue1C/qFHdb/vm/wYrarW b31aYlpY1E9nfzu3Y97wfUPPD2ktB035fedcdbRL0vuHftzZL9bv0w0a1brozilOCS+GDm5464RK E16vf5bFRwWxp0YF+fTdX/6GSz3Lwf1K56SmDyq5GTJx+tze5T+u0daxa3zA3GPD29T0iE1q/sU5 vxE2Ef+3TT+3SvXmvFOdLfzjtMD1Vr4vTWXFZsemVi06k8D2hnVDm/H2H1OiWxxbIlqn5G2Q1/E4 kz/H+UHWi3q1vmxIedPEqAEMERVsJQ7H0GjtCLBxQscbRBlBTRgGpIIy/4Wf/fSdJqu92/r3zHm1 xtrR+dgFA0m4BhEmFh45LoZg8DUAzgyOqC0hjGYUlgJqiq+g4aGagN2CfQsT2Rn5egpce98Xh+y1 52TV/b8jMLhV5q3lxO2Lw7jv9Wyzlr74e83yk9s3BipK53Nk1mUzL1Jye5uzJbdGaYfb5ZbPvfz7 2LvMDr6ue1kQ6zp/0qUz5+72HXi4X+tszZuT64yutu88nXzE7KKE4v6ye9azNksXz1PsuLFli1BI z5c5h1K9ZmmozUno4rc+Lpxa4bH7/NpmK/8NSRH3DF6+tJR93PnplmXjT2HFnpSGZDaWaZ9mMTnr V7t17PrPdDP1p9e9W8wlkzez5vGcmXtHI7HG46P4HEFFCyaZ9jVsR6cZ7XjqcCzYdu/Kznsv0sx7 vyhNm3NmQ3lIoNW1IpdNyt+ABdQqYAE1Cd48mqILbh5xDlzzCKMgADePDMyNTIFFk5EhuIwyhnAN QVyDxs30aB6pG6hCuHJ5zpkFoAtFXIJdFVyD/azMHS2MdM0sLBx1Ld0sjQxVDZQhfpJB9ZNuMMhT CsGpRaALSAgWb1MbuRScJAKrbk59O/vvnfaLv/n6hV+tMtcQKvvnG7C6bLrWZPcHK8MymZ5OqfNt vV1f+L6U4fZu55zf+WsKP2hfrJl0bor43IVHd/38Xnc38aGugdwcNd0y+2du0/rW3eg0v3Hm/efz 0Yf/ZDz4lNI/+8VhoZ+L97X8udZ9jtV2L2NZgDrzj5btYm29CftiNXVszi/9OyPKVNZf7IDFDblE e1uzzWEiouVTrQV+MWyY/CjWfLX67mQdD5HG0Mc5r1ZqT+3t4KtbzLC0XIV9hlYB8w4tlQmz7h1d pOS93yeSrTykyHmDXcrdyS0cEdv+vWz35DTbvPmH8co6n0WV9UaRmnzztn59YDPP/o2bNXJzClEg aEzt2M9k/frWlF21bvy/Tn+pm/v/IkpLCWuJQUlLqaS4IDmRKi0lmEkl2AtrlPYf2wFspRXDuzV/ Hl3qSDul+Thq51mGpjrxmKMqkUK7V3zPvt7+r/f01jJ5aaVv3x+e2rLTkVHKfK2H+bSCX2eMl2v0 7ODeViKssX1z6UMtzkfd/vdn2E/fbiLU+ErgruydXSnn/QKsfbr+St5VXXd1Wvsr7yNPP/x0FI9l fB3eUVtW9TT/X7vCmslzembtj5daIGqg8mBRXeJEWU3Nw54TrJybO9/du9p811/H1Pq5oyPjKgYe 7k/XPKXPOfVWb/is2xur+XBfb/1E0bItCb9F1FflCyU7aURYdVl3OzzZfvTMpHAZt7Ds/tOTfMNY GU79MHBw9bsv2bH3q8CHu1L3NeS2BH4qf6D2eDdno9AdOasLroZNLMuBJdZiJkZGg8b2AeyyoXQk EQPgCxovGYjAaycNRkN2ZlbwgjRQnQWNTE5mQx7kMXegaxA8bkM+A2RZUWBZAtfIYgjMAEuO/9v2 vkR0zY0U5agHnRdzTDv1dhjEIGnhMfQz8Fmg1KBA6Fa5hWoNKjhTbUllQX56UWJBRqUCWinF0sTI IB/3d+9Lta1FE+qNjnxMnxWf+5ztxKlFAW2rD97QaNfeY//8kkGSiWqHi+7rjQLKZeWxD822SlxY ePrj6SJhRnfvtQZ7pqw89GjGnOYNFnbqyaxLreWlfgQubWL1rPww4ZDPKnkxA2f3dVZWD//ui9ly qKZh2zcN8VPybE2+mkub9/P6zt8eFDqDu2h36Lpl9SuXvjw977DW6xi5Tcorg18z1O+fFKbgfS3t RjhDunB/8DHbV8Kfe1q2TSndslXnoOn0z5ZVU488e+j3xq3O44y477ujR542Lmm97Pq/94KCJtd6 gWllayV529Uqr3Ov6zJUe3nM+cTtIGY2RcOLjKf+1btsFP/t5GlYbuw0ZWETk7xBE5M0Im7YDJuY eIBCHHRPmujVJUolzg5NmgtiDSSQUyA3YmqIEWgnXIbVkB9Y2VqC5j6A2MzEKAojAe6LfKAuHHRT /uR/tUk59WECM9y0stDKKlASmVp4LT1uTbxYSURp2moW8SM3CkI/GCsu2Jd/s+f8zFniE9Yddr8Y rnFTetv2fyrFz0NijxxzlNJ2PWVn3bg3vjJdhmHPrmrm6SwP7R/Hv9XKVPZlTTXYrLrQq47v5q2d JnzJR3773zz322FeSI/KwQh9i++PNmQ6yh6Oabn6qn9zzXMetSKGuoXBCra1UnP+XZIP9cmeVitd 53ZhYl+qutb1hxIFfI8P39+iGaR3LTBWooVlw7eLP/x5zlZd/JC6Y4/StMUmZ79Z7P/1Rff6xX2d R5nt3E8eLChcP+XP6us75+6YJ7E758akQzU+iVtmPj5xWE1Csdy964n7cfHkw5VrkifteclScSbp 1ZzqLwARxZDsDQplbmRzdHJlYW0NCmVuZG9iag0KNDcgMCBvYmoNCjw8L1R5cGUvWFJlZi9TaXpl IDQ3L1dbIDEgNCAyXSAvUm9vdCAxIDAgUi9JbmZvIDE4IDAgUi9JRFs8MEEyQzAwNjAzREM4Mjk0 N0FCRUM1RTFEMkFFREI5MjU+PDBBMkMwMDYwM0RDODI5NDdBQkVDNUUxRDJBRURCOTI1Pl0gL0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTQ5Pj4NCnN0cmVhbQ0KeJwtzrkNAjEUhOHn5T725BBn AXRAA7RAQkxICUhExHRBSES8m1EQGQSLmd8O/Gn0NPYz86eunb9zsz9neAr3EnElkpNIDyKLha8J CsVDjLawh68Y78Qk8BHTt1nkn5hZBjmkEGaFUwjJQQQNaEIL2tCBLvSgDwMYQgyJ/2h+0WaLu1he xeoo1jdRkkpStTH7AV40FU8NCmVuZHN0cmVhbQ0KZW5kb2JqDQp4cmVmDQowIDQ4DQowMDAwMDAw MDE5IDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAgbg0KMDAwMDAwMDEyNSAwMDAwMCBuDQowMDAw MDAwMTgxIDAwMDAwIG4NCjAwMDAwMDA0NTUgMDAwMDAgbg0KMDAwMDAwMzUyMCAwMDAwMCBuDQow MDAwMDAzNjkzIDAwMDAwIG4NCjAwMDAwMDM5MzEgMDAwMDAgbg0KMDAwMDAwNDEwOSAwMDAwMCBu DQowMDAwMDA0MzUyIDAwMDAwIG4NCjAwMDAwMDQ1MzMgMDAwMDAgbg0KMDAwMDAwNDc4MyAwMDAw MCBuDQowMDAwMDA0OTIwIDAwMDAwIG4NCjAwMDAwMDQ5NTAgMDAwMDAgbg0KMDAwMDAwNTExNSAw MDAwMCBuDQowMDAwMDA1MTg5IDAwMDAwIG4NCjAwMDAwMDU0NDUgMDAwMDAgbg0KMDAwMDAwNTYy NiAwMDAwMCBuDQowMDAwMDA1ODc1IDAwMDAwIG4NCjAwMDAwMDAwMjAgNjU1MzUgZg0KMDAwMDAw MDAyMSA2NTUzNSBmDQowMDAwMDAwMDIyIDY1NTM1IGYNCjAwMDAwMDAwMjMgNjU1MzUgZg0KMDAw MDAwMDAyNCA2NTUzNSBmDQowMDAwMDAwMDI1IDY1NTM1IGYNCjAwMDAwMDAwMjYgNjU1MzUgZg0K MDAwMDAwMDAyNyA2NTUzNSBmDQowMDAwMDAwMDI4IDY1NTM1IGYNCjAwMDAwMDAwMjkgNjU1MzUg Zg0KMDAwMDAwMDAzMCA2NTUzNSBmDQowMDAwMDAwMDMxIDY1NTM1IGYNCjAwMDAwMDAwMzIgNjU1 MzUgZg0KMDAwMDAwMDAzMyA2NTUzNSBmDQowMDAwMDAwMDM0IDY1NTM1IGYNCjAwMDAwMDAwMzUg NjU1MzUgZg0KMDAwMDAwMDAzNiA2NTUzNSBmDQowMDAwMDAwMDM3IDY1NTM1IGYNCjAwMDAwMDAw MzggNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDA2NTI4IDAwMDAwIG4NCjAwMDAw MDY4MjMgMDAwMDAgbg0KMDAwMDAwNzA0NiAwMDAwMCBuDQowMDAwMDA3MjY5IDAwMDAwIG4NCjAw MDAwMDc1NjggMDAwMDAgbg0KMDAwMDA0ODk5NyAwMDAwMCBuDQowMDAwMDQ5MDQwIDAwMDAwIG4N CjAwMDAwNDkxOTMgMDAwMDAgbg0KMDAwMDA4MDExNSAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXpl IDQ4L1Jvb3QgMSAwIFIvSW5mbyAxOCAwIFIvSURbPDBBMkMwMDYwM0RDODI5NDdBQkVDNUUxRDJB RURCOTI1PjwwQTJDMDA2MDNEQzgyOTQ3QUJFQzVFMUQyQUVEQjkyNT5dID4+DQpzdGFydHhyZWYN CjgwNDY1DQolJUVPRg0KeHJlZg0KMCAwDQp0cmFpbGVyDQo8PC9TaXplIDQ4L1Jvb3QgMSAwIFIv SW5mbyAxOCAwIFIvSURbPDBBMkMwMDYwM0RDODI5NDdBQkVDNUUxRDJBRURCOTI1PjwwQTJDMDA2 MDNEQzgyOTQ3QUJFQzVFMUQyQUVEQjkyNT5dIC9QcmV2IDgwNDY1L1hSZWZTdG0gODAxMTU+Pg0K c3RhcnR4cmVmDQo4MTU4Mg0KJSVFT0Y= ------=_NextPart_000_005D_01CC4256.22579E90-- From mrex@sap.com Thu Jul 14 10:14:36 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C4A21F8D71 for ; Thu, 14 Jul 2011 10:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.586 X-Spam-Level: X-Spam-Status: No, score=-9.586 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_19=0.6, 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 jqkeZ9S6StaT for ; Thu, 14 Jul 2011 10:14:35 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0B121F8D3F for ; Thu, 14 Jul 2011 10:14:34 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6EHEMsc019534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2011 19:14:22 +0200 (MEST) From: Martin Rex Message-Id: <201107141714.p6EHELl7025964@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 14 Jul 2011 19:14:21 +0200 (MEST) In-Reply-To: <166DABD0-6CBD-465B-A75B-F3F853CA6A08@vpnc.org> from "Paul Hoffman" at Jul 14, 11 08:12:58 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 17:14:36 -0000 Paul Hoffman wrote: > > On Jul 14, 2011, at 5:20 AM, Erik Andersen wrote: > > > > At least there seems to be agreement on what a certification path is and > > what is forward and what is reverse. That is propress. > > You sound like an optimist. Note the definition that was posted: > Certification Path: An ordered list of certificates starting with a > certificate signed by a trust anchor and ending with the target > certificate. > > In fact, many people assume that the certification path includes the > trust anchor. Thus, Peter's skepticism is warranted, even in this case. But including the trust anchor in the certification path is extremely reasonable, and it is the X.something specs that are seriously flawed in this detail. (actually, only X509PKIPathv1 suffers from this brain damage, there are no restrictions in PKCS#7 precluding the presence of a trust anchor certificate in this unsorted bag of certificates). Personally, I find it extremely reasonable and useful that Microsoft's Certificate Export Wizard will include the trust anchor certificate when you ask it to export a certificate as PKCS#7 and checkmark the option "Include all certificates in the certification path if possible" In contrast to that, PKCS#7 chains available from some commercial CAs are often usability-impaired, because they lack the trust anchor certificate. -Martin From paul.hoffman@vpnc.org Thu Jul 14 10:49:01 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B0321F8CDA for ; Thu, 14 Jul 2011 10:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAtIn2gHxCIa for ; Thu, 14 Jul 2011 10:49:01 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 22F9F21F8CB8 for ; Thu, 14 Jul 2011 10:49:00 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6EHmoqk086253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Jul 2011 10:48:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201107141714.p6EHELl7025964@fs4113.wdf.sap.corp> Date: Thu, 14 Jul 2011 10:48:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0944878F-A45B-435D-967A-5804356283C1@vpnc.org> References: <201107141714.p6EHELl7025964@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] Certification path 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, 14 Jul 2011 17:49:01 -0000 On Jul 14, 2011, at 10:14 AM, Martin Rex wrote: > But including the trust anchor in the certification path is extremely > reasonable, and it is the X.something specs that are seriously flawed > in this detail. What if the trust anchor is not a certificate? (Cue the TAMP music....) If you want a certification path to only include certificates, you = cannot say that it must include the trust anchor.=20 If you want to allow a certification path to optionally include a trust = anchor certificate, you probably need some magic marking to say that the = initial certificate is a trust anchor, not something that is chained to = a trust anchor. The current definition is simpler than either of those, at the cost of = not including any definitive indication of the trust anchor. (And before = anyone says "the trust anchor is obviously the thing that signed the = first certificate!", that's not always true. It could also be a policy = that has nothing to do the actual signer, for example "the entity that = has at various times been represented by these four different signing = keys".) --Paul Hoffman From mrex@sap.com Thu Jul 14 12:08:06 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584A311E807E for ; Thu, 14 Jul 2011 12:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.587 X-Spam-Level: X-Spam-Status: No, score=-9.587 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_19=0.6, 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 DgzJOFcZJF3k for ; Thu, 14 Jul 2011 12:08:05 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8319621F8604 for ; Thu, 14 Jul 2011 12:08:05 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6EJ7wAq024671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2011 21:08:03 +0200 (MEST) From: Martin Rex Message-Id: <201107141907.p6EJ7vOV002530@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 14 Jul 2011 21:07:57 +0200 (MEST) In-Reply-To: <0944878F-A45B-435D-967A-5804356283C1@vpnc.org> from "Paul Hoffman" at Jul 14, 11 10:48:59 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 19:08:06 -0000 Paul Hoffman wrote: > > On Jul 14, 2011, at 10:14 AM, Martin Rex wrote: > > But including the trust anchor in the certification path is extremely > > reasonable, and it is the X.something specs that are seriously flawed > > in this detail. > > What if the trust anchor is not a certificate? (Cue the TAMP music....) > > If you want a certification path to only include certificates, > you cannot say that it must include the trust anchor. In theory, you are quite right. There exists a whole lot of wild fantasy about non-X.509 TrustAnchors (and their management) that creates a shitload of needless complexity. But there seems to (quite reasonably) exist PKI software, where you must supply all trust anchors as X.509 certs, and the most common occurance of TAs are self-signed X.509 certs. As in "In god we trust, all others must submit an X.509 certificate." > > If you want to allow a certification path to optionally include a trust > anchor certificate, you probably need some magic marking to say that the > initial certificate is a trust anchor, not something that is chained > to a trust anchor. Nope, that is irrelevant. "Trust Anchor" status is a purely individual perception. A receipient of a multi-certificate certification path may have declared an arbitrary certificate from that path as trust anchor, so reasonably dealing with the situation is always unavoidable. Certifications paths should always be composed to end (looking forward) with a self-signed certificate (or start with a self-signed certificate if using formats like X509PKIPathv1). Making assumptions about whether and which of the certificates in the path are a trust anchor for the RP, is IMHO inappropriate. > > The current definition is simpler than either of those, at the cost > of not including any definitive indication of the trust anchor. Things would be simple if TrustAnchors had been defined as "X.509 certificate PLUS something", so that adding a TA cert (or prepending it for the Bigendian X509PKIPathv1) to a certification path would be easy and straightforward. -Martin From paul.hoffman@vpnc.org Thu Jul 14 12:15:00 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0AC21F8C15 for ; Thu, 14 Jul 2011 12:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.364 X-Spam-Level: X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af14Uj5lHjMj for ; Thu, 14 Jul 2011 12:15:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2C94E21F8C10 for ; Thu, 14 Jul 2011 12:15:00 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6EJEl7i089878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Jul 2011 12:14:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201107141907.p6EJ7vOV002530@fs4113.wdf.sap.corp> Date: Thu, 14 Jul 2011 12:14:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <50ED5A3C-A67C-45DA-BAEC-7358433C8627@vpnc.org> References: <201107141907.p6EJ7vOV002530@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] Certification path 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, 14 Jul 2011 19:15:01 -0000 On Jul 14, 2011, at 12:07 PM, Martin Rex wrote: > Paul Hoffman wrote: >>=20 >> On Jul 14, 2011, at 10:14 AM, Martin Rex wrote: >>> But including the trust anchor in the certification path is = extremely >>> reasonable, and it is the X.something specs that are seriously = flawed >>> in this detail. >>=20 >> What if the trust anchor is not a certificate? (Cue the TAMP = music....) >>=20 >> If you want a certification path to only include certificates, >> you cannot say that it must include the trust anchor.=20 >=20 > In theory, you are quite right. >=20 > There exists a whole lot of wild fantasy about non-X.509 TrustAnchors > (and their management) that creates a shitload of needless complexity. There are plenty of deployed examples of it as well. > But there seems to (quite reasonably) exist PKI software, where you > must supply all trust anchors as X.509 certs, and the most common > occurance of TAs are self-signed X.509 certs. If you want to define certification paths as only existing for paths = where the trust anchor is a certificate, that certainly works for the = common case. The definition we have today does not have that restriction A new definition might add such a restriction. Such a new definition = might then also create a second definition for something like = "non-originated certification path" that could accommodate folks who use = non-certificate TAs. --Paul Hoffman From denis.pinkas@bull.net Fri Jul 15 02:41:02 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDE121F85CA for ; Fri, 15 Jul 2011 02:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMaXuaVilIKv for ; Fri, 15 Jul 2011 02:40:58 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7F46F21F859E for ; Fri, 15 Jul 2011 02:40:57 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id F23B23182BB; Fri, 15 Jul 2011 11:50:39 +0200 (CEST) In-Reply-To: <005c01cc4245$5ecece90$1c6c6bb0$@eu> References: <005c01cc4245$5ecece90$1c6c6bb0$@eu> To: "Erik Andersen" MIME-Version: 1.0 X-KeepSent: ADA01F13:F5EF2B9B-C12578CE:00349D35; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Fri, 15 Jul 2011 11:40:55 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 15/07/2011 11:40:55 Content-Type: multipart/mixed; boundary="=_mixed 00350F76C12578CE_=" Cc: PKIX Subject: Re: [pkix] Trust anchors 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, 15 Jul 2011 09:41:02 -0000 --=_mixed 00350F76C12578CE_= Content-Type: multipart/alternative; boundary="=_alternative 00350F76C12578CE_=" --=_alternative 00350F76C12578CE_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Erik, You are walking on a field of mines. Nevertheless, it is good to have a=20 ball rolling. Since, I don't like the proposal, I will explain shortly why and will=20 attach a counter proposal. The first sentence is meaningless for me: "A trust anchor is an entity=20 that is trusted by=20 a certificate-using system supporting a relying party".=20 The second sentence introduces the concept of "trust anchor store".=20 This concept originally introduced in the PKIX WG is too restrictive. I do know that several vendors have adopted a model where all CA are=20 equally trusted,=20 but this is far too restrictive and this should not be the general rule. Trust anchors may be grouped under a set of rules usually called a=20 "validation policy" or a "signature policy".=20 In a given set of rules there are trust anchors and, for each trust=20 anchor, conditions that shall apply to every certificate of a to-be-tested = certification path that ends to that trust anchor, like OIDs for=20 certification policies, key usages, etc ... Trust anchors cannot be be simply grouped in "trust anchor stores", since = different constraints may apply to every trust anchor. This is the reason why I have deleted the text related to the"trust anchor = store". Denis De : "Erik Andersen" A : "PKIX" Date : 14/07/2011 18:46 Objet : [pkix] Trust anchors Envoy=E9 par : pkix-bounces@ietf.org To prove I am an optimist, I have produced a first draft for a subclause=20 on trust anchors to be included in X.509. =20 I will appreciate any constructive comment.=20 =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik [pi=E8ce jointe "trust-anchor.pdf" supprim=E9e par Denis PINKAS/FR/BULL]=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 00350F76C12578CE_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Erik,

You are walking on a field of mines. Nevertheless, it is good to have a ball rolling.

Since, I don't like the proposal, I will explain shortly why and will attach a counter proposal.

The first sentence is meaningless for me: "A trust anchor is an entity that is trusted by
a certificate-using system supporting a relying party".

The second sentence introduces the c= oncept of "trust anchor store".
This concept originally introduced in the PKIX WG is too restrictive.

I do know that several vendors have adopted a model where all CA are equally trusted,
but this is far too restrictive and this should not be the general rule.

Trust anchors may be grouped under a set of rules usually called a "validation policy" or a "sign= ature policy".
In a given set of rules there are trust anchors and, for each trust anchor, conditions that shall apply to every certificate of a to-be-tested
certification path that ends to that trust anchor, like OIDs for certificat= ion policies, key usages, etc ...

Trust anchors cannot be  be sim= ply grouped in "trust anchor stores", since different constraints may apply to every trust anchor.

This is the reason why I have deleted the text related to the"trust anchor store".

Denis






De :     &= nbsp;  "Erik Andersen" <era@x500.eu>
A :     &n= bsp;  "PKIX" <pkix@i= etf.org>
Date :    =    14/07/2011 18:46
Objet :        [pkix] Trust anchors
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



To prove I am an optimist, I have produ= ced a first draft for a subclause on trust anchors to be included in X.509.
 
I will appreciate any constructive comm= ent.  
 
Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: = era@x500.eu
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/
http://dk.linkedin.com/in/andersenerik
 [pi=E8ce jointe "trust-ancho= r.pdf" supprim=E9e par Denis PINKAS/FR/BULL] =5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 00350F76C12578CE_=-- --=_mixed 00350F76C12578CE_= Content-Type: application/octet-stream; name="7.5 Trust anchors.pdf" Content-Disposition: attachment; filename="7.5 Trust anchors.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nNVaTZMbNRC9+1f4hk3FQl8jjeAUUoGC4kLKVRwSDl6vNw6w65DdBZYfwu9F mpHULanHdpaFKkhRpZ2RWl/9Xr/u8a9zzoSc8/AvNbbXMz7/2v//dvbrrGcq/De8wO3t9fzL9eyz V3YuBON6vr6aceac03w0IuaWs35ujZivr2evF3YpmJJc6QVbrjSz1nZq0eWH86Vh3PUdbq2Xq545 1Vm5+BDGiK4X/eI+j7ldCs46a+ziDkzOobkZegouFjdLIZlwViy2yxVn0vXe5j6/PuQWmidat2DS Ot/8cf3tzBuzcr7+bub//iT8ZcIf609fL54vFesM530YpCzTvLNpTqd6vdjl1X/w+7TC9j1e/bul 6JjqtFtcLVe+aTpl/EPNtO8oCkubbKkYP3QVHdoTbD6tyejF+/waTina6YULZ9OOAePF2Yyvg512 yDZ33BMTgsGb/AwNPmSLV7Ay/14a1imuFtfhqe6Miz4Rhv8ymHQ6+4TpbZwnPBy2LZzpUcddfpbv LJ604pzrPnQI6/A3idyjMD9cWtflS5POPwyeIqV/YzuPh/WlBwG2uslW7waPdxKt5BZ1fJZeTyzv kEfFA+mlChtt1wzngO3D05ts6S11JrDipz2oNH30bqucKk4njydv6pB7XkHP6CXePBq+z8N31E7A OpzD5dhRgV/auAwplUrQ6jMGXSfjhkwv8cOHEQjD0qS1nin74B+r5CCryCnBS24RygH7b5crx/zZ WRXREqAPdHKJqDTTwUV++JC5Er0uOCK2dhjGCXQv/CqEvyM1ElzntPRuiTGZmhvC5CVl8s/MDHCc yGsOmBDSGCAE1HOMF+FkgQ9IQi8uPfnEBl9103p3nE0OhMdsCIZB850LFy1FopDOx1GVGGQaOASt EMDBwEfLmgJRalYOYLiF8Iv70bwSXdcohw5qV4OsvJiL/PCBmAdOfgrfsVU4ynnbYYDaeWqqGPlX 8TZWY9C/DApg/dMQ+n/wlKOYsyl2Gp0u2LduMDqlV0xaKhTBw0PuZ9e2ctgiqoVA+ZBhQwXPxBHc wDx0rG/UR8DXAw7raXRBDRGoO4zt2LoFZYVG31HoRe9/q2igwiz4EHJ87BDjsZlTbpBnlGlGQyI1 HqqRBQmsDFPOdEUwKRYRTR9GwBrOtDIEYlHXDaYO8P7kGhOxqN5N1bEFPklg1NIrXsroqbyktPlP yQgrm7QQcsXoojHD7EvWHVzzlxx9oZWHg6zuDIrTheqXfh2dTqrM96wjdrxeHLEhSkMYhtAM4G+V ei+w0i+itNCGCWPwoD22DmAae1oMQXiPEIi6Tmnr9L5JuEoa2iHYI84QqvPziwaN04lGnrJv0wtT rAiGvy9bJIQJT4w9L06lANW5l+Emb3KKcQYGUI45nmM2sknrdsA4CZM/El5LRCSbU7E7vb8ng3+h hs41Re6ZBDmc0xSzPDZBmKKWoJjIe9xU52y5TJKj19gBkVzfV6GuFPsVIcTbzprgNZ2boyYIg6hZ bRdz0zgIiiHequ8gCksHLBwS5i4yKgCwACmALkRsNLhI3tPDLUUn7cUFGKe6hcwXpxV6WGV2LQ1M 1C3ahRZapmW4fTtGIsTvKFf9PSyTB6fb4Y4NNk9AfwIGAx/o3rttn/jgSKLZYeT809he3OO5sf1j AEiSVrMNOJgJLZPWSRFiiegIhUmaoq8n4RghfjBkMOKbgBcG3easfVINxKvFagDQD5EfV+4gigOQ 8/SqSP9Rsn6fOQOFeQATwJ+K0qiEeU8ADDgBq/DkHygDJ6EGOC9zgNSzlCUZ/CltJxP8UpWk5jmq JEa6Mpkba7cVLMfqbQ/VW1RwbpSWKS4D0TYIObhteIY63ufNQaECihd3J3YJOos8OaruUta649wH qtqCDBVpJVxG4nSyBAP7IUm5IveWVqnqQaXtK8FG1lYonv+8KWegMn7PuBiw22fs/oVDq3X+hRJl op5c4KZCMZw993nGqqk7Fff+HuGATr/Tw0sEM9DH+WLJY4abQwUBShXcFh7SVAAva/4I04B/wcWg wjNZZTtVXjpdpIWeMWWsQVLC/o6cplaCobUtfS7OmDJ5H0+US3EbTfkFylxLp1qlQauRWSadaiqt Kz0tnDg4C9whRfdwr1vMw4ktfvYoFkxYjStLpM9tEOtkQ6h5oCgGZidJ4IhXlSIM7NR6vKaL0zWf 9Jqq6GKyIVUViC5Uv7w/YYlaCNZ2Y0VXMmlFcquqdjxwcwmo+Lpyup5rDWXJ0eRJKjvf6zbIw1J8 R3RCltibuyu/JV77DWjhhKEDDqVCgG1OZxut7CE1DMThRpiEoydJD0ILVY1+OvrCLlkyzJn8FZ9C oP0QMxDLtOmhIhGN51kOFGxuUdo2Vc1v9/jUXwQ//sPGMaDEg/gfszNdzs+nuyHkBlkNpGCCbxxN +WaBMY7AV2n0QNXgpO+J1lPV6d4szwnGkQ1HdX+mtPODf8tl2M3Ri6S02R0w0onbO/LBoyyEwDRf kFnRWd9ci0MxZ54JaFxyL7BEMi8kN4iGbylFcUOxM6Q8paM3pw8CHK0IUifWnB8SbjgdQN/2Ch86 P0OEGt7Eb5cgyS/KfWn86YSOtT9eIqLdE+dzIJGOFOvS3IWdY5R2gX2mjShAH/UvBIaH+YseUAoI vkKGtSGO+vFLjo5VvB3kwUOUcH6YkqjCnwyiOHaggh9SdmREe0bEfRzbQC3QmQspF3Je1KTDRWxU Xp5JcTI2kukwdmj84bpWairkxlW4KdMHJDLrb8+TzEb9QAW9fnSM9lpVofX+TFWySI/+9756HCu6 PjtS7fiIEDhR3QB+oYANp4iOobmXviCIJ7yXM8XT9vjvDY4mGU/xmfvRobgILbkZKcYYXHC6qFBT 1aMK0BGZXQ26MJxMiv4dVEVwT6Oqxt9/D6qypNWKm8cKUGmHjwqfvXJzx5zJv6lWvYm/qRbChB9b a66D44TfVXtFIoPydsNBpOY9NG+heQfN59C8geYWmntoHsgpviEtXOFhhvNxP9M/Epe83tBEHQq8 IUnBolzQKptKFJ4jBo5n+d9A8+VShPjvOyZByLvFV36004IXoftVJkB4/SLXulDHLs/tsmeJ/Ezn FqtdbPjqpYawrZgE3fpyPfve//sbPArqtGVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagoyMzUxCmVu ZG9iago0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUg MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgMTAg MCBSCj4+Ci9Db250ZW50cyA1IDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMg L0tpZHMgWwo0IDAgUgpdIC9Db3VudCAxCi9Sb3RhdGUgMD4+CmVuZG9iagoxIDAgb2JqCjw8L1R5 cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSCj4+CmVuZG9iagoxMCAwIG9iago8PC9SOAo4IDAgUi9S Nwo3IDAgUi9SOQo5IDAgUj4+CmVuZG9iago4IDAgb2JqCjw8L0Jhc2VGb250L0NvdXJpZXIvVHlw ZS9Gb250Ci9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjcgMCBvYmoKPDwvQmFzZUZvbnQvSGVsdmV0 aWNhL1R5cGUvRm9udAovRW5jb2RpbmcgMTEgMCBSL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTEg MCBvYmoKPDwvVHlwZS9FbmNvZGluZy9EaWZmZXJlbmNlc1sKMTUwL2VuZGFzaF0+PgplbmRvYmoK OSAwIG9iago8PC9CYXNlRm9udC9Db3VyaWVyLUJvbGQvVHlwZS9Gb250Ci9TdWJ0eXBlL1R5cGUx Pj4KZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVjZXIoQUZQTCBHaG9zdHNjcmlwdCA4LjUzKQovQ3Jl YXRpb25EYXRlKEQ6MjAxMTA3MTUxMTE4MTkpCi9Nb2REYXRlKEQ6MjAxMTA3MTUxMTE4MTkpCi9U aXRsZShcMzc2XDM3N1wwMDA3XDAwMC5cMDAwNVwwMDAgXDAwMCBcMDAwVFwwMDByXDAwMHVcMDAw c1wwMDB0XDAwMCBcMDAwYVwwMDBuXDAwMGNcMDAwaFwwMDBvXDAwMHJcMDAwcykKL0NyZWF0b3Io XDM3NlwzNzdcMDAwUFwwMDBEXDAwMEZcMDAwQ1wwMDByXDAwMGVcMDAwYVwwMDB0XDAwMG9cMDAw clwwMDAgXDAwMFZcMDAwZVwwMDByXDAwMHNcMDAwaVwwMDBvXDAwMG5cMDAwIFwwMDAwXDAwMC5c MDAwOVwwMDAuXDAwMDEpCi9BdXRob3IoUElOS0FTKT4+ZW5kb2JqCnhyZWYKMCAxMgowMDAwMDAw MDAwIDY1NTM1IGYgCjAwMDAwMDI2NjYgMDAwMDAgbiAKMDAwMDAwMzAzMSAwMDAwMCBuIAowMDAw MDAyNTk4IDAwMDAwIG4gCjAwMDAwMDI0NTYgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAow MDAwMDAyNDM2IDAwMDAwIG4gCjAwMDAwMDI4MjQgMDAwMDAgbiAKMDAwMDAwMjc2MiAwMDAwMCBu IAowMDAwMDAyOTY0IDAwMDAwIG4gCjAwMDAwMDI3MTQgMDAwMDAgbiAKMDAwMDAwMjkwNCAwMDAw MCBuIAp0cmFpbGVyCjw8IC9TaXplIDEyIC9Sb290IDEgMCBSIC9JbmZvIDIgMCBSCi9JRCBbPDhF N0VEODRFMzc1OTc1NkJFQThBNTQxOTRBQ0RBRjYzPjw4RTdFRDg0RTM3NTk3NTZCRUE4QTU0MTk0 QUNEQUY2Mz5dCj4+CnN0YXJ0eHJlZgozNDAzCiUlRU9GCg== --=_mixed 00350F76C12578CE_=-- From era@x500.eu Fri Jul 15 03:16:40 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB54721F8666 for ; Fri, 15 Jul 2011 03:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 kpg2TcMjmQC6 for ; Fri, 15 Jul 2011 03:16:36 -0700 (PDT) Received: from mail01.dandomain.dk (mail01.dandomain.dk [194.150.112.201]) by ietfa.amsl.com (Postfix) with ESMTP id BD4BD21F8669 for ; Fri, 15 Jul 2011 03:16:35 -0700 (PDT) Received: from Morten ([95.209.241.49]) by mail01.dandomain.dk (DanDomain Mailserver) with ASMTP id YRF35327; Fri, 15 Jul 2011 12:16:27 +0200 From: "Erik Andersen" To: "'Paul Hoffman'" References: <004b01cc421c$14f94620$3eebd260$@eu> <005501cc4220$76382740$62a875c0$@eu> <166DABD0-6CBD-465B-A75B-F3F853CA6A08@vpnc.org> In-Reply-To: <166DABD0-6CBD-465B-A75B-F3F853CA6A08@vpnc.org> Date: Fri, 15 Jul 2011 12:16:27 +0200 Message-ID: <007101cc42d8$45417a70$cfc46f50$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxCOIjx9nIcv4EeTeqB+7ggJrR1CAAn3sNA Content-Language: da Cc: pkix@ietf.org Subject: Re: [pkix] Certification path 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, 15 Jul 2011 10:16:40 -0000 Not including the trust anchor in the certification path implies that trust anchor information, e.g., validity, is not checked. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sendt: 14. juli 2011 17:13 Til: Erik Andersen Cc: pkix@ietf.org Emne: Re: [pkix] Certification path On Jul 14, 2011, at 5:20 AM, Erik Andersen wrote: > At least there seems to be agreement on what a certification path is and > what is forward and what is reverse. That is propress. You sound like an optimist. Note the definition that was posted: Certification Path: An ordered list of certificates starting with a certificate signed by a trust anchor and ending with the target certificate. In fact, many people assume that the certification path includes the trust anchor. Thus, Peter's skepticism is warranted, even in this case. --Paul Hoffman From era@x500.eu Fri Jul 15 06:22:13 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2400821F8726 for ; Fri, 15 Jul 2011 06:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XanXU+Kcxnt for ; Fri, 15 Jul 2011 06:22:08 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id CD9A421F8747 for ; Fri, 15 Jul 2011 06:22:07 -0700 (PDT) Received: from Morten ([95.209.241.49]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id YUL70005; Fri, 15 Jul 2011 15:22:05 +0200 From: "Erik Andersen" To: References: <005c01cc4245$5ecece90$1c6c6bb0$@eu> In-Reply-To: Date: Fri, 15 Jul 2011 15:22:05 +0200 Message-ID: <009001cc42f2$3479d420$9d6d7c60$@eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0091_01CC4302.F802A420" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxC001XtyFsnq9sT1SgUquOMoiRNQAGog8w Content-Language: da Cc: 'PKIX' , SG17-Q11 , Directory list Subject: Re: [pkix] Trust anchors 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, 15 Jul 2011 13:22:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0091_01CC4302.F802A420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Denis, =20 Thanks for your comments. I understand that you believe that trust = anchor storage shall not be mentioned in X.509 at all. =20 X.509 is not that well structured, as it has been written by different people at different times during a period where concepts and terms were being developed. =20 As an example, the term trust anchor is used with any previous = introduction. An innocent reader does not necessarily know what a trust anchor is. Following your proposal, the term trust anchor would still be used = without any introduction. =20 The proposed subclause is intended to be just before a subclause = introducing the concept of certification path. Some of your proposed text fits = nicely in here. =20 It was important to me to emphasise that a trust anchor is some trusted entity by a relying party and not necessarily trusted by the end-entity. = =20 New player from new countries are coming into the PKI area. X.509 should = be written in such a way that it is understandable for newcomers. Many PKI specifications can only be understood by those that are already = (so-called) expert. =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik =20 Fra: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]=20 Sendt: 15. juli 2011 11:41 Til: Erik Andersen Cc: PKIX Emne: RE: [pkix] Trust anchors =20 Erik,=20 You are walking on a field of mines. Nevertheless, it is good to have a = ball rolling.=20 Since, I don't like the proposal, I will explain shortly why and will = attach a counter proposal.=20 The first sentence is meaningless for me: "A trust anchor is an entity = that is trusted by=20 a certificate-using system supporting a relying party".=20 The second sentence introduces the concept of "trust anchor store".=20 This concept originally introduced in the PKIX WG is too restrictive.=20 I do know that several vendors have adopted a model where all CA are = equally trusted,=20 but this is far too restrictive and this should not be the general rule. = Trust anchors may be grouped under a set of rules usually called a "validation policy" or a "signature policy".=20 In a given set of rules there are trust anchors and, for each trust = anchor, conditions that shall apply to every certificate of a to-be-tested=20 certification path that ends to that trust anchor, like OIDs for certification policies, key usages, etc ...=20 Trust anchors cannot be be simply grouped in "trust anchor stores", = since different constraints may apply to every trust anchor.=20 This is the reason why I have deleted the text related to the"trust = anchor store".=20 Denis=20 De : "Erik Andersen" =20 A : "PKIX" =20 Date : 14/07/2011 18:46=20 Objet : [pkix] Trust anchors=20 Envoy=E9 par : pkix-bounces@ietf.org=20 _____ =20 To prove I am an optimist, I have produced a first draft for a subclause = on trust anchors to be included in X.509.=20 =20 I will appreciate any constructive comment. =20 =20 Erik Andersen=20 Andersen's L-Service=20 Elsevej 48,=20 DK-3500 Vaerloese=20 Denmark=20 Mobile: +45 2097 1490=20 e-amail: era@x500.eu=20 Skype: andersen-erik=20 http://www.x500.eu/=20 http://www.x500standard.com/=20 http://dk.linkedin.com/in/andersenerik=20 [pi=E8ce jointe "trust-anchor.pdf" supprim=E9e par Denis = PINKAS/FR/BULL] _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0091_01CC4302.F802A420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Denis,

 

Thanks for your comments. I understand that you believe that trust = anchor storage shall not be mentioned in X.509 at = all.

 

X.509 is not that well structured, as it has been written by = different people at different times during a period where concepts and = terms were being developed.

 

As an example, the term trust anchor is used with any previous = introduction. An innocent reader does not necessarily know what a trust = anchor is. Following your proposal, the term trust anchor would still be = used without any introduction.

 

The proposed subclause is intended to be just before a subclause = introducing the concept of certification path. Some of your proposed = text fits nicely in here.

 

It was important to me to emphasise that a trust anchor is some = trusted entity by a relying party and not necessarily trusted by the = end-entity.

 

New player from new countries are coming into the PKI area. X.509 = should be written in such a way that it is understandable for newcomers. = Many PKI specifications can only be understood by those that are already = (so-called) expert.

 

Erik = Andersen

Andersen's = L-Service

Elsevej = 48,

DK-3500 = Vaerloese

Denmark

Mobile: = +45 2097 1490

e-amail: = era@x500.eu=

Skype: = andersen-erik

http://www.x500.eu/

=

http://www.x500standard.com/

http://dk.linkedin.com/in/andersenerik=

 

Fra:<= /b> = denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sendt: = 15. juli 2011 11:41
Til: Erik Andersen
Cc: = PKIX
Emne: RE: [pkix] Trust = anchors

 

Erik, =

You are = walking on a field of mines. Nevertheless, it is good to have a ball = rolling.

Since, I = don't like the proposal, I will explain shortly why and will attach a = counter proposal.

The first = sentence is meaningless for me: "A trust anchor is an entity that = is trusted by
a certificate-using system supporting a relying = party".

The second = sentence introduces the concept of "trust anchor store". =
This concept originally introduced in the PKIX WG is too = restrictive.

I do know = that several vendors have adopted a model where all CA are equally = trusted,
but this is far too restrictive and this should not be the = general rule.

Trust = anchors may be grouped under a set of rules usually called a = "validation policy" or a "signature policy".
In = a given set of rules there are trust anchors and, for each trust anchor, = conditions that shall apply to every certificate of a to-be-tested =
certification path that ends to that trust anchor, like OIDs for = certification policies, key usages, etc ...

Trust = anchors cannot be  be simply grouped in "trust anchor = stores", since different constraints may apply to every trust = anchor.

This is the = reason why I have deleted the text related to the"trust anchor = store".

Denis =






= De :        "Erik = Andersen" <era@x500.eu>
= A :        "PKIX&quo= t; <pkix@ietf.org>
= Date :        14/07/2011 = 18:46
= Objet :        [pkix] Trust = anchors
= Envoy=E9 par :        pkix-bounces@i= etf.org




To prove I am an optimist, = I have produced a first draft for a subclause on trust anchors to be = included in X.509.
 
I will appreciate any = constructive comment.  
 
Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: era@x500.eu
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/ =
http://dk.linkedin.com/in/andersenerik
 [pi=E8ce jointe = "trust-anchor.pdf" supprim=E9e par Denis PINKAS/FR/BULL] = ______________________________________________= _
pkix mailing = list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

------=_NextPart_000_0091_01CC4302.F802A420-- From paul.hoffman@vpnc.org Fri Jul 15 07:36:28 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2C621F8661 for ; Fri, 15 Jul 2011 07:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.653 X-Spam-Level: X-Spam-Status: No, score=-102.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9FrdHJQqOw4 for ; Fri, 15 Jul 2011 07:36:28 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2C06521F8646 for ; Fri, 15 Jul 2011 07:36:28 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6FEaHNG034177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Jul 2011 07:36:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <005c01cc4245$5ecece90$1c6c6bb0$@eu> Date: Fri, 15 Jul 2011 07:36:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <32EBBBC6-E8C2-4FCE-8167-FBFC55A6A425@vpnc.org> References: <005c01cc4245$5ecece90$1c6c6bb0$@eu> To: Erik Andersen X-Mailer: Apple Mail (2.1084) Cc: PKIX Subject: Re: [pkix] Trust anchors 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, 15 Jul 2011 14:36:28 -0000 On Jul 14, 2011, at 9:44 AM, Erik Andersen wrote: > To prove I am an optimist, I have produced a first draft for a = subclause on trust anchors to be included in X.509. Errr, why are we discussing changes to the X.509 spec on this list? That = should be done in the ITU following the ITU's rules, it seems.=20 --Paul Hoffman From era@x500.eu Fri Jul 15 07:57:58 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CD721F8854 for ; Fri, 15 Jul 2011 07:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 Zf213EAcBwpG for ; Fri, 15 Jul 2011 07:57:53 -0700 (PDT) Received: from mail01.dandomain.dk (mail01.dandomain.dk [194.150.112.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEBE21F881C for ; Fri, 15 Jul 2011 07:57:53 -0700 (PDT) Received: from Morten ([95.209.241.49]) by mail01.dandomain.dk (DanDomain Mailserver) with ASMTP id YVU54151; Fri, 15 Jul 2011 16:57:51 +0200 From: "Erik Andersen" To: "'Paul Hoffman'" References: <005c01cc4245$5ecece90$1c6c6bb0$@eu> <32EBBBC6-E8C2-4FCE-8167-FBFC55A6A425@vpnc.org> In-Reply-To: <32EBBBC6-E8C2-4FCE-8167-FBFC55A6A425@vpnc.org> Date: Fri, 15 Jul 2011 16:57:52 +0200 Message-ID: <00af01cc42ff$9549d7c0$bfdd8740$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxC/JegRXY1MjKIR9i0W84e94EPaQAARDaA Content-Language: da Cc: 'PKIX' Subject: Re: [pkix] Trust anchors 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, 15 Jul 2011 14:57:58 -0000 X.509 is also an ISO/IEC standard (ISO/IEC 9594-8), so currently we are following mostly the ISO/IEC rules. We are currently in a ballot process. Very few people participate in the official ballot process. It is important the input to the ballot process is the result of consensus among experts. It is the intension that the result of the discussions will be part of the ITU-T comments into the ISO/IEC ballot process, so we are following the rules. I have felt that we should not update X.509 without consulting all interesting parties. Those not interested can just stay out of the discussion. It could interested to know whether other than Paul has this negative attitude. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sendt: 15. juli 2011 16:36 Til: Erik Andersen Cc: PKIX Emne: Re: [pkix] Trust anchors On Jul 14, 2011, at 9:44 AM, Erik Andersen wrote: > To prove I am an optimist, I have produced a first draft for a subclause on trust anchors to be included in X.509. Errr, why are we discussing changes to the X.509 spec on this list? That should be done in the ITU following the ITU's rules, it seems. --Paul Hoffman From paul.hoffman@vpnc.org Fri Jul 15 08:26:52 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3248521F86EA for ; Fri, 15 Jul 2011 08:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.652 X-Spam-Level: X-Spam-Status: No, score=-102.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZWvdu66tyrh for ; Fri, 15 Jul 2011 08:26:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 63CCA21F86CA for ; Fri, 15 Jul 2011 08:26:51 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6FFQeIZ036845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Jul 2011 08:26:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <00af01cc42ff$9549d7c0$bfdd8740$@eu> Date: Fri, 15 Jul 2011 08:26:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <64CED4A0-CF31-4B2A-B30F-1C9F88B4F345@vpnc.org> References: <005c01cc4245$5ecece90$1c6c6bb0$@eu> <32EBBBC6-E8C2-4FCE-8167-FBFC55A6A425@vpnc.org> <00af01cc42ff$9549d7c0$bfdd8740$@eu> To: "Erik Andersen" X-Mailer: Apple Mail (2.1084) Cc: 'PKIX' Subject: Re: [pkix] Trust anchors 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, 15 Jul 2011 15:26:52 -0000 On Jul 15, 2011, at 7:57 AM, Erik Andersen wrote: > X.509 is also an ISO/IEC standard (ISO/IEC 9594-8), so currently we = are > following mostly the ISO/IEC rules. We are currently in a ballot = process. > Very few people participate in the official ballot process. It is = important > the input to the ballot process is the result of consensus among = experts. It > is the intension that the result of the discussions will be part of = the > ITU-T comments into the ISO/IEC ballot process, so we are following = the > rules. >=20 > I have felt that we should not update X.509 without consulting all > interesting parties. Those not interested can just stay out of the > discussion. >=20 > It could interested to know whether other than Paul has this negative > attitude. The "negative attitude" is based on long experience with SDOs such as = ITU-T bristling when they think that the IETF is infringing on their = territory. Starting a discussion for ITU-T work in an IETF WG could = easily be considered such infringement. Thus, my comment about the = discussion happening under ITU-T rules. I have no idea if ISO/IEC is = either allowed to start new X.509 work, and if they are, if they are = allowed to do so in an IETF WG. That is something for the SDO's various = liaisons to discuss, not us. --Paul Hoffman From era@x500.eu Fri Jul 15 08:45:03 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E947821F89AC for ; Fri, 15 Jul 2011 08:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 1sl42q1CcynP for ; Fri, 15 Jul 2011 08:44:59 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 2145E21F89A3 for ; Fri, 15 Jul 2011 08:44:58 -0700 (PDT) Received: from Morten ([95.209.241.49]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id YWH79356; Fri, 15 Jul 2011 17:44:56 +0200 From: "Erik Andersen" To: "'Paul Hoffman'" References: <005c01cc4245$5ecece90$1c6c6bb0$@eu> <32EBBBC6-E8C2-4FCE-8167-FBFC55A6A425@vpnc.org> <00af01cc42ff$9549d7c0$bfdd8740$@eu> <64CED4A0-CF31-4B2A-B30F-1C9F88B4F345@vpnc.org> In-Reply-To: <64CED4A0-CF31-4B2A-B30F-1C9F88B4F345@vpnc.org> Date: Fri, 15 Jul 2011 17:44:58 +0200 Message-ID: <00b301cc4306$295876f0$7c0964d0$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxDA6Kr/VByIksRQQ2kQPSOOmH6mQAASC7g Content-Language: da Cc: 'PKIX' Subject: Re: [pkix] Trust anchors 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, 15 Jul 2011 15:45:04 -0000 We are not actually proposing new work for X.509, but is primarily concerned with making the text consistent and up-to-date with the current thinking. I have been in the business so long that I am little tired of competition between different groups, where we should cooperate and benefit from each other experiences to get good and non-diverged specifications. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sendt: 15. juli 2011 17:27 Til: Erik Andersen Cc: 'PKIX' Emne: Re: SV: [pkix] Trust anchors On Jul 15, 2011, at 7:57 AM, Erik Andersen wrote: > X.509 is also an ISO/IEC standard (ISO/IEC 9594-8), so currently we are > following mostly the ISO/IEC rules. We are currently in a ballot process. > Very few people participate in the official ballot process. It is important > the input to the ballot process is the result of consensus among experts. It > is the intension that the result of the discussions will be part of the > ITU-T comments into the ISO/IEC ballot process, so we are following the > rules. > > I have felt that we should not update X.509 without consulting all > interesting parties. Those not interested can just stay out of the > discussion. > > It could interested to know whether other than Paul has this negative > attitude. The "negative attitude" is based on long experience with SDOs such as ITU-T bristling when they think that the IETF is infringing on their territory. Starting a discussion for ITU-T work in an IETF WG could easily be considered such infringement. Thus, my comment about the discussion happening under ITU-T rules. I have no idea if ISO/IEC is either allowed to start new X.509 work, and if they are, if they are allowed to do so in an IETF WG. That is something for the SDO's various liaisons to discuss, not us. --Paul Hoffman From era@x500.eu Fri Jul 15 09:03:54 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68F521F8A80 for ; Fri, 15 Jul 2011 09:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.214 X-Spam-Level: X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_50=0.001, HELO_EQ_DK=1.009, 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 Vhae4ErZTRDd for ; Fri, 15 Jul 2011 09:03:50 -0700 (PDT) Received: from mail01.dandomain.dk (mail01.dandomain.dk [194.150.112.201]) by ietfa.amsl.com (Postfix) with ESMTP id ED2D221F89EB for ; Fri, 15 Jul 2011 09:03:49 -0700 (PDT) Received: from Morten ([95.209.241.49]) by mail01.dandomain.dk (DanDomain Mailserver) with ASMTP id YXS05748 for ; Fri, 15 Jul 2011 18:03:48 +0200 From: "Erik Andersen" To: "PKIX" Date: Fri, 15 Jul 2011 18:03:49 +0200 Message-ID: <00b701cc4308$cb901ac0$62b05040$@eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B8_01CC4319.8F18EAC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxDCMibs9AS4k3gQSuXlJMzRJXG9g== Content-Language: da Subject: [pkix] RFC 5280 - 4.1.2.3. Signature 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, 15 Jul 2011 16:03:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B8_01CC4319.8F18EAC0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I will jump to a RFC 5280 question now. What should be put into the Signature field as defined in RFC 5280 - 4.1.2.3 for a to-be-signed certificate? Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik ------=_NextPart_000_00B8_01CC4319.8F18EAC0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I will = jump to a RFC 5280 question now.

 

What should = be put into the Signature field as defined in RFC 5280 - 4.1.2.3 for a = to-be-signed certificate?

 

Erik = Andersen

Andersen's = L-Service

Elsevej = 48,

DK-3500 = Vaerloese

Denmark=

Mobile: +45 2097 = 1490

e-amail: era@x500.eu

Skype: = andersen-erik

http://www.x500.eu/

http://www.x500standard.com/

http://dk.linkedin.com/in/andersenerik

 

------=_NextPart_000_00B8_01CC4319.8F18EAC0-- From paul.hoffman@vpnc.org Fri Jul 15 09:04:01 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5919921F8AB8 for ; Fri, 15 Jul 2011 09:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.65 X-Spam-Level: X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVMCntXSXuQb for ; Fri, 15 Jul 2011 09:04:01 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7042221F8AA8 for ; Fri, 15 Jul 2011 09:04:00 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6FG3mxw039121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Jul 2011 09:03:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <00b301cc4306$295876f0$7c0964d0$@eu> Date: Fri, 15 Jul 2011 09:03:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <80A3F02B-C4D3-42DF-BA88-AB963A5FE67D@vpnc.org> References: <005c01cc4245$5ecece90$1c6c6bb0$@eu> <32EBBBC6-E8C2-4FCE-8167-FBFC55A6A425@vpnc.org> <00af01cc42ff$9549d7c0$bfdd8740$@eu> <64CED4A0-CF31-4B2A-B30F-1C9F88B4F345@vpnc.org> <00b301cc4306$295876f0$7c0964d0$@eu> To: "Erik Andersen" X-Mailer: Apple Mail (2.1084) Cc: 'PKIX' Subject: Re: [pkix] Trust anchors 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, 15 Jul 2011 16:04:01 -0000 On Jul 15, 2011, at 8:44 AM, Erik Andersen wrote: > We are not actually proposing new work for X.509, but is primarily = concerned > with making the text consistent and up-to-date with the current = thinking. The first part of that sentence doesn't match with the second. > I have been in the business so long that I am little tired of = competition > between different groups, where we should cooperate and benefit from = each > other experiences to get good and non-diverged specifications.=20 Fully, fully agree. PKIX vs. X.509 is a stellar example of how silly the = competition can be. --Paul Hoffman From bruce.stephens@isode.com Fri Jul 15 09:09:14 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B79A21F8A67 for ; Fri, 15 Jul 2011 09:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=0.927, 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 IGVXYISq8Dkn for ; Fri, 15 Jul 2011 09:09:13 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 82D6721F8A58 for ; Fri, 15 Jul 2011 09:09:13 -0700 (PDT) Received: from tinier.isode.net (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id for ; Fri, 15 Jul 2011 17:09:11 +0100 Received: by tinier.isode.net (sSMTP sendmail emulation); Fri, 15 Jul 2011 17:09:11 +0100 From: Bruce Stephens To: "PKIX" References: <00b701cc4308$cb901ac0$62b05040$@eu> X-Hashcash: 1:20:110715:pkix@ietf.org::27Loqs6YccOE4i1W:0000189W Date: Fri, 15 Jul 2011 17:09:10 +0100 In-Reply-To: <00b701cc4308$cb901ac0$62b05040$@eu> (Erik Andersen's message of "Fri, 15 Jul 2011 18:03:49 +0200") Message-ID: <80pqlbv848.fsf@tinier.isode.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [pkix] RFC 5280 - 4.1.2.3. Signature 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, 15 Jul 2011 16:09:14 -0000 "Erik Andersen" writes: > I will jump to a RFC 5280 question now. > > What should be put into the Signature field as defined in RFC 5280 - > 4.1.2.3 for a to-be-signed certificate? It's as written, isn't it? This field MUST contain the same algorithm identifier as the signatureAlgorithm field in the sequence Certificate (Section 4.1.1.2). The contents of the optional parameters field will vary [...] From era@x500.eu Fri Jul 15 09:22:46 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9126621F8B10 for ; Fri, 15 Jul 2011 09:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 W9l+GUeR8Uk2 for ; Fri, 15 Jul 2011 09:22:42 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 80EA921F8AD3 for ; Fri, 15 Jul 2011 09:22:41 -0700 (PDT) Received: from Morten ([78.156.214.233]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id YXL13516 for ; Fri, 15 Jul 2011 18:22:16 +0200 From: "Erik Andersen" To: "'PKIX'" References: <00b701cc4308$cb901ac0$62b05040$@eu> <80pqlbv848.fsf@tinier.isode.net> In-Reply-To: <80pqlbv848.fsf@tinier.isode.net> Date: Fri, 15 Jul 2011 18:22:17 +0200 Message-ID: <00c501cc430b$600a70e0$201f52a0$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxDCcVAByowWipBQwKPj+YrdMjFBwAAQ5Pg Content-Language: da Subject: Re: [pkix] [Spam] Re: RFC 5280 - 4.1.2.3. Signature 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, 15 Jul 2011 16:22:46 -0000 Hi Bruce, Sure - my point was, if it is a to-be-signed certificate, the field you refer to is not present or am I misunderstanding something.=20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = Bruce Stephens Sendt: 15. juli 2011 18:09 Til: PKIX Emne: [Spam] Re: [pkix] RFC 5280 - 4.1.2.3. Signature "Erik Andersen" writes: > I will jump to a RFC 5280 question now. > > What should be put into the Signature field as defined in RFC 5280 - > 4.1.2.3 for a to-be-signed certificate? It's as written, isn't it? This field MUST contain the same algorithm identifier as the signatureAlgorithm field in the sequence Certificate (Section 4.1.1.2). The contents of the optional parameters field will vary [...] _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From bruce.stephens@isode.com Fri Jul 15 09:28:48 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF3621F8677 for ; Fri, 15 Jul 2011 09:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.618, 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 7SA+Gca0q6-5 for ; Fri, 15 Jul 2011 09:28:48 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 6355121F8736 for ; Fri, 15 Jul 2011 09:27:46 -0700 (PDT) Received: from tinier.isode.net (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id for ; Fri, 15 Jul 2011 17:27:44 +0100 Received: by tinier.isode.net (sSMTP sendmail emulation); Fri, 15 Jul 2011 17:27:44 +0100 From: Bruce Stephens To: pkix@ietf.org References: <00b701cc4308$cb901ac0$62b05040$@eu> <80pqlbv848.fsf@tinier.isode.net> <00c501cc430b$600a70e0$201f52a0$@eu> X-Hashcash: 1:20:110715:pkix@ietf.org::DzYkM3jfDV3Gvx1D:00002rx/ Date: Fri, 15 Jul 2011 17:27:44 +0100 In-Reply-To: <00c501cc430b$600a70e0$201f52a0$@eu> (Erik Andersen's message of "Fri, 15 Jul 2011 18:22:17 +0200") Message-ID: <80wrfjtsov.fsf@tinier.isode.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [pkix] [Spam] Re: RFC 5280 - 4.1.2.3. Signature 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, 15 Jul 2011 16:28:48 -0000 "Erik Andersen" writes: > Hi Bruce, > > Sure - my point was, if it is a to-be-signed certificate, the field you > refer to is not present or am I misunderstanding something. As far as I know the toBeSigned structure doesn't exist (or isn't being discussed in RFC 5280, anyway) except as it exists in a Certificate. So it makes sense for toBeSigned fields to give information about the signature. [...] From era@x500.eu Fri Jul 15 09:41:08 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE5721F8B6E for ; Fri, 15 Jul 2011 09:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DK=1.009] 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 UqnlTx95+ORB for ; Fri, 15 Jul 2011 09:41:04 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 2347621F8B4B for ; Fri, 15 Jul 2011 09:41:03 -0700 (PDT) Received: from Morten ([78.156.214.233]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id YXE18502 for ; Fri, 15 Jul 2011 18:41:02 +0200 From: "Erik Andersen" To: References: <00b701cc4308$cb901ac0$62b05040$@eu> <80pqlbv848.fsf@tinier.isode.net> <00c501cc430b$600a70e0$201f52a0$@eu> <80wrfjtsov.fsf@tinier.isode.net> In-Reply-To: <80wrfjtsov.fsf@tinier.isode.net> Date: Fri, 15 Jul 2011 18:41:00 +0200 Message-ID: <00c601cc430d$ff552df0$fdff89d0$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxDDGf5HFYPnjslQwC9OKhhurxmPgAAOJQQ Content-Language: da Subject: Re: [pkix] [Spam] Re: [Spam] Re: RFC 5280 - 4.1.2.3. Signature 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, 15 Jul 2011 16:41:08 -0000 As I understand, a to-be-signed certificate may be used as trust anchor information. Can I conclude that the field shall hold the value you would use for signing, if you were to sign it, but never going to? Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = Bruce Stephens Sendt: 15. juli 2011 18:28 Til: pkix@ietf.org Emne: [Spam] Re: [pkix] [Spam] Re: RFC 5280 - 4.1.2.3. Signature "Erik Andersen" writes: > Hi Bruce, > > Sure - my point was, if it is a to-be-signed certificate, the field = you > refer to is not present or am I misunderstanding something.=20 As far as I know the toBeSigned structure doesn't exist (or isn't being discussed in RFC 5280, anyway) except as it exists in a Certificate. So it makes sense for toBeSigned fields to give information about the signature. [...] _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From carl@redhoundsoftware.com Fri Jul 15 09:53:56 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9EF21F8B84 for ; Fri, 15 Jul 2011 09:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 jlW+b4Xv5iWu for ; Fri, 15 Jul 2011 09:53:56 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1123821F8B7A for ; Fri, 15 Jul 2011 09:53:55 -0700 (PDT) Received: by vxi40 with SMTP id 40so1470595vxi.31 for ; Fri, 15 Jul 2011 09:53:55 -0700 (PDT) Received: by 10.52.72.17 with SMTP id z17mr982144vdu.494.1310748835409; Fri, 15 Jul 2011 09:53:55 -0700 (PDT) Received: from [192.168.1.5] (pool-173-79-132-155.washdc.fios.verizon.net [173.79.132.155]) by mx.google.com with ESMTPS id z6sm517435vcv.42.2011.07.15.09.53.53 (version=SSLv3 cipher=OTHER); Fri, 15 Jul 2011 09:53:54 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Fri, 15 Jul 2011 12:53:50 -0400 From: Carl Wallace To: Erik Andersen , Message-ID: Thread-Topic: [pkix] [Spam] Re: [Spam] Re: RFC 5280 - 4.1.2.3. Signature In-Reply-To: <00c601cc430d$ff552df0$fdff89d0$@eu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] [Spam] Re: [Spam] Re: RFC 5280 - 4.1.2.3. Signature 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, 15 Jul 2011 16:53:56 -0000 On 7/15/11 12:41 PM, "Erik Andersen" wrote: >As I understand, a to-be-signed certificate may be used as trust anchor >information. > >Can I conclude that the field shall hold the value you would use for >signing, if you were to sign it, but never going to? See RFC 5914, Section 3, paragraph 1. From bruce.stephens@isode.com Fri Jul 15 11:32:15 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6846521F8BDD for ; Fri, 15 Jul 2011 11:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN0LTvOxf46t for ; Fri, 15 Jul 2011 11:32:15 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id D971821F8BDB for ; Fri, 15 Jul 2011 11:32:14 -0700 (PDT) Received: from cenderis.isode.com (cenderis.demon.co.uk [62.49.17.254]) by rufus.isode.com (submission channel) via TCP with ESMTPA id for ; Fri, 15 Jul 2011 19:32:13 +0100 X-SMTP-Protocol-Errors: PIPELINING From: Bruce Stephens To: References: X-Hashcash: 1:20:110715:pkix@ietf.org::nQOdRHqcYBE0er9p:000007zg Date: Fri, 15 Jul 2011 19:32:11 +0100 In-Reply-To: (Carl Wallace's message of "Fri, 15 Jul 2011 12:53:50 -0400") Message-ID: <84zkkf8kes.fsf@cenderis.demon.co.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [pkix] [Spam] Re: [Spam] Re: RFC 5280 - 4.1.2.3. Signature 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, 15 Jul 2011 18:32:15 -0000 Carl Wallace writes: > On 7/15/11 12:41 PM, "Erik Andersen" wrote: > >>As I understand, a to-be-signed certificate may be used as trust anchor >>information. You're right, I had forgotten about its use in RFC 5914. >>Can I conclude that the field shall hold the value you would use for >>signing, if you were to sign it, but never going to? > > See RFC 5914, Section 3, paragraph 1. So (as I'd expect) it has no meaning in this context, though we'd anticipate that it would have the same value as in some certificate (just because you'd probably be creating it by removing the signature from a certificate and adjusting the content a little). From thierry.moreau@connotech.com Fri Jul 15 12:35:10 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBFD21F8C2B for ; Fri, 15 Jul 2011 12:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.052 X-Spam-Level: * X-Spam-Status: No, score=1.052 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 HSdz1v799dtX for ; Fri, 15 Jul 2011 12:35:10 -0700 (PDT) Received: from bretelle.intaglionic.org (unknown [76.10.176.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7E51F21F8C02 for ; Fri, 15 Jul 2011 12:35:10 -0700 (PDT) Received: from [192.168.1.200] (unknown [192.168.1.200]) by bretelle.intaglionic.org (Postfix) with ESMTPA id 8608B30623; Fri, 15 Jul 2011 19:58:21 -0400 (EDT) Message-ID: <4E20988F.1090902@connotech.com> Date: Fri, 15 Jul 2011 15:44:15 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Erik Andersen References: <005c01cc4245$5ecece90$1c6c6bb0$@eu> <009001cc42f2$3479d420$9d6d7c60$@eu> In-Reply-To: <009001cc42f2$3479d420$9d6d7c60$@eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'PKIX' , SG17-Q11 , Directory list Subject: Re: [pkix] Trust anchors 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, 15 Jul 2011 19:35:11 -0000 Erik Andersen wrote: > Hi Denis, > > > > X.509 is not that well structured, as it has been written by different > people at different times during a period where concepts and terms were > being developed. > > > > As an example, the term trust anchor is used with[out] any previous > introduction. An innocent reader does not necessarily know what a trust > anchor is. Your text nicely addresses this issue. It is clear, concise, and not misleading to me: obviously, a trust anchor store may include additional information so that is is used according to a local signature validation policy. From someone ever climbing the learning curve with respect to applied PK crypto. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 From kent@bbn.com Sat Jul 16 10:48:26 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF30D21F8766 for ; Sat, 16 Jul 2011 10:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.277 X-Spam-Level: X-Spam-Status: No, score=-106.277 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoZZQV+rFWp7 for ; Sat, 16 Jul 2011 10:48:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2765C21F8606 for ; Sat, 16 Jul 2011 10:48:26 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57059 helo=[10.205.137.93]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qi8yV-000HCe-Dp; Sat, 16 Jul 2011 13:48:24 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201107141714.p6EHELl7025964@fs4113.wdf.sap.corp> References: <201107141714.p6EHELl7025964@fs4113.wdf.sap.corp> Date: Sat, 16 Jul 2011 10:06:55 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org, Paul Hoffman Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 17:48:26 -0000 At 7:14 PM +0200 7/14/11, Martin Rex wrote: >Paul Hoffman wrote: >> >> On Jul 14, 2011, at 5:20 AM, Erik Andersen wrote: >> > >> > At least there seems to be agreement on what a certification path is and >> > what is forward and what is reverse. That is propress. >> >> You sound like an optimist. Note the definition that was posted: > >> Certification Path: An ordered list of certificates starting with a >> certificate signed by a trust anchor and ending with the target >> certificate. >> >> In fact, many people assume that the certification path includes the >> trust anchor. Thus, Peter's skepticism is warranted, even in this case. > >But including the trust anchor in the certification path is extremely >reasonable, and it is the X.something specs that are seriously flawed >in this detail. I'm in favor of having the checks that we apply to certs along a path, be applied to the cert immediately below the TA, which would include applying name constraints, policy constraints, etc. However, that is not the same as transmitting a TA as part of a path. Because a TA has to be verified OOB, it makes less sense to include it in a transmitted path. The first cert (below the TA) contains enough info to select a TA from among a set that an RP holds, i.e., the Issuer name and the AKI. also, as Paul noted, we do not mandate that a TA be a self-signed cert. So, it's not clear what set of formats one would have to support to enable including a TA in a cert path. If I have a TA in some non-cert form, I cannot create a self-signed cert for it, so ... Steve From kent@bbn.com Sat Jul 16 10:48:27 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1520121F8606 for ; Sat, 16 Jul 2011 10:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.416 X-Spam-Level: X-Spam-Status: No, score=-106.416 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrW-U-sKkZW3 for ; Sat, 16 Jul 2011 10:48:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A4F8A21F874E for ; Sat, 16 Jul 2011 10:48:26 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57059 helo=[10.205.137.93]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qi8yX-000HCe-D5; Sat, 16 Jul 2011 13:48:25 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <00b301cc4306$295876f0$7c0964d0$@eu> References: <005c01cc4245$5ecece90$1c6c6bb0$@eu> <32EBBBC6-E8C2-4FCE-8167-FBFC55A6A425@vpnc.org> <00af01cc42ff$9549d7c0$bfdd8740$@eu> <64CED4A0-CF31-4B2A-B30F-1C9F88B4F345@vpnc.org> <00b301cc4306$295876f0$7c0964d0$@eu> Date: Sat, 16 Jul 2011 10:15:39 -0400 To: "Erik Andersen" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: 'PKIX' , 'Paul Hoffman' Subject: Re: [pkix] Trust anchors X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 17:48:27 -0000 At 5:44 PM +0200 7/15/11, Erik Andersen wrote: >We are not actually proposing new work for X.509, but is primarily concerned >with making the text consistent and up-to-date with the current thinking. > >I have been in the business so long that I am little tired of competition >between different groups, where we should cooperate and benefit from each >other experiences to get good and non-diverged specifications. > >Erik Andersen Erik, Thanks for the heads up. Since PKIX tries to maintain alignment with the X.509 base standard, I think it is appropriate for you to raise this question on the PKIX list. As I noted in my reply to Martin, I have long been in favor of including the data that may be associated with a trust anchor, and which can be expressed in a cert (e.g., extensions), as part of the path validation process. (Sharon Boyen can attest to my views in this regard, from several years ago.) This does not translate into including a TA in a cert path wrt transmission. Steve From kent@bbn.com Sun Jul 17 08:17:42 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA4D21F874E for ; Sun, 17 Jul 2011 08:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.208 X-Spam-Level: X-Spam-Status: No, score=-106.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSIT7vB7Q0cJ for ; Sun, 17 Jul 2011 08:17:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C5EB821F86AA for ; Sun, 17 Jul 2011 08:17:00 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:42140 helo=[198.18.176.250]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QiT5K-0004gp-AQ; Sun, 17 Jul 2011 11:16:48 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201107141907.p6EJ7vOV002530@fs4113.wdf.sap.corp> References: <201107141907.p6EJ7vOV002530@fs4113.wdf.sap.corp> Date: Sun, 17 Jul 2011 11:16:38 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org, Paul Hoffman Subject: Re: [pkix] Certification path 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, 17 Jul 2011 15:17:42 -0000 At 9:07 PM +0200 7/14/11, Martin Rex wrote: >Paul Hoffman wrote: >> >> On Jul 14, 2011, at 10:14 AM, Martin Rex wrote: >> > But including the trust anchor in the certification path is extremely >> > reasonable, and it is the X.something specs that are seriously flawed >> > in this detail. >> >> What if the trust anchor is not a certificate? (Cue the TAMP music....) >> >> If you want a certification path to only include certificates, >> you cannot say that it must include the trust anchor. > >In theory, you are quite right. > >There exists a whole lot of wild fantasy about non-X.509 TrustAnchors >(and their management) that creates a shitload of needless complexity. > >But there seems to (quite reasonably) exist PKI software, where you >must supply all trust anchors as X.509 certs, and the most common >occurance of TAs are self-signed X.509 certs. > Yes, there is a ,lot of software that requires a TA to be supplied as an SS cert. Much of that software is also non-complaint with X.509 and 3280/56280. The fact that many folks believe that every TA MUST be provided as an SS cert is an illustration of widespread ignorance (re these standards), not a motivation to change standards :-). Steve From kent@bbn.com Sun Jul 17 08:17:49 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B688521F891D for ; Sun, 17 Jul 2011 08:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.466 X-Spam-Level: X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOgEGE9SFNVc for ; Sun, 17 Jul 2011 08:17:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 80C5821F88D9 for ; Sun, 17 Jul 2011 08:17:47 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:60875 helo=[198.18.176.250]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QiT6J-0004h1-0h for pkix@ietf.org; Sun, 17 Jul 2011 11:17:47 -0400 Mime-Version: 1.0 Message-Id: Date: Sun, 17 Jul 2011 11:17:39 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] reminder to presenters 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, 17 Jul 2011 15:17:49 -0000 The agenda has been posted, as have the agenda slides. Yhis is a second call for presenters in the PKIX session to send slides to me for posting. Thanks, Steve From kent@bbn.com Sun Jul 17 08:24:11 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C8321F85EC for ; Sun, 17 Jul 2011 08:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.487 X-Spam-Level: X-Spam-Status: No, score=-106.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vixicNA6tDsd for ; Sun, 17 Jul 2011 08:24:10 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A29CB21F85E2 for ; Sun, 17 Jul 2011 08:24:10 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49226 helo=[198.18.176.250]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QiTCU-0004iw-2E for pkix@ietf.org; Sun, 17 Jul 2011 11:24:10 -0400 Mime-Version: 1.0 Message-Id: Date: Sun, 17 Jul 2011 11:24:08 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-901206246==_ma============" Subject: [pkix] whoops 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, 17 Jul 2011 15:24:11 -0000 --============_-901206246==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Jim Schaad asked to me request WGLC for draft-ietf-pubkey-caps-02 at the same time that he requested WGLC for 5272bis. Obviously I forgot to include the former doc. So, let's begin WGLC for this draft. Becuase we'll be at the IETF meeting soon, we'll have a longer-than-usual WGLC, ending on August 5. Thanks, Steve --============_-901206246==_ma============ Content-Type: text/html; charset="us-ascii" whoops
Jim Schaad asked to me request WGLC for draft-ietf-pubkey-caps-02  at the same
time that he requested WGLC for 5272bis. Obviously I forgot to include the former doc.

So, let's begin WGLC for this draft. Becuase we'll be at the IETF meeting soon, we'll have a longer-than-usual WGLC, ending on August 5.

Thanks,

Steve
--============_-901206246==_ma============-- From DPKemp@missi.ncsc.mil Mon Jul 18 12:27:08 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852D9228010 for ; Mon, 18 Jul 2011 12:27:08 -0700 (PDT) X-Quarantine-ID: <4Gl-4T57vlRL> X-Amavis-Modified: Mail body modified (defanged) by ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat 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 4Gl-4T57vlRL for ; Mon, 18 Jul 2011 12:27:07 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1311017228-4785-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5100A22800E for ; Mon, 18 Jul 2011 12:27:07 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p6IJR6JG012827 for ; Mon, 18 Jul 2011 15:27:06 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Jul 2011 15:27:11 -0400 Date: Mon, 18 Jul 2011 15:27:06 -0400 Message-ID: In-Reply-To: References: <004001cc4210$b3cb3210$1b619630$@eu> From: "Kemp, David P." To: "PKIX" Subject: Re: [pkix] Certification path 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, 18 Jul 2011 19:27:08 -0000 This is a multi-part message in MIME format... ------------=_1311017228-4785-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1311017228-4785-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Return-Path: Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5100A22800E for ; Mon, 18 Jul 2011 12:27:07 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p6IJR6JG012827 for ; Mon, 18 Jul 2011 15:27:06 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Jul 2011 15:27:11 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC4580.AE0E4B58" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [pkix] Certification path Date: Mon, 18 Jul 2011 15:27:06 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Certification path Thread-Index: AcxCLZOdt3dlDNsiSJywyF3l61MDBwDSK7Sg References: <004001cc4210$b3cb3210$1b619630$@eu> From: "Kemp, David P." To: "PKIX" X-OriginalArrivalTime: 18 Jul 2011 19:27:11.0562 (UTC) FILETIME=[B10F92A0:01CC4580] This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4580.AE0E4B58 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does Interstate 95 go from north to south, or from south to north? It hardly matters whether one starts paving in Miami FL or in Houlton ME, or start at both ends and meet in the middle - the end result after construction is done is a path. This sounds less like a minefield question (c.f. non-repudiation) and more like a meaningless question. Even for validation, RFC 5280 says: This section describes an algorithm for validating certification paths. Conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality equivalent to the external behavior resulting from this procedure. Any algorithm may be used by a particular implementation so long as it derives the correct result. Whoever decided to flip a coin and assign Forward and Reverse to a particular direction along a cert path did PKI a great disservice, about as silly as labeling the northbound lanes of I-95 as forward and southbound as reverse. But now that the coin has landed, the standard PKI assignment of forward is rootward, and reverse is leafward: Building in the Forward direction: The process of building a certification path from the target certificate to a trust anchor. 'Forward' is the former name of the crossCertificatePair element 'issuedToThisCA'. Dave -----Original Message----- From: Stephen Kent At 12:27 PM +0200 7/14/11, Erik Andersen wrote: >Does a certification path go from the end-entity to the trust anchor=20 >or does it go from the trust anchor to the end-entity? What is=20 >forward and what is reverse? > paths generally are built bottom up, always verified top down. So, in=20 part, it's a question of which activity one is performing. ------_=_NextPart_001_01CC4580.AE0E4B58 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgcTAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAHgAAAFJFOiBbcGtpeF0gQ2VydGlm aWNhdGlvbiBwYXRoAJYKAQWAAwAOAAAA2wcHABIADwAbAAYAAQAsAQEggAMADgAAANsHBwASAA8A GwAGAAEALAEBCYABACEAAAA2NTkyRDdGOUQzOTVDRDQ0QUZFOEIwRkZEN0VENUZEQQCqBwEDkAYA fA0AAEYAAAALAAIAAQAAAAMAJgAAAAAACwArAAAAAAADAC4AAAAAAAMANgAAAAAAQAA5AGA8wq2A RcwBHgA9AAEAAAAFAAAAUkU6IAAAAAACAUcAAQAAADMAAABjPVVTO2E9IDtwPUV4Y2hhbmdlTlNB O2w9REFCRUNLLTExMDcxODE5MjcwNlotMzE5MAAAHgBwAAEAAAAaAAAAW3BraXhdIENlcnRpZmlj YXRpb24gcGF0aAAAAAIBcQABAAAAGwAAAAHMQi2Tnbd3ZQzbIkicsMhd5etTAwcA0iu0oAAeABoM AQAAAA8AAABLZW1wLCBEYXZpZCBQLgAAHgAdDgEAAAAaAAAAW3BraXhdIENlcnRpZmljYXRpb24g cGF0aAAAAAIBCRABAAAAQAUAADwFAACBCAAATFpGdWjEABEDAAoAcmNwZzEyNeIyA0N0ZXgFQQED Aff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwR MwjvCfe2OxgfDjA1ESIMYGMAUDMLCQFkMzYWUAumIETabweRSQIwBJBzAZAOsIAgOTUgZ28gA1JE IG4XwWggdB4wc/MIYB7QLCAFsR5THzMe8jkeoz8gHTAFQBPhZGwceSAAwAJAHXEgd2j/FCAiYAXA AiAd0B2RACAEIOUKsHYLgGcgC4AF0AcwYG1pIEZMH5Ij8UhtCGBsHwAkAUUfgyMTIN0dsCAG4B7R CfBkBCAAcH5kIcAJ4AVAI/EigSHAabZkIZAd0C0n4ybhIBggfnMlMSZQAYASgQWgAIB0MnIa0HRp JWEEACBk2yLSKuFhI3Ee0C4KogqE+QqAVGgq4R8xJvIocAQReGxpax3QK5AkUCLgZnUIkGwnUHEK UB2QKqIokGMuZi4ekW4tGCDYcHVkBzAqkiknJAWw+x3QLdZlAHAjsS2DLuYr+9xFdgnwHkAFsXYH QChAQzBzH4BSRkMgDkA4wRZQc2F5czosCiEQviAsxAWQKpMBAATyYgeR/wORB0AeIAUQHtAegDRK I8HuYwSQKpAugGMwczaHK7J2cy+wEiFuNEEuQSPRbT0LUGUHgAIwMHMEIG9m+yfhLOJwBZA6hyZQ MUEeoO50NocYIC7gaRghHvI81zc99Di3H4BiH1AF0FVT/lQjcANgI6ABAB5ALTAqg/k0kXR5NodA QjSBQVMeMN8oww7QBJEHQCaAZRPgI6B/BbEpRCOyHlM+A0MhOkBkzQhwZSv1NuFBbiGwOLhnAMAh sDhAIHUUECdQYvdJ0SNxOmFjJTAKwTzcHyHnLXACICPQYXM2hzkAN9H/BRA0AAQgJ/IFoRggKoAp Nfkr+1doHQA0AAXABYFDYfVAo2Yt0HArgQWgI/EnMqtNwACQZwOgRgWwdwsR/ScjUlFCFBAe8kuL MFBPkj8+8010OjMro1XhJ1BQS/5JK4EJwSZhMFAEEASQI6D/OkAfgAGgH0FNsR8gAxAhof9Z0Qtg OEAt0CPBJ/Ieo1mBzydBC2Ai4D2zSS0d8VnR/zRBU+cfM1u0WdEYIFSTO/H+QkKhHqAH4B7QJmFP JCPx/xPgWnIm8AmAH4An8h2RJvD/U/JX81NTQUM90V0mKuEDYP8moFPiWVEpE1SUKuEocCmw/1Pi Nh5fYAMQMFAjxCfyU7b9Vfc6NwEd0EiDBBE90UKQ/WdVYTaHNuE6S1dUR+VU0f0KwGcnkTpIVNUq UR2QJyGvE9AFsEkYNuEnU7UnKtL/J/I8UhKBRBAHgD3ET0EDYPUEEENt+FALcAXALqA9E0dvywQB ClBkVG8swkPUQScr+0QjkGUsCiwEai14ck8FEGcLgEaBTd0tkWFtoHhzLARGA2FpQNpTDrBwImAD oEt0VywERkEFQA4gOjI3V+BNGCArMAHQFlA3LzGqNH2AMR+ARQUQa0mhdwSBFBADoHcDYA6wNhU+ 3xzzVvRr/R4mKMUtPTFEQf9Fpm76CuN/gQWxKxAHkU5x/4FagztFtoInIQBRECZhKuHff0VdKiJQ iARexT9/RSwK/zujHhAJ8ASQB0BaMjFBalKnJnMfAB6AdXBZUWxT4H818DRwBnIIkECiUnArEHf7 MxAGAG8fgCPxi2YAII/R/HQnK3Iu5z3CIlAN4B7gvwDQKpAjoIKRKyU+YHI8VQUr+32VAB4ANRAB AAAAQQAAADxDMUE0N0YxNTQwREYzMjQ2QThEMzBDODUzQzA1RDBEQTAzREUyMjcwQERBQkVDSy5t aXNzaS5uY3NjLm1pbD4AAAAAHgA5EAEAAABNAAAAPDAwNDAwMWNjNDIxMCRiM2NiMzIxMCQxYjYx OTYzMCRAZXU+IDxwMDYyNDA4MDJjYTQ0YTRkZTc2NDJAWzE5Mi4xLjI1NS4yMTBdPgAAAAAeAEIQ AQAAACgAAAA8cDA2MjQwODAyY2E0NGE0ZGU3NjQyQFsxOTIuMS4yNTUuMjEwXT4AAwCAEP////8f APMQAQAAAEgAAABSAEUAJQAzAEEAIABbAHAAawBpAHgAXQAgAEMAZQByAHQAaQBmAGkAYwBhAHQA aQBvAG4AIABwAGEAdABoAC4ARQBNAEwAAAALAPYQAAAAAEAABzD76AuugEXMAUAACDApNxqugEXM AQIBEDABAAAARgAAAAAAAACSY/KWVP7TEaP4AIBfMZxFBwBeSkCXo5TSEaPFAIBfvsi/AAABc108 AADLFhE/CNOlT5p8aj1IRKKnAAACcSseAAAAAAMA3j+fTgAAAwDxPwkEAAAeAPg/AQAAAA8AAABL ZW1wLCBEYXZpZCBQLgAAAgH5PwEAAABNAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9P PUVYQ0hBTkdFTlNBL09VPU1JU1NJL0NOPVJFQ0lQSUVOVFMvQ049RFBLRU1QMQAAAAAeAPo/AQAA ABUAAABTeXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfs/AQAAAB4AAAAAAAAA3KdAyMBCEBq0uQgA Ky/hggEAAAAAAAAALgAAAAMA/T/kBAAAAwAZQAAAAAADABpAAAAAAB4AMEABAAAACAAAAERQS0VN UDEAHgAxQAEAAAAIAAAARFBLRU1QMQAeADhAAQAAAAgAAABEUEtFTVAxAB4AOUABAAAAAgAAAC4A AAADAHZA/////wMACVkBAAAAAwABbgAAAAADACGBAyAGAAAAAADAAAAAAAAARgAAAAABgQAAAAAA AAUAIoEDIAYAAAAAAMAAAAAAAABGAAAAAAKBAAAAAAAAAAAAAAMAJIEDIAYAAAAAAMAAAAAAAABG AAAAABOBAAABAAAACwAlgQMgBgAAAAAAwAAAAAAAAEYAAAAAHIEAAAAAAAALACeBAyAGAAAAAADA AAAAAAAARgAAAAAmgQAAAAAAAAMAKYEDIAYAAAAAAMAAAAAAAABGAAAAABCBAAAAAAAAAwAqgQMg BgAAAAAAwAAAAAAAAEYAAAAAEYEAAAAAAAADAC2BAyAGAAAAAADAAAAAAAAARgAAAAAqgQAAAAAA AAMAMIEDIAYAAAAAAMAAAAAAAABGAAAAACmBAAAAAAAACwAxgQMgBgAAAAAAwAAAAAAAAEYAAAAA JIEAAAAAAAALADKBAyAGAAAAAADAAAAAAAAARgAAAAAsgQAAAAAAAB4AM4EDIAYAAAAAAMAAAAAA AABGAAAAACeBAAABAAAAAQAAAAAAAAADADSBAyAGAAAAAADAAAAAAAAARgAAAAASgQAAAQAAAB4A NYEDIAYAAAAAAMAAAAAAAABGAAAAACGBAAABAAAAAQAAAAAAAAALADaBAyAGAAAAAADAAAAAAAAA RgAAAAADgQAAAAAAAAMAOYEDIAYAAAAAAMAAAAAAAABGAAAAACOBAAD///9/CwCIgQggBgAAAAAA wAAAAAAAAEYAAAAADoUAAAAAAAADAO2BCCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsA8oEI IAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwD8gQggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAA AAADAAOCCCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsA7IIIIAYAAAAAAMAAAAAAAABGAAAA AAaFAAAAAAAACwDwggggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAAAAABAAOyDCCAGAAAAAADAAAAA AAAARgAAAAC/hQAAMLBNf4BFzAELACkAAAAAAAsAIwAAAAAAAwAGEALnyEADAAcQbwUAAAMAEBAA AAAAAwAREAEAAAAeAAgQAQAAAGUAAABET0VTSU5URVJTVEFURTk1R09GUk9NTk9SVEhUT1NPVVRI LE9SRlJPTVNPVVRIVE9OT1JUSD9JVEhBUkRMWU1BVFRFUlNXSEVUSEVST05FU1RBUlRTUEFWSU5H SU5NSUFNSUZMAAAAAAIBfwABAAAAQQAAADxDMUE0N0YxNTQwREYzMjQ2QThEMzBDODUzQzA1RDBE QTAzREUyMjcwQERBQkVDSy5taXNzaS5uY3NjLm1pbD4AAAAA4is= ------_=_NextPart_001_01CC4580.AE0E4B58-- ------------=_1311017228-4785-1-- From mrex@sap.com Mon Jul 18 13:10:16 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC26821F8761 for ; Mon, 18 Jul 2011 13:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.888 X-Spam-Level: X-Spam-Status: No, score=-9.888 tagged_above=-999 required=5 tests=[AWL=0.361, 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 VyJjQxriEHux for ; Mon, 18 Jul 2011 13:10:16 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C43BB21F86DF for ; Mon, 18 Jul 2011 13:10:15 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6IK9aTC021042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2011 22:09:36 +0200 (MEST) From: Martin Rex Message-Id: <201107182009.p6IK9ZxG009624@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Mon, 18 Jul 2011 22:09:35 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Jul 17, 11 11:16:38 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification path 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, 18 Jul 2011 20:10:17 -0000 Stephen Kent wrote: > > Martin Rex wrote: > > > >There exists a whole lot of wild fantasy about non-X.509 TrustAnchors > >(and their management) that creates a shitload of needless complexity. > > > >But there seems to (quite reasonably) exist PKI software, where you > >must supply all trust anchors as X.509 certs, and the most common > >occurance of TAs are self-signed X.509 certs. > > Yes, there is a ,lot of software that requires a TA to be supplied > as an SS cert. Much of that software is also non-complaint with X.509 > and 3280/56280. The fact that many folks believe that every TA MUST be > provided as an SS cert is an illustration of widespread ignorance (re > these standards), not a motivation to change standards :-). rfc3280 and rfc5280 are documents with probably the highest number of questionable bells-and-whistles in the RFC series. But both documents are at "Proposed Standard" level, meaning that they can be expected to overdo in what the recommend and require, and that exploring less is perfectly sufficient and reasonable, so that during eventual progression of these document on the maturity ladder, many of the current recommendations and requirements will have to be cut down to more reasonable levels, bringing the complexity of the technology down to useful levels. The purpose of IETF standards should be about what is generally useful, and not be focusing as much on what is desired by some small niches, but completely irrelevant for >90% of the consumers of the technology. Wrapping keys and relevant attributes of TAs into X.509 certificates is a trivial no-brainer for the creator of the keying material. And it would be perfectly reasonable for the IETF to require TAs to be created as "X.509 plus X" as mandatory for interoperability. As mentioned, a lot of PKI software requires you to supply TAs as X.509 certs for performing X.509 certificate path validation. And for interop, mandating TAs to be distributed as X.509 certs make a whole lot of sense and simplifies a lot of things. It fits into PKCS#7 and PKCS#12 nicely, works with the TLS certificate_list, could even be used with the X509PKIPathv1 data type, where none of the non-X.509 certs fits. -Martin From carl@redhoundsoftware.com Mon Jul 18 13:48:12 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05E521F876A for ; Mon, 18 Jul 2011 13:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 QM8PiVPAy9g0 for ; Mon, 18 Jul 2011 13:48:12 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1D521F8764 for ; Mon, 18 Jul 2011 13:48:11 -0700 (PDT) Received: by vws12 with SMTP id 12so3365146vws.31 for ; Mon, 18 Jul 2011 13:48:11 -0700 (PDT) Received: by 10.52.95.134 with SMTP id dk6mr6708457vdb.354.1311022089995; Mon, 18 Jul 2011 13:48:09 -0700 (PDT) Received: from [192.168.1.5] (pool-173-79-132-155.washdc.fios.verizon.net [173.79.132.155]) by mx.google.com with ESMTPS id r12sm2030276vcq.36.2011.07.18.13.48.06 (version=SSLv3 cipher=OTHER); Mon, 18 Jul 2011 13:48:09 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Mon, 18 Jul 2011 16:48:01 -0400 From: Carl Wallace To: Message-ID: Thread-Topic: [pkix] Certification path In-Reply-To: <201107182009.p6IK9ZxG009624@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Certification path 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, 18 Jul 2011 20:48:12 -0000 > >Wrapping keys and relevant attributes of TAs into X.509 certificates >is a trivial no-brainer for the creator of the keying material. >And it would be perfectly reasonable for the IETF to require >TAs to be created as "X.509 plus X" as mandatory for interoperability. You have used the term "X.509 plus X" a couple of times now. What do you mean and how does it differ from RFC 5914, which permits X.509, X.509 minus signature and X.509 plus X (where X is TrustAnchorInfo) to represent a trust anchor? >As mentioned, a lot of PKI software requires you to supply TAs as >X.509 certs for performing X.509 certificate path validation. >And for interop, mandating TAs to be distributed as X.509 certs >make a whole lot of sense and simplifies a lot of things. >It fits into PKCS#7 and PKCS#12 nicely, works with the TLS >certificate_list, >could even be used with the X509PKIPathv1 data type, where none of >the non-X.509 certs fits. It's fine to carry TAs in these containers as long as you don't use them from there without some additional checks. From kent@bbn.com Tue Jul 19 14:20:55 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA79122800F for ; Tue, 19 Jul 2011 14:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-B0bFaMe8py for ; Tue, 19 Jul 2011 14:20:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6F307228006 for ; Tue, 19 Jul 2011 14:20:55 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49165) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QjHih-000CZX-Dm; Tue, 19 Jul 2011 17:20:47 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201107182009.p6IK9ZxG009624@fs4113.wdf.sap.corp> References: <201107182009.p6IK9ZxG009624@fs4113.wdf.sap.corp> Date: Tue, 19 Jul 2011 17:11:49 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification path 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, 19 Jul 2011 21:20:56 -0000 Martin, Thansk for your input. 5280 has been ready to progress from proposed to draft, except for a couple of obscure issues that are not related to any of the topics you cited. It's not that a self-signed cert is a bad format for a TA, it's that it is not the only good format, and thus will not be mandated as THE format. We have other PKIX RFCs that address this issue. Steve From mrex@sap.com Tue Jul 19 17:07:53 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDDA21F8A4B for ; Tue, 19 Jul 2011 17:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.395, 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 iPDM7Zaxx2NO for ; Tue, 19 Jul 2011 17:07:52 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 89CDD21F8A35 for ; Tue, 19 Jul 2011 17:07:52 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6K07iWD003629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jul 2011 02:07:44 +0200 (MEST) From: Martin Rex Message-Id: <201107200007.p6K07hbq018989@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Wed, 20 Jul 2011 02:07:43 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Jul 19, 11 05:11:49 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification path 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, 20 Jul 2011 00:07:53 -0000 Stephen Kent wrote: > > Thanks for your input. 5280 has been ready to progress from proposed > to draft, except for a couple of obscure issues that are not related > to any of the topics you cited. There are few things in rfc5280 that IMO need fixing, even when not ripping out and not downgrading requirements. > > It's not that a self-signed cert is a bad format for a TA, it's that > it is not the only good format, and thus will not be mandated as THE > format. We have other PKIX RFCs that address this issue. I think that there should be a mandatory to support TA format for PKIX, and that should be X.509. Support for attributes beyond X.509 are just fine being optional. I definitely see that as a prerequisite for going to Draft Standard. SSLv3 (defined by Netscape) did not have any mandatory cipher suites. TLSv1.0 did have one single mandatory cipher suite (but a very bad choice for crypto-policital-reasons that did not match the installed base at all). TLSv1.1 fixed that to mandate the best ciphersuite defined by SSLv3 (and what everyone had implemented). Not mandating one particular solution is fine when you're still at proposed, the technology is young and you have no idea about which format will succeed in the marketplace. PKIX is 10+ years down the road, so when going to Draft Standard, there really ought to be a requirement for a mandatory TA format. The marketplace has long decided that the common denominator is X.509. The only reason that there ever was "less than X.509" is expensive small-storage hardware tokens 15+ years ago, where dropping the signature of a certificate did help slightly. That is no longer a valid excuse, just as the "size of an IPv4+IPv6 dual-stack vs. IPv4-only" should no longer be a valid excuse for not supporting IPv6 today. -Martin From kyanha@kyanha.net Wed Jul 20 02:03:03 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0241D21F84EB for ; Wed, 20 Jul 2011 02:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_25=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 NMfLRm+1jPYr for ; Wed, 20 Jul 2011 02:03:01 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2C5821F86A5 for ; Wed, 20 Jul 2011 02:03:01 -0700 (PDT) Received: by iwn39 with SMTP id 39so17245iwn.31 for ; Wed, 20 Jul 2011 02:03:01 -0700 (PDT) Received: by 10.231.114.104 with SMTP id d40mr7379979ibq.114.1311152580770; Wed, 20 Jul 2011 02:03:00 -0700 (PDT) Received: from penango (ip68-96-191-113.lv.lv.cox.net [68.96.191.113]) by mx.google.com with ESMTPS id us2sm49655icb.19.2011.07.20.02.02.58 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 02:02:59 -0700 (PDT) From: "Kyle Hamilton" To: mrex@sap.com Date: Wed, 20 Jul 2011 02:02:46 -0700 (Pacific Daylight Time) Message-ID: In-Reply-To: <004001cc4210$b3cb3210$1b619630$@eu> References: <004001cc4210$b3cb3210$1b619630$@eu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.8.1eqgqc2dv80lkbmqenh7a2 Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification path 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, 20 Jul 2011 09:03:03 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.8.1eqgqc2dv80lkbmqenh7a2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=utf-8 DQoNCk9uIFR1ZSwgSnVsIDE5LCAyMDExIGF0IDU6MDcgUE0sIE1hcnRpbiBSZXggPG1yZXhAc2Fw LmNvbT4gd3JvdGU6DQo+IFN0ZXBoZW4gS2VudCB3cm90ZToNCj4+DQo+PiBUaGFua3MgZm9yIHlv dXIgaW5wdXQuIMKgNTI4MCBoYXMgYmVlbiByZWFkeSB0byBwcm9ncmVzcyBmcm9tIHByb3Bvc2Vk DQo+PiB0byBkcmFmdCwgZXhjZXB0IGZvciBhIGNvdXBsZSBvZiBvYnNjdXJlIGlzc3VlcyB0aGF0 IGFyZSBub3QgcmVsYXRlZA0KPj4gdG8gYW55IG9mIHRoZSB0b3BpY3MgeW91IGNpdGVkLg0KPg0K PiBUaGVyZSBhcmUgZmV3IHRoaW5ncyBpbiByZmM1MjgwIHRoYXQgSU1PIG5lZWQgZml4aW5nLCBl dmVuDQo+IHdoZW4gbm90IHJpcHBpbmcgb3V0IGFuZCBub3QgZG93bmdyYWRpbmcgcmVxdWlyZW1l bnRzLg0KDQpTdWNoIGFzICJwZXJtaXR0ZWQgc3VidHJlZXMiIGJlaW5nIGxpbWl0ZWQgdG8gQ0Eg Y2VydGlmaWNhdGVzLg0KDQpXaGF0IGV4YWN0bHkgaXMgdGhlIENBOmZhbHNlIGZsYWc/ICBXaGF0 J3MgaXRzIHByZWNpc2Ugc2VtYW50aWM/ICBJdCBhcHBlYXJzIHRvIHNheSBpcyBvbmx5IHRoYXQg dGhlIGNlcnRpZmllciBkb2VzIG5vdCB0cnVzdCB0aGUgaG9sZGVyIG9mIHRoYXQgY2VydGlmaWVk IGtleSB0byBvcGVyYXRlIGFzIGFuIGF1dGhvcml0YXRpdmUgY2VydGlmaWVyIHdpdGhpbiBpdHMg b3duIGJ1c2luZXNzIGRvbWFpbiAgVGhhdCBpcywgdGhlIENBIGRvZXNuJ3QgdHJ1c3QgdGhlIHBl cnNvbiBmb3IgYW55dGhpbmcgYXQgYWxsIG90aGVyIHRoYW4gcmVzcG9uc2libHkgbWFuYWdpbmcg aXRzIG93biBwcml2YXRlIGtleS4NCg0KVGhlIHdheSB0aGUgTVVTVCAoUkZDNTI4MDogNC4yLjEu MTAsIOKAnFRoZSBuYW1lIGNvbnN0cmFpbnRzIGV4dGVuc2lvbiwgd2hpY2ggTVVTVCBiZSB1c2Vk IG9ubHkgaW4gYSBDQSBjZXJ0aWZpY2F0ZVsuLi5d4oCdKSBpcyBzdHJ1Y3R1cmVkLCBpdCBjYW5u b3QgYmUgdXNlZCB0byBiaW5kIGEgcHVibGljIGtleSB0byBhdXRob3JpdHkgdG8gdXNlIGFuZCBp c3N1ZSBjZXJ0aWZpY2F0ZXMgaW4gaXRzIG93biBkb21haW5zLiAgSXQgbWFrZXMgbm8gc2Vuc2Ug dGhhdCB0aGUgaG9sZGVyIG9mIHRoZSBjZXJ0aWZpZWQga2V5IGhhcyBubyBhdXRvbm9teTsgb3Ro ZXJ3aXNlLCB0aGVyZSdkIGJlIG5vIG5lZWQgZm9yIHRoZSBjZXJ0aWZpY2F0ZS4gIEl0IGlzIHBv b3IgcG9saWN5IGVuY29kZWQgaW50byBhIHRlY2huaWNhbCBzdGFuZGFyZCB3aGljaCBpcyBhY3Rp dmVseSBoYXJtaW5nIHVzZWZ1bCBhcHBsaWNhdGlvbi4NCg0KWyBtb3JlIG9uIHRoaXMgYWZ0ZXIg c2lnbmF0dXJlIF0NCg0KQXMgZm9yIHRob3NlIHdobyBiZW1vYW4gdGhlIGxhY2sgb2YgdHJ1c3Rl ZCBzdG9yYWdlOiB3ZSdsbCBuZXZlciBoYXZlIGl0IHVudGlsIHdlIGFjdHVhbGx5IGhhdmUgYSBy ZWFzb24gdG8ga2VlcCB0aGluZ3Mgc2VjdXJlLg0KDQo+IEkgdGhpbmsgdGhhdCB0aGVyZSBzaG91 bGQgYmUgYSBtYW5kYXRvcnkgdG8gc3VwcG9ydCBUQSBmb3JtYXQgZm9yIFBLSVgsDQo+IGFuZCB0 aGF0IHNob3VsZCBiZSBYLjUwOS4NCg0KVGhlcmUgYXJlIGFkZGl0aW9uYWwgd2F5cyB0aGF0IHRy dXN0IGFuY2hvcnMgY2FuIGJlIGVuY29kZWQsIHN1Y2ggYXMgT3BlblBHUC4gIEknbSBhbHNvIHdh cnkgb2YgTVVTVC1lbmNvZGluZyBwb2xpY2llcyBpbnRvIHRlY2huaWNhbCBzdGFuZGFyZHMsIGFz IEkgc3VnZ2VzdCBhYm92ZS4NCg0KWW91IGNhbid0IGtub3cgd2hhdCB0aGUgbmV4dCBnZW5lcmF0 aW9uIG9mIHByb3RvY29sIGltcHJvdmVtZW50cyBpcyBnb2luZyB0byBlbnRhaWwsIGFuZCBhZnRl ciAzIG9yIDQgaXRlcmF0aW9ucyBzdGlsbCBiZWluZyByZXF1aXJlZCB0byBzdXBwb3J0IHRoZSBs ZWdhY3kgWC41MDkgZm9ybWF0IHdoZW4gdGhlcmUgd2VyZSBhbHRlcm5hdGl2ZSwgcHJlZmVyYWJs ZSB3YXlzIG9mIGVuY29kaW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIGNvbW1vbiB1c2UuICAo YWxzbywgdGhlcmUncyB0aGUgY29uY2VwdCBvZiAiaG93IG11Y2ggYW5kIGZvciB3aGF0IGRvIHdl IGhhdmUgdG8gdHJ1c3QgdGhlIENBPyIgIEkgdGhpbmsgaXQncyAnYXV0aG9yaXRhdGl2ZSBpZGVu dGl0eScuKQ0KDQotS3lsZSBIDQoNClsgY29udGludWVkIGZyb20gYWJvdmUgXQ0KDQpUaGUgb25s eSB0aGluZyB0aGF0IGlzIHJlYWxseSBuZWNlc3NhcnkgaXMgdGhhdCB0aGUgYXV0aG9yaXRhdGl2 ZWx5LWhlbGQgaWRlbnRpdGllcyAodGhlIGNsYWltcyB0byBzdGF0ZS1oZWxkIGlkZW50aXRpZXMs IHN1Y2ggYXMgImxlZ2FsIG5hbWUiIGFuZCAiY2l0aXplbnNoaXAiIGFuZCAiZG9tYWluIG5hbWVz IikgYXJlIGNvcnJlY3RseSBhc3NlcnRlZCBieSBzb21lb25lIHRoZSByb290IGhhcyBkZWxlZ2F0 ZWQgcGVybWlzc2lvbiB0byBvcGVyYXRlIGFzIHBhcnQgb2YgaXRzIHRydXN0IGhpZXJhcmNoeS4g IEJyb3dzZXJzIGhhdmUgaW5maW5pdGVseSBtb3JlIHByb2Nlc3NpbmcgcG93ZXIgdGhhbiB3YXMg ZXZlciBjb250ZW1wbGF0ZWQgY291bGQgZXhpc3QgaW4gdGhlIGNpdmlsaWFuIHdvcmxkIChvbmNl LWV4cG9ydC1jb250cm9sbGVkIHN1cGVyY29tcHV0ZXJzIGluIGV2ZXJ5IGRlc2sgYW5kIGJyaWVm Y2FzZSwgbXVjaCBsZXNzIGluIGV2ZXJ5IHNlcnZlciksIGFuZCB3ZSBrbm93IHRoYXQgcGVvcGxl IHJlZnVzZSB0byB1c2UgdGhlaXIga2V5cyBhcyBzaW1wbGUsIHVuaXZlcnNhbCBwb2xpY2Utc3Rh dGUgZGV2aWNlcy4NCg0KT25jZSBlbmQtZW50aXRpZXMgc3RhcnQgZ2V0dGluZyB0aGF0IHBhcnRp Y3VsYXIgaGFwcGVucywgdGhlIEVWIGNlcnRpZmljYXRlIHRoYXQgZXZlcnkgbGFyZ2UgY29ycG9y YXRpb24gY3VycmVudGx5IGhhcyBjYW4gaGF2ZSBpdHMga2V5IHJlbW92ZWQgZnJvbSB0aGUgd2Vi c2VydmVyLCBhbmQgaXQgY2FuIGF1dGhvcml6ZSBpdHMgb3duIG1hY2hpbmVzIHdpdGggdXNlZnVs IGFuZCBjb3JyZWN0IGtleSBtYW5hZ2VtZW50IHN5c3RlbXMgKHN1Y2ggYXMgIjUtbWludXRlIHZh bGlkaXR5IGNlcnRpZmljYXRlcyB3aXRoIHJlZ3VsYXIgcmVrZXlpbmciKSBmaW5hbGx5IHB1dCBp biBwbGFjZS4gIFRoZSBwZXJzb24gaXMgY29ycmVjdGx5IGlkZW50aWZpZWQgKGFzIGl0IGNoYWlu cyBkb3duIGZyb20gdGhlIGlkZW50aXR5IGNlcnQpLCBhbmQgaXQgY2FuIGJlIHJlc3RyaWN0ZWQg dG8gb25seSBwZXJtaXR0aW5nIG9wZXJhdGlvbnMgdW5kZXIgYSBnaXZlbiBzZXQgb2YgZG9tYWlu cy4gIFRoaXMgcHJldmVudHMgZm9yZ2VyeSwgYW5kIGRvZXNuJ3QgcmVxdWlyZSB1cyB0byBiZSB3 YXJ5IG9mIGlzc3VpbmcgdW5yZXN0cmljdGVkIENBIGNlcnRpZmljYXRlcyB0byBjb3Jwb3JhdGlv bnMuDQoNCkFsc28sIGNvcnBvcmF0aW9ucyBoYXZlIGFuIGludGVyZXN0IGluIHJlZHVjaW5nIHRo ZSBleHBvc3VyZSBvZiB0aGVpciBlbXBsb3llZXMgZnJvbSBoYXJhc3NtZW50LiAgVGhpcyBzdWdn ZXN0cyB0aGF0IHRoZXkgc2hvdWxkIGJlIGFibGUgdG8gaXNzdWUgdGhlaXIgb3duIGNlcnRpZmlj YXRlcyAtLSBub3QgYXMgInRydXN0ZWQgdG8gcHJvdmlkZSBhdXRob3JpdGF0aXZlIGluZm9ybWF0 aW9uIiwgYnV0IGFzICJ0cnVzdGVkIHRvIGJlIGFibGUgdG8gcGVyZm9ybSBpbnRlcm5hbCBnb3Zl cm5hbmNlIGFuZCBwcmV2ZW50IGNlcnRpZmljYXRlcyBmcm9tIGJlaW5nIGlzc3VlZCB0byBub24t YWZmaWxpYXRlZCBlbnRpdGllcyIuICBUaGUgY29ycG9yYXRpb24ga25vd3Mgd2hvIGFuZCB3aGF0 IGl0IGlzc3VlZCB0aGUgY2VydGlmaWNhdGUgdG8gKGl0IGtlZXBzIGxvZ3MpLCBhbmQgaXQgY2Fu IG1haW50YWluIHRoYXQga2V5IHdpdGggdGhlIHNlY3VyaXR5IHRyYWRpdGlvbmFsbHkgYWZmb3Jk ZWQgdGhlIGNvcnBvcmF0ZSBzZWFsIC0tIG9yIG5vdCwgYXMgaXRzIG5lZWRzIGRpY3RhdGUuICBU aGUga2V5IGFuZCBjZXJ0aWZpY2F0ZSBhcmUgYXNzZXRzIG9mIHRoZSBjb21wYW55LCBhbmQgdGhl IGNvbXBhbnkgd2lsbCB0YWtlIHJlYXNvbmFibGUgZWZmb3J0cyB0byBwcm90ZWN0IGl0cyBpZGVu dGl0eSAtLSBjZXJ0YWlubHkgbW9yZS1yZWFzb25hYmxlIHRoYW4gImFuIEVWIGtleSBvbiBldmVy eSB3ZWJzZXJ2ZXIgd2l0aCBsb25nLXRlcm0gY2VydGlmaWNhdGVzIiwgd2hpY2ggaXMgd2hhdCBj dXJyZW50bHkgZXhpc3RzLg0KDQpJbiBhZGRpdGlvbiwgd2Uga25vdyB0aGF0IGFwcGxpY2F0aW9u IHZlbmRvcnMgYW5kIENBcyB3aWxsIG1vdmUgdG8gY291bnRlciBpZGVudGlmaWVkIHNlY3VyaXR5 IGlzc3Vlcy4gIEFzIGV2aWRlbmNlLCB3ZSBoYXZlIHRoZSBFViBjZXJ0aWZpY2F0ZTogY3JlYXRl ZCBhcyBhIHdheSB0byBzdHJvbmdseSBpZGVudGlmeSBwYXJ0aWN1bGFyIGhpZ2gtdm9sdW1lIHNp dGVzLCB0byBwcmV2ZW50IEROUyBoaWphY2tpbmcgYXR0YWNrcyBmcm9tIGJlaW5nIHVzZWQgd2l0 aCBhIGNvcnJ1cHQgQ0EgdG8gc3RlYWwgbGFyZ2UgbnVtYmVycyBvZiB0cmFuc2FjdGlvbnMuICBU aGlzIHNwZWNpZmljYXRpb24gd2FzIGNyZWF0ZWQgYnkgdGhlICJDQS9Ccm93c2VyIEZvcnVtIiwg d2hpY2ggc3BlY2lmaWVkIHdoYXQgdGhlIENBIGhhZCB0byBkbyBhbmQgd2hhdCBzdGFuZGFyZHMg aXQgaGFkIHRvIG1lZXQgdG8gYmUgZ2l2ZW4gZ3JlZW4tYmFyIHRyZWF0bWVudCBieSB0aGUgYnJv d3NlcnMuDQoNCldlJ3ZlIGJlZW4gYXNzdW1pbmcgdGhhdCB0aGUgdXNlciBjYW4gbmV2ZXIgYmUg dGF1Z2h0IHRvIHRha2UgZ29vZCBjb250cm9sIG9mIGhpcyBpZGVudGl0eSwgbXVjaCBsZXNzIGhp cyBwcml2YWN5LiAgSSdtIGNvbnZpbmNlZCB0aGF0IHRoZSB1c2VyIG5ldmVyIHdpbGwgdW50aWwg aGUgaGFzIGdvb2QgdG9vbHMgdG8gZG8gc28uDQoNClBsZWFzZSwgY2FuIHdlIGdldCByaWQgb2Yg dGhlIE1VU1RzIHdoaWNoIHByZXZlbnQgdGhpbmdzIGZyb20gYmVpbmcgdXNlZCBkaWZmZXJlbnRs eSB0aGFuIHRoZXkgY3VycmVudGx5IGFyZT8= --gmsm1.8.1eqgqc2dv80lkbmqenh7a2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINAjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGxjCCBa6g AwIBAgICCMUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNzE5MDFaFw0xMjA2MDUyMDMxMzFaMIHAMSAwHgYDVQQNExcyMDc2MDUtQzh5TUxvb3ll VE85NFFKeDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xIDAeBgkqhkiG9w0BCQEWEWt5YW5oYUBreWFuaGEubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5YylxEUtOSlqBT0sxqB7H0YUDx30ADzggTrSLA9n JVa0QCcIXhk04n7VUD5Augbc40rWhgmB8xl6N9pQ5qvAQZj8JmNej6LRlueN/et9MCjNN0euH0Ky zzKBSE5fxoUPYTTa6QBBurmKNR0navAKWBi8ITLRPi864zTay2oW1A1E1nt69SgJGn3PAv/LyKII WWMzu9YeJsRCd4u6vLHOsGHvr5rc7Dq4bXx8x+vyHgSuYccAnNu81lOC2Unea4TORMoULiwKOTRb pEy35H9Y7MW+SCTlaQiSLgxvYB260OuofHZgcS0wr/OnbGVAEUeBRYhfu3BaxNlZ6zY7mvs9NwID AQABo4IC+jCCAvYwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBThUNrymHVQVA3i/K/6BF4dnrmTqDAfBgNVHSMEGDAWgBSuVYNv 7DHKufcd+q9rMfPIHeOsuzAcBgNVHREEFTATgRFreWFuaGFAa3lhbmhhLm5ldDCCAUIGA1UdIASC ATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9p bnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFM aW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9v Y3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDov L3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAjquLhQpUqqxo pg1hbv8zADjhTUY1Gxm1Ha/5Ntdjds7HZ54jOqD2fVwWRbqLAtq+rwHIaudvk13icftTedJlV01r +6VjmOZhSwOPPiYG/v81ABitv8bfyOkei/3BblORXOyzwuXHrbmMOgaEcCmQmqyTo1UJiNMy5Tw0 CvDt+KbSbGP2lQL8BAGyLhswuGePoReqw221KsX6sZJ4Eovk70SlNN19YiRAFYdWL+ggY5mMPn9S qXk8GGLaOyg3g2HnVr7Y4MLYfI0pheoRvoGxj8a4xofTz3u6OlGYE/3D5/uLQbw/rTz6GVVgUFPi GFSKZjzXwfEYJ3Kd1BMXCyfE6zGCAnwwggJ4AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAgjFMAkGBSsOAwIaBQCggb4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTEwNzIwMDkwMjQ2WjAjBgkqhkiG9w0BCQQxFgQUJcSS5EwiRsnYS6EUr6wPJgZY wMUwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIIBAEqQFM4xOrwXBTw4k2KMbTaIhV43arhA9USIdjA0LKIWlAo1412rjD1wvr4MmXsg1esS9I3L c6gB5GmeIt+2FiQnUVuIIUbnmQTvoI2hxndntR6isXsWTG48c99TGXBiKK5aplTuVQb3oyKrHThG 09yvG9KJahagTXDuX2GaEp38PlGsalZx2qhz8eg2wzgiiDmGvZ/eIKg9pIXfffTZtjLBUuJpV6S2 NEWYZtJ1+/31It+D584I5uWj1sDoAd0wRjw6EJfG433CIttXvLI3Md60vOGh4epaq+3czTPUFJTC O876dcOeXevRQS+r+4yND/uZobnu1D3h7uzXCFfYLtUAAAAAAAA= --gmsm1.8.1eqgqc2dv80lkbmqenh7a2-- From turners@ieca.com Wed Jul 20 19:38:44 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CA321F8B0E for ; Wed, 20 Jul 2011 19:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9GQUo3t7W1x for ; Wed, 20 Jul 2011 19:38:44 -0700 (PDT) Received: from nm29.access.bullet.mail.mud.yahoo.com (nm29.access.bullet.mail.mud.yahoo.com [66.94.237.94]) by ietfa.amsl.com (Postfix) with SMTP id 4D42821F8AF1 for ; Wed, 20 Jul 2011 19:38:36 -0700 (PDT) Received: from [66.94.237.126] by nm29.access.bullet.mail.mud.yahoo.com with NNFMP; 21 Jul 2011 02:38:30 -0000 Received: from [98.139.221.62] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 21 Jul 2011 02:38:30 -0000 Received: from [127.0.0.1] by smtp103.biz.mail.bf1.yahoo.com with NNFMP; 21 Jul 2011 02:38:30 -0000 X-Yahoo-Newman-Id: 492197.54575.bm@smtp103.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: NuSy.jYVM1kCAQDMEkIWNgHpGWxEmtlsVH9dLMcgOPNdVnr mJCTvmEn5LFAWYGK.ksoLRmZuKz.P7DV1JuTm4XTWMzBz44WGJFroXZmmQB5 EQGZVF2jjYvVVLb_jzJestTjTc0STio.vrHeJUW_Um0kagwyEHgwgHh1aYHE GPLO.tijYPuSjhHtFMvhq47Dl3xpBqGgKMjjSZ8Ha.RglcVvkaExrizCESLd W9rcnNx1dGbG22VjZE3AY50Dkty0vpjlQ1oAxhDn.W_g5Kak7jGByIHPK.1w 0x1gPzGiQbZnGQb0XO2E7MnW3tUqbIzEIiyGYIn2WUAyQDzoOHUj4pyPqRX6 Fk7gfZYxK4RJOm9QMeLt9KQ-- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@96.231.123.29 with plain) by smtp103.biz.mail.bf1.yahoo.com with SMTP; 20 Jul 2011 19:38:30 -0700 PDT Message-ID: <4E27754C.8050407@ieca.com> Date: Wed, 20 Jul 2011 20:39:40 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: pkix@ietf.org References: <20110702150314.6924.99292.idtracker@ietfa.amsl.com> In-Reply-To: <20110702150314.6924.99292.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pkix] Fwd: I-D Action: draft-turner-pkix-cmc-serverkeygeneration-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 02:38:44 -0000 Some in the WG might find this draft interesting. spt -------- Original Message -------- Subject: I-D Action: draft-turner-pkix-cmc-serverkeygeneration-00.txt Date: Sat, 02 Jul 2011 08:03:14 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CMC Extensions: Server Key Generation Author(s) : Jim Schaad Sean Turner Paul Timmel Filename : draft-turner-pkix-cmc-serverkeygeneration-00.txt Pages : 23 Date : 2011-07-02 This document defines a set of extensions to the Certificate Management over CMS (CMC) protocol that addresses the desire to support server-side generation of keys. This service is provided by the definition of additional control statements within the CMC architecture. Additional CMC errors are also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-pkix-cmc-serverkeygeneration-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-turner-pkix-cmc-serverkeygeneration-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From pritikin@cisco.com Thu Jul 21 15:03:36 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6549821F8A1A for ; Thu, 21 Jul 2011 15:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhpOtgdVxzNH for ; Thu, 21 Jul 2011 15:03:35 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id AC64D21F8782 for ; Thu, 21 Jul 2011 15:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=2582; q=dns/txt; s=iport; t=1311285815; x=1312495415; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=mFsNChfTYOnzqd9A+q1AnSvbcMNYw070TTlnQC9Uzdc=; b=b2yJ9YgoFIEFm6TDmMSn5WzrSKP8gi4oEKXa5Rd7NwlZLwtNtH1z8Mtq KdqFpsT7LPo4fHxJgNQRKkyJGzsMARkWCycoAgDvoR/DqfLUVVFYi2USG mX93URp2pJKHUAWQ9BAM/29EnG1S5iDjLFiyYLB8i4Cd+Ak14J+ljst8O A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcHABehKE6rRDoG/2dsb2JhbABTmDaPDHeIfJ0VniCFYF8Eh1WLGZB9 X-IronPort-AV: E=Sophos;i="4.67,244,1309737600"; d="scan'208";a="5279468" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-9.cisco.com with ESMTP; 21 Jul 2011 22:03:35 +0000 Received: from dhcp-10-129-4-192.cisco.com (dhcp-10-129-4-192.cisco.com [10.129.4.192]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6LM3YHV010334 for ; Thu, 21 Jul 2011 22:03:34 GMT From: Max Pritikin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jul 2011 16:03:34 -0600 References: <20110711215020.13718.96766.idtracker@ietfa.amsl.com> To: pkix@ietf.org Message-Id: <5E0BAA2F-C9A0-4D5D-A72D-47044AD17677@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [pkix] Fwd: New Version Notification for draft-pritikin-est-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 22:03:36 -0000 Folks, I very much appreciate the time and comments received from folks on this = list concerning earlier versions. Although I'm sure all issues have not = yet been addressed I think this version of the document is a step = forward. I'll be in Quebec City for the first couple days and look = forward to further feedback during the monday session. This version is slightly restructured to make the concepts clearer and I = recommend at least skimming the introduction and reading the = table-of-contents. In particular Figure 1 should help orient new = readers.=20 draft-pritikin-est-02: > Abstract >=20 > This document specifies a protocol for certificate Enrollment over > Secure Transport (EST). EST is a certificate enrollment protocol > that operates over HTTPS, and thus should be trivially accessible = by > modern clients. The Certificate Management over CMS (CMC) "Simple > PKI Request" and "Simple PKI Response" messages are leveraged. EST > is designed to be easily implemented by clients and servers running > other common enrollment mechanisms such as Simple Certificate > Enrollment Protocol (SCEP). Renewal and rekey mechanisms are > described consistent with Certificate Management Protocol (CMP). Thanks, - max Begin forwarded message: > From: internet-drafts@ietf.org > Date: July 11, 2011 3:50:20 PM MDT > To: pritikin@cisco.com > Cc: pritikin@cisco.com > Subject: New Version Notification for draft-pritikin-est-02.txt >=20 > A new version of I-D, draft-pritikin-est-02.txt has been successfully = submitted by Max Pritikin and posted to the IETF repository. >=20 > Filename: draft-pritikin-est > Revision: 02 > Title: Enrollment over Secure Transport > Creation date: 2011-07-11 > WG ID: Individual Submission > Number of pages: 25 >=20 > Abstract: > This document specifies a protocol for certificate Enrollment over > Secure Transport (EST). EST is a certificate enrollment protocol > that operates over HTTPS, and thus should be trivially accessible by > modern clients. The Certificate Management over CMS (CMC) = "Simple > PKI Request" and "Simple PKI Response" messages are = leveraged. EST > is designed to be easily implemented by clients and servers running > other common enrollment mechanisms such as Simple Certificate > Enrollment Protocol (SCEP). Renewal and rekey mechanisms are > described consistent with Certificate Management Protocol (CMP). >=20 >=20 >=20 >=20 > The IETF Secretariat From anders.rundgren@telia.com Thu Jul 21 15:57:59 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341C421F8906 for ; Thu, 21 Jul 2011 15:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVR2rUVjWFmq for ; Thu, 21 Jul 2011 15:57:58 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 5189621F88A5 for ; Thu, 21 Jul 2011 15:57:58 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F0072A477; Fri, 22 Jul 2011 00:57:54 +0200 Message-ID: <4E28AEEA.2080601@telia.com> Date: Fri, 22 Jul 2011 00:57:46 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Max Pritikin References: <20110711215020.13718.96766.idtracker@ietfa.amsl.com> <5E0BAA2F-C9A0-4D5D-A72D-47044AD17677@cisco.com> In-Reply-To: <5E0BAA2F-C9A0-4D5D-A72D-47044AD17677@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] New Version Notification for draft-pritikin-est-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 22:57:59 -0000 Max, I won't bother you more. I just wanted to say I'm unconvinced that a new enrollment protocol that does not - have browser bindings like Apple's iPhone SCEP - support container-based sessions - provide key attribute data like PINs is what the market is waiting on. I still wish you good luck! Anders On 2011-07-22 00:03, Max Pritikin wrote: > > Folks, > > I very much appreciate the time and comments received from folks on this list concerning earlier versions. Although I'm sure all issues have not yet been addressed I think this version of the document is a step forward. I'll be in Quebec City for the first couple days and look forward to further feedback during the monday session. > > This version is slightly restructured to make the concepts clearer and I recommend at least skimming the introduction and reading the table-of-contents. In particular Figure 1 should help orient new readers. > > draft-pritikin-est-02: >> Abstract >> >> This document specifies a protocol for certificate Enrollment over >> Secure Transport (EST). EST is a certificate enrollment protocol >> that operates over HTTPS, and thus should be trivially accessible by >> modern clients. The Certificate Management over CMS (CMC) "Simple >> PKI Request" and "Simple PKI Response" messages are leveraged. EST >> is designed to be easily implemented by clients and servers running >> other common enrollment mechanisms such as Simple Certificate >> Enrollment Protocol (SCEP). Renewal and rekey mechanisms are >> described consistent with Certificate Management Protocol (CMP). > > > Thanks, > > - max > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Date: July 11, 2011 3:50:20 PM MDT >> To: pritikin@cisco.com >> Cc: pritikin@cisco.com >> Subject: New Version Notification for draft-pritikin-est-02.txt >> >> A new version of I-D, draft-pritikin-est-02.txt has been successfully submitted by Max Pritikin and posted to the IETF repository. >> >> Filename: draft-pritikin-est >> Revision: 02 >> Title: Enrollment over Secure Transport >> Creation date: 2011-07-11 >> WG ID: Individual Submission >> Number of pages: 25 >> >> Abstract: >> This document specifies a protocol for certificate Enrollment over >> Secure Transport (EST). EST is a certificate enrollment protocol >> that operates over HTTPS, and thus should be trivially accessible by >> modern clients. The Certificate Management over CMS (CMC) "Simple >> PKI Request" and "Simple PKI Response" messages are leveraged. EST >> is designed to be easily implemented by clients and servers running >> other common enrollment mechanisms such as Simple Certificate >> Enrollment Protocol (SCEP). Renewal and rekey mechanisms are >> described consistent with Certificate Management Protocol (CMP). >> >> >> >> >> The IETF Secretariat > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From era@x500.eu Fri Jul 22 09:10:30 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF01821F8B5E for ; Fri, 22 Jul 2011 09:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.053 X-Spam-Level: * X-Spam-Status: No, score=1.053 tagged_above=-999 required=5 tests=[AWL=-1.961, BAYES_50=0.001, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, TRACKER_ID=2.003] 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 5zGNUcx96n22 for ; Fri, 22 Jul 2011 09:10:30 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 810D921F8B5F for ; Fri, 22 Jul 2011 09:10:28 -0700 (PDT) Received: from Morten ([79.138.247.32]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id FXF63556; Fri, 22 Jul 2011 18:09:56 +0200 From: "Erik Andersen" To: "Directory list" , "SG17-Q11" , "PKIX" Date: Fri, 22 Jul 2011 18:09:59 +0200 Message-ID: <001101cc4889$d20cb7b0$76262710$@eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01CC489A.959587B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxIic3taBCUjlsDSo2gu50amw3zcw== Content-Language: da Subject: [pkix] ForwardCertificationPath 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, 22 Jul 2011 16:10:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0012_01CC489A.959587B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Somewhere in clause 7 of X.509 we have the following ASN.1 with very little explanatory text. Can anyone explain the following: In addition, the following ASN.1 data type can be used to represent the forward certification path. This component contains the certification path which can point back to the originator. ForwardCertificationPath ::= SEQUENCE OF CrossCertificates CrossCertificates ::= SET OF Certificate In particular, why is it Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik ------=_NextPart_000_0012_01CC489A.959587B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Somewhere = in clause 7 of X.509 we have the following ASN.1 with very little = explanatory text. Can anyone explain the following:

 

In addition, = the following ASN.1 data type can be used to represent the forward = certification path. This component contains the certification path which = can point back to the originator.

 

ForwardCertificationPath  ::=3D  SEQUENCE OF = CrossCertificates

 

CrossCertificates  ::=3D  SET OF = Certificate

 

In particular, why is it  

 

Erik = Andersen

Andersen's = L-Service

Elsevej = 48,

DK-3500 = Vaerloese

Denmark=

Mobile: +45 2097 = 1490

e-amail: era@x500.eu

Skype: = andersen-erik

http://www.x500.eu/

http://www.x500standard.com/

http://dk.linkedin.com/in/andersenerik

 

------=_NextPart_000_0012_01CC489A.959587B0-- From era@x500.eu Fri Jul 22 09:11:16 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B478F21F8514 for ; Fri, 22 Jul 2011 09:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.333 X-Spam-Level: * X-Spam-Status: No, score=1.333 tagged_above=-999 required=5 tests=[AWL=-1.681, BAYES_50=0.001, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, TRACKER_ID=2.003] 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 LgidpVDzKzg1 for ; Fri, 22 Jul 2011 09:11:16 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 647BF21F8B72 for ; Fri, 22 Jul 2011 09:11:02 -0700 (PDT) Received: from Morten ([79.138.247.32]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id FXH52100; Fri, 22 Jul 2011 18:11:00 +0200 From: "Erik Andersen" To: "Directory list" , "SG17-Q11" , "PKIX" Date: Fri, 22 Jul 2011 18:11:02 +0200 Message-ID: <001601cc4889$f81818f0$e8484ad0$@eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01CC489A.BBA0E8F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxIic3taBCUjlsDSo2gu50amw3zcw== Content-Language: da Subject: [pkix] ForwardCertificationPath 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, 22 Jul 2011 16:11:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0017_01CC489A.BBA0E8F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Somewhere in clause 7 of X.509 we have the following ASN.1 with very little explanatory text. Can anyone explain the following: In addition, the following ASN.1 data type can be used to represent the forward certification path. This component contains the certification path which can point back to the originator. ForwardCertificationPath ::= SEQUENCE OF CrossCertificates CrossCertificates ::= SET OF Certificate In particular, why is it Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik ------=_NextPart_000_0017_01CC489A.BBA0E8F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Somewhere = in clause 7 of X.509 we have the following ASN.1 with very little = explanatory text. Can anyone explain the following:

 

In addition, = the following ASN.1 data type can be used to represent the forward = certification path. This component contains the certification path which = can point back to the originator.

 

ForwardCertificationPath  ::=3D  SEQUENCE OF = CrossCertificates

 

CrossCertificates  ::=3D  SET OF = Certificate

 

In particular, why is it  

 

Erik = Andersen

Andersen's = L-Service

Elsevej = 48,

DK-3500 = Vaerloese

Denmark=

Mobile: +45 2097 = 1490

e-amail: era@x500.eu

Skype: = andersen-erik

http://www.x500.eu/

http://www.x500standard.com/

http://dk.linkedin.com/in/andersenerik

 

------=_NextPart_000_0017_01CC489A.BBA0E8F0-- From era@x500.eu Fri Jul 22 09:12:19 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4CD21F8B83 for ; Fri, 22 Jul 2011 09:12:19 -0700 (PDT) X-Quarantine-ID: X-Amavis-Modified: Mail body modified (defanged) by ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: 2.15 X-Spam-Level: ** X-Spam-Status: No, score=2.15 tagged_above=-999 required=5 tests=[AWL=-2.078, BAYES_60=1, HELO_EQ_DK=1.009, TVD_SPACE_RATIO=2.219] 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 ES6TNbFlX7q9 for ; Fri, 22 Jul 2011 09:12:18 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1311351139-30319-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id DAC0021F8B61 for ; Fri, 22 Jul 2011 09:12:17 -0700 (PDT) Received: from Morten ([79.138.247.32]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id FXI74016; Fri, 22 Jul 2011 18:12:16 +0200 From: "Erik Andersen" To: "Directory list" , "SG17-Q11" , "PKIX" Date: Fri, 22 Jul 2011 18:12:21 +0200 Message-ID: X-Mailer: Microsoft Office Outlook 12.0 Subject: [pkix] Tilbagekaldelse: ForwardCertificationPath 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, 22 Jul 2011 16:12:19 -0000 This is a multi-part message in MIME format... ------------=_1311351139-30319-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1311351139-30319-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Return-Path: Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id DAC0021F8B61 for ; Fri, 22 Jul 2011 09:12:17 -0700 (PDT) Received: from Morten ([79.138.247.32]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id FXI74016; Fri, 22 Jul 2011 18:12:16 +0200 From: "Erik Andersen" To: "Directory list" , "SG17-Q11" , "PKIX" Subject: Tilbagekaldelse: ForwardCertificationPath Date: Fri, 22 Jul 2011 18:12:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0024_01CC489A.E9156A40" X-Mailer: Microsoft Office Outlook 12.0 Expiry-Date: Sun, 24 Jul 2011 18:12:20 +0200 X-MS-TNEF-Correlator: 000000002739104FF199A74C8B8EEAD76E769022248F2B00 This is a multi-part message in MIME format. ------=_NextPart_000_0024_01CC489A.E9156A40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Erik Andersen vil gerne tilbagekalde meddelelsen "ForwardCertificationPath". ------=_NextPart_000_0024_01CC489A.E9156A40 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IhkQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAEwAAAElQTS5PdXRs b29rLlJlY2FsbACCBgEDkAYAzAMAABgAAAADACYAAQAAAAIBMQABAAAAKAEAAFBDREZFQjA5AAEA AgCqAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4A AAAAQwA6AFwAVQBzAGUAcgBzAFwARQByAGkAawBcAEEAcABwAEQAYQB0AGEAXABMAG8AYwBhAGwA XABNAGkAYwByAG8AcwBvAGYAdABcAE8AdQB0AGwAbwBvAGsAXABPAHUAdABsAG8AbwBrAC4AcABz AHQAAAAYAAAAAAAAACc5EE/xmadMi47q1252kCLCgAAAGAAAAAAAAAAnORBP8ZmnTIuO6tdudpAi pI4rAAAAAAAQAAAAdwUu8tnxX0+GeQzd48acnRkAAABGb3J3YXJkQ2VydGlmaWNhdGlvblBhdGgA CwABDgEAAAADABQOAQAAAAIBAGgBAAAAEAAAAHcFLvLZ8V9PhnkM3ePGnJ0DAAFoAQAAAB4AAmgB AAAACQAAAElQTS5Ob3RlAAAAAAsAA2gBAAAAAwAEaAAAAAADAJiACCAGAAAAAADAAAAAAAAARgAA AAAahQAAAQAAAAsAHw4BAAAAAgH4DwEAAAAQAAAAJzkQT/GZp0yLjurXbnaQIgIB+g8BAAAAEAAA ACc5EE/xmadMi47q1252kCIDAP4PBQAAAAIBCRABAAAA2QAAANUAAABbAQAATFpGdeVqd0EDAAoA cmNwZzEyNSIyA0N0ZXgFQmJp/mQEAAMwAQMB9wqAAqQD5P8HEwKAEHMAUARWCFUHshGlJw5RAwEC AGNoCsBzZdx0MgYABsMRpTMERhQ33jASrBGzCO8J9zsYnw4wdjURogxgYwBQCwkBZDOmNhbQC6Yg RQUQaxFArm4EgRSQA6B2AxFnBJFIZSB0AxBiYR6Qa6sHQAEAIAeAZAEAbCAAqR4SIkYFsHcLEUME kLUe8GYN4GEe8AIgUCGAWGgiLgqiCoB9IqAAAAADAA00/T+lBgMADzT9P6UGAgEUNAEAAAAQAAAA TklUQfm/uAEAqgA32W4AAAIBfwABAAAAMQAAADAwMDAwMDAwMjczOTEwNEZGMTk5QTc0QzhCOEVF QUQ3NkU3NjkwMjIyNDhGMkIwMAAAAAADAAYQUA+SGgMABxBFAAAAAwAQEAAAAAADABEQAQAAAB4A CBABAAAARgAAAEVSSUtBTkRFUlNFTlZJTEdFUk5FVElMQkFHRUtBTERFTUVEREVMRUxTRU4iRk9S V0FSRENFUlRJRklDQVRJT05QQVRIIgAAAN/a ------=_NextPart_000_0024_01CC489A.E9156A40-- ------------=_1311351139-30319-1-- From era@x500.eu Fri Jul 22 09:14:10 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169D121F8B86 for ; Fri, 22 Jul 2011 09:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.774 X-Spam-Level: * X-Spam-Status: No, score=1.774 tagged_above=-999 required=5 tests=[AWL=-1.240, BAYES_50=0.001, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, TRACKER_ID=2.003] 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 zQ9h-2Qz0KZE for ; Fri, 22 Jul 2011 09:14:09 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id AB5E521F8B88 for ; Fri, 22 Jul 2011 09:14:01 -0700 (PDT) Received: from Morten ([79.138.247.32]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id FXK44500; Fri, 22 Jul 2011 18:14:00 +0200 From: "Erik Andersen" To: "Directory list" , "SG17-Q11" , "PKIX" Date: Fri, 22 Jul 2011 18:14:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01CC489B.26E11E00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxIic3taBCUjlsDSo2gu50amw3zcw== Content-Language: da Subject: [pkix] ForwardCertificationPath 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, 22 Jul 2011 16:14:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0027_01CC489B.26E11E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sorry for clumsy fingers. Somewhere in clause 7 of X.509 we have the following ASN.1 with very little explanatory text. Can anyone explain the following: In addition, the following ASN.1 data type can be used to represent the forward certification path. This component contains the certification path which can point back to the originator. ForwardCertificationPath ::= SEQUENCE OF CrossCertificates CrossCertificates ::= SET OF Certificate In particular, why is it a SET OF Certificate? Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik ------=_NextPart_000_0027_01CC489B.26E11E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry for = clumsy fingers.

 

Somewhere in = clause 7 of X.509 we have the following ASN.1 with very little = explanatory text. Can anyone explain the following:

 

In addition, = the following ASN.1 data type can be used to represent the forward = certification path. This component contains the certification path which = can point back to the originator.

 

ForwardCertificationPath  ::=3D  SEQUENCE OF = CrossCertificates

 

CrossCertificates  ::=3D  SET OF = Certificate

 

In particular, why is it a SET OF = Certificate? 

 

Erik = Andersen

Andersen's = L-Service

Elsevej = 48,

DK-3500 = Vaerloese

Denmark=

Mobile: +45 2097 = 1490

e-amail: era@x500.eu

Skype: = andersen-erik

http://www.x500.eu/

http://www.x500standard.com/

http://dk.linkedin.com/in/andersenerik

 

------=_NextPart_000_0027_01CC489B.26E11E00-- From anders.rundgren@telia.com Fri Jul 22 13:23:45 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A69C21F89A7 for ; Fri, 22 Jul 2011 13:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3H0UYADe9gzz for ; Fri, 22 Jul 2011 13:23:44 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3A63821F88A6 for ; Fri, 22 Jul 2011 13:23:44 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA034408BD for pkix@ietf.org; Fri, 22 Jul 2011 22:23:42 +0200 Message-ID: <4E29DC48.6060305@telia.com> Date: Fri, 22 Jul 2011 22:23:36 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "pkix@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Secure Credential Cloning 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, 22 Jul 2011 20:23:45 -0000 This posting is just an attempt keeping patent trolls away. The described concept is already in production use (in various variants), but hasn't been *publicly* documented AFAIK. Secure Credential Cloning ========================= There are quite a bunch of efforts based on having credentials in the cloud as well as "syncing" them to various devices. This fits a certain category of credentials. However, banks, governments, and enterprises are unlikely to buy into this concept for various rational and historical reasons. FWIW, the SKS/KeyGen2 scheme addresses credential mobility/accessibility in two different ways: - Through physical means (if using USB token form factor) - Through credential "cloning" Cloning is not to be confused with copying; it is a process when you get another *instance* of the same credential. Assume that you have a government- or bank-credential (presumably in an awkward container of their choice such as a regular smart card...), and that you would rather use your "iPhone" as credential carrier. If the issuer accepts your choice of credential carrier (typically listed on the issuer's site), you may login to the issuer using the original credential and get a new one for the target device. How can this be performed in a secure manner you may wonder? 1. The device has a device certificate which identifies the brand and ID to the issuer during the issuance process 2. During enroll the user specifies the SHA1 (or similar) of the device certificate so that the issuer is assured that it is talking to the right container Note: no enrollment passwords are needed! A further advantage with cloning is that in case you lose a credential it can be revoked while other instances of it are still usable making it a sort of a credential backup solution as well. Anders Rundgren http://webpki.org/auth-token-4-the-cloud.html From gardiner@bbn.com Fri Jul 22 14:21:47 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7315721F8AE4 for ; Fri, 22 Jul 2011 14:21:47 -0700 (PDT) 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 vzxRPMJ4JDSk for ; Fri, 22 Jul 2011 14:21:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 759E021F8AD3 for ; Fri, 22 Jul 2011 14:21:46 -0700 (PDT) Received: from [128.89.253.21] (port=1977 helo=gardiner-xp2.bbn.com) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QkNAC-000G6z-Bq; Fri, 22 Jul 2011 17:21:40 -0400 Message-Id: <6.2.1.2.2.20110722171911.02a8fc60@po2.bbn.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 22 Jul 2011 17:21:33 -0400 To: "Erik Andersen" , "Directory list" , "SG17-Q11" ,"PKIX" From: "Charles W. Gardiner" In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_101523609==.ALT" Subject: Re: [pkix] ForwardCertificationPath 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, 22 Jul 2011 21:21:47 -0000 --=====================_101523609==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:14 PM 7/22/2011, Erik Andersen wrote: >Content-Type: multipart/alternative; > boundary="----=_NextPart_000_0027_01CC489B.26E11E00" >Content-Language: da > >Sorry for clumsy fingers. > >Somewhere in clause 7 of X.509 we have the following ASN.1 with very >little explanatory text. Can anyone explain the following: > >In addition, the following ASN.1 data type can be used to represent the >forward certification path. This component contains the certification path >which can point back to the originator. > >ForwardCertificationPath ::= SEQUENCE OF CrossCertificates > >CrossCertificates ::= SET OF Certificate > >In particular, why is it a SET OF Certificate? To indicate they are all at the same level of the hierarchy? In a SEQUENCE the order is significant, but not in a SET. Charlie Gardiner > > >Erik Andersen >Andersen's L-Service >Elsevej 48, >DK-3500 Vaerloese >Denmark >Mobile: +45 2097 1490 >e-amail: era@x500.eu >Skype: andersen-erik >http://www.x500.eu/ >http://www.x500standard.com/ >http://dk.linkedin.com/in/andersenerik > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix --=====================_101523609==.ALT Content-Type: text/html; charset="us-ascii" At 12:14 PM 7/22/2011, Erik Andersen wrote:
Content-Type: multipart/alternative;
         boundary="----=_NextPart_000_0027_01CC489B.26E11E00"
Content-Language: da

Sorry for clumsy fingers.
 
Somewhere in clause 7 of X.509 we have the following ASN.1 with very little explanatory text. Can anyone explain the following:
 
In addition, the following ASN.1 data type can be used to represent the forward certification path. This component contains the certification path which can point back to the originator.
 
ForwardCertificationPath  ::=  SEQUENCE OF CrossCertificates
 
CrossCertificates  ::=  SET OF Certificate
 
In particular, why is it a SET OF Certificate?

    To indicate they are all at the same level of the hierarchy?  In a SEQUENCE the order is significant, but not in a SET.

Charlie Gardiner

 
 
Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: era@x500.eu
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/
http://dk.linkedin.com/in/andersenerik
 
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=====================_101523609==.ALT-- From DPKemp@missi.ncsc.mil Fri Jul 22 14:24:54 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E3921F8B1C for ; Fri, 22 Jul 2011 14:24:54 -0700 (PDT) X-Quarantine-ID: X-Amavis-Modified: Mail body modified (defanged) by ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat 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 ktE7VP9xUthQ for ; Fri, 22 Jul 2011 14:24:52 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1311369893-23253-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9C86A21F8AFB for ; Fri, 22 Jul 2011 14:24:52 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p6MLOmbO096692 for ; Fri, 22 Jul 2011 17:24:48 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jul 2011 17:24:54 -0400 Date: Fri, 22 Jul 2011 17:24:47 -0400 Message-ID: In-Reply-To: <4E29DC48.6060305@telia.com> References: <4E29DC48.6060305@telia.com> From: "Kemp, David P." To: Subject: Re: [pkix] Secure Credential Cloning 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, 22 Jul 2011 21:24:54 -0000 This is a multi-part message in MIME format... ------------=_1311369893-23253-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1311369893-23253-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Return-Path: Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9C86A21F8AFB for ; Fri, 22 Jul 2011 14:24:52 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p6MLOmbO096692 for ; Fri, 22 Jul 2011 17:24:48 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jul 2011 17:24:54 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC48B5.C8FB49FE" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [pkix] Secure Credential Cloning Date: Fri, 22 Jul 2011 17:24:47 -0400 Message-ID: In-Reply-To: <4E29DC48.6060305@telia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Secure Credential Cloning Thread-Index: AcxIrVJ6vDk7yTZPSx6GFuhiOwmjhgAA4vBA References: <4E29DC48.6060305@telia.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 22 Jul 2011 21:24:54.0328 (UTC) FILETIME=[CC732380:01CC48B5] This is a multi-part message in MIME format. ------_=_NextPart_001_01CC48B5.C8FB49FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I suppose an abundance of caution is warranted, given the number of dubious patents already issued, but isn't a method supposed to be non-obvious in order to be patentable? You are requesting issuance of a credential, using the subject's credential to authenticate the request. Is there anything novel about that idea? The new credential is NOT a clone; some fields MUST be different (serial number, validity, subject public key, signature), some fields MAY be different (issuer, extensions such as certificate policy and key usage), but presumably in your use case the subject DN and the subject alternative name extension MUST be copied from the authenticating cert to the new cert. If there are no other mechanisms used to authenticate the requestor, the assurance of the new credential will be less than the original. That is the same problem as with paper "breeder" credentials - if you can get the DMV to renew a forged/stolen driver's license, or get some other issuer to give you a new credential based on the license, then you have a way of bootstrapping a dodgy credential into a perfectly legitimate one. I wouldn't want a hacker to be able to misuse my smart card to get their cellphone provisioned with a legitimate credential containing my name, so the issuance method should have other safeguards. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Anders Rundgren Sent: Friday, July 22, 2011 4:24 PM To: pkix@ietf.org Subject: [pkix] Secure Credential Cloning This posting is just an attempt keeping patent trolls away. The described concept is already in production use (in various variants), but hasn't been *publicly* documented AFAIK. Secure Credential Cloning =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= There are quite a bunch of efforts based on having credentials in the cloud as well as "syncing" them to various devices. This fits a certain category of credentials. However, banks, governments, and enterprises are unlikely to buy into this concept for various rational and historical reasons. FWIW, the SKS/KeyGen2 scheme addresses credential mobility/accessibility in two different ways: - Through physical means (if using USB token form factor) - Through credential "cloning" Cloning is not to be confused with copying; it is a process when you get another *instance* of the same credential. Assume that you have a government- or bank-credential (presumably in an awkward container of their choice such as a regular smart card...), and that you would rather use your "iPhone" as credential carrier. If the issuer accepts your choice of credential carrier (typically listed on the issuer's site), you may login to the issuer using the original credential and get a new one for the target device. How can this be performed in a secure manner you may wonder? 1. The device has a device certificate which identifies the brand and ID to the issuer during the issuance process 2. During enroll the user specifies the SHA1 (or similar) of the device certificate so that the issuer is assured that it is talking to the right container Note: no enrollment passwords are needed! A further advantage with cloning is that in case you lose a credential it can be revoked while other instances of it are still usable making it a sort of a credential backup solution as well. Anders Rundgren http://webpki.org/auth-token-4-the-cloud.html _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------_=_NextPart_001_01CC48B5.C8FB49FE Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjEVAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAJQAAAFJFOiBbcGtpeF0gU2VjdXJl IENyZWRlbnRpYWwgQ2xvbmluZwDxDAEFgAMADgAAANsHBwAWABEAGAAvAAUAXAEBIIADAA4AAADb BwcAFgARABgAMAAFAF0BAQmAAQAhAAAAQUQ2QUY0QzhEMjVBRjY0MUExN0ZGNzVBQUI5MDEyOUYA bgcBA5AGAGQRAABGAAAACwACAAEAAAADACYAAAAAAAsAKwAAAAAAAwAuAAAAAAADADYAAAAAAEAA OQDgGnXItUjMAR4APQABAAAABQAAAFJFOiAAAAAAAgFHAAEAAAAzAAAAYz1VUzthPSA7cD1FeGNo YW5nZU5TQTtsPURBQkVDSy0xMTA3MjIyMTI0NDhaLTQxNDIAAB4AcAABAAAAIQAAAFtwa2l4XSBT ZWN1cmUgQ3JlZGVudGlhbCBDbG9uaW5nAAAAAAIBcQABAAAAGwAAAAHMSK1Serw5O8k2T0sehhbo YjsJo4YAAOLwQAAeABoMAQAAAA8AAABLZW1wLCBEYXZpZCBQLgAAHgAdDgEAAAAhAAAAW3BraXhd IFNlY3VyZSBDcmVkZW50aWFsIENsb25pbmcAAAAAAgEJEAEAAABACQAAPAkAABkQAABMWkZ1wyrj XgMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo 4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgSUAg c3VwcG8UECCjA5EBoHVuZABwYx1wAG9mIGNhdXRppQIgIAQAIHcKwHIAcIEOsGQsIGdpdgnwyCB0 aB1wbnUG0BKB0R5hZHViHtB1BCAKsB8OsAIwBCAHQBggYWR5Px8BHRAfsh3QBUAEAG4n+QVAYSAH gCBQBHAdBiRAHHRvIyAgcQIgLW9i/nYhYwuAHlALIBKBJPQhtHEBoGxlPwqiCoQKgFlXCGAdgBgg IBggcQpQc/kewG5nIqMeFiPQBQAJgH8h4QcxH9AhgCliIFIdEGLyagWQdCcEICqIJOIeoT8gYCrR HpAOsCBDKPUuIN8c4AQgIFEowQBweSBQKWL/JVAgEAMgAaAIYAVAIFAhwNMfAAEAYT8u8FQgYgfR 4yyJHxFOT1QqUhewMfAuOx0AA3AdcGYIkGxksQQgTVVTMzAlIWQGkOZmL2ECMCAoFBAHIiCFjR/Q dgdAMUBpdHkf0A8r5SGgIUA24GMga2UxNzJpZ24hwAhwZSnzN0Ez+kFZNO0iszaRDsH/CfAAkAIg BCAdEBPQHYAsYf8EkB7ANDAt4x1AOBEikABwZyRAOFErMWFnOSIjMnC/GCAdEADAAmAikQOgeQhh HysxHXAekB1hK6kgRE7/PhNBKgdADrAEoCHAIAEggN5hNAE7xzSXBaBwCJAkQP8DUiBDLWkpYjzy JOIgUzIC9T0BLie6SR5wL0UowSVQnx5QL0Ij4RPRAwBzbQQg/0CRJNMtbyj1BbAf0EYDIsHfH3Ee NEe3LJgD8GwDICUh/yeABBEw8SA0BbA4sAuAB0D/LuExsDESLyMdAEPiP2AlkL8ngEXgPMED8CBQ IaFwEoFsImIJ0QSBIip5BCAt/x8AHnBAQR6BA6A+0DDSHXD4RE1WJOI1cQfRI9ACEHJyPtBkL00x J4ADoGS7BRAgEHIsUTgRO/FlH9D/BbFWgjPjSkQ7RCTiH/JV8/sj0DH9YkDhJEAe4SBSWWf/S/JV 8xPgQ6Ej0B9AIpAeYX8G4EpAKUAfcB0wKWIj0GT9BHBnIpAyOgIwS7EhoASQ/zVQLDA/4SeAH/Ae wADALgH/M5Eu4h8wCGA0YCOSH0A1kXsj0BPgYzhQJoYnYiTibfsEAECSbSKQSxAKwAVAHpB3CyBb c1aUaQXAHjBP8HD/JCAx8FLiJbA8EiTBU6Mj0P9jSSyJBaAnQQuAKWJnMUPS/zlCIEMppyP2JCBk kV80SkRbPrA1UGcp0Asgc0h7RNdfUSe6J7otcxJPUUUF0K9QYT7BcxMntEYDYTohoDBraXgtMKEe IXNAywiQADAuWAEgWwDAAxCNJPA6dX92gl0gTwOgVEJlE+BsHnBPHnBB9x3wBJAEIFId4QnBC5An w38GYAIwdVB1EDFAX8Af0EozZJAikDIyH9AB0DExACA0OjI0IFBN/Se0VHcwdWN2N3qFK/R1UO5b d1J4oAZgYzkBEiAsmP5DM4EpYSe6MbAfER1BKVX8IGohgCOxHaECQFNABTH9OFBlYLMhtCBAA2BP 8CIR/1+xSHUxsgEABPIgwCRAbBH/HjAFMR8RIjcDoFLxITAsMP8e0kCSOzADoDbABRAhcSe0+4my H4FzPvUT4CODIMAgIfYqN+Q/4CphEYAAB4AfkuEQwEZBSUtIe3/vgPz+PZCvkSWBfEmWKRA3EF9y /x3RPJEeYQERF8EEIF1XX0HfRvNVCSYRIFIzcXULMSfSx1NyaPE8siJzeR4gKWH/VNAgUUXhJQCJ tYZxJbB2Af9Rsx8RNDAiAjzjC3EegQ6wemcFsHkntB5iVQgu4Uieb5gwWQEjEQBwa3Mf0b8wQQSg jSKe8T4ijTJyP2D/BAAHkSiyHeA24DhQP+AntP0k8nU/8keDHxGHJlfxmcf/H3Aewi0BPiKCQU1B TEEDIA8iUTPgAIBIe0ZXSVdBTXRTS1MvSzhgR98J8BRABPCZYR1xZFjQUGG/B5EsiQRgIVA24Dcg LwDQ/3YBAJCqZCe0luJkcDUZX7GcczpyWzGhA2B1Z1PR/mitMKWTB4AGIjswHnArRH00sEIk4ThQ A6BX8UXgZtsA0E1BKa3OLIkiM3KZAj8nuoEFHwIlUEdjRRNuZvdLU1OjRUF5KWEzwDcQh5P/UuKq 8h8wXsUntFaCAHBKRP4qC4ApQB4SjMBOdVKjKoj9LuFBIsE0ATDzXwi49Z8311WwBbGesi0siSg/ bB2S/HdrH0GHA2xCBJCct2iF/yQgWXE8ZyPQGCBwIAtgb8H9Z3cuxVA5MUIUvOVkcye0j6RhSmJA kkBDImlQaTL/VNA8wmt5H1EIkUh/bZUSgf+q0gUwBCBAQ8MlnRvJljWw/zcgRWCloaGWNuApQF2I O0R/LFEAkA6wOTFWAgDAYyFv/1FhR3ZbFStHnLVzdiyJPiL/uVMx42lCo6IgUgGQWBEFQP+aVMoV niFWM6LTJtJisbEB/yTBwMIdAI7EA4HCAdE3ZHD7eaInqzEu4IZEmnKLYmDy/90UPPq4cA3gPKAx QSrRNDF/UkRUYD4iPiEntC7wHOBEf9IdITAFECt1Kae39Se6Mv0u4ETilAnwhTIgQ0CRb8FHVBCY 8N/HU0hBfIAo7wWxAJBmwMRxKU5mmlTg5/88+m1TMRHLGYeiTeIkwjEDf1IUB0B3YCtyR5Pg51FB aNdnocG8J7ROSkBldVBKEf/llI0iIaEEEGRwcFFJxFSC9GQhJ7pBNCAIcEpTInD/NsAnQT7QtoW0 yDD0nBLHtP/RsR1iKnmrpWeiA6AlIRgg/nawoWohL+BmYVq1ujUEIP8eYbdxKLIpQU/xPqFmUgDA /+1y+BfZ4RfBKi5dQWWQHSD/M9EKQB7DmAXKG3mfJ9Lu4KB0cDovL5gwYndRl3aCqsBL4S2wky00 A7BXIGC/QJdiLu7gbfgFX/8FjwafB2rg5HdS0XGqcSlxf89iCHh9/QJSrUACoQvwLu12Ri924tpx L89ic6DWUBYvd1Lg5H0OgB4ANRABAAAAQQAAADxDMUE0N0YxNTQwREYzMjQ2QThEMzBDODUzQzA1 RDBEQTAzREUyMzM5QERBQkVDSy5taXNzaS5uY3NjLm1pbD4AAAAAHgA5EAEAAAAdAAAAPDRFMjlE QzQ4LjYwNjAzMDVAdGVsaWEuY29tPgAAAAAeAEIQAQAAAB0AAAA8NEUyOURDNDguNjA2MDMwNUB0 ZWxpYS5jb20+AAAAAAMAgBD/////HwDzEAEAAABWAAAAUgBFACUAMwBBACAAWwBwAGsAaQB4AF0A IABTAGUAYwB1AHIAZQAgAEMAcgBlAGQAZQBuAHQAaQBhAGwAIABDAGwAbwBuAGkAbgBnAC4ARQBN AEwAAAAAAAsA9hAAAAAAQAAHMKHn+Mi1SMwBQAAIMM81B8m1SMwBAgEQMAEAAABGAAAAAAAAAJJj 8pZU/tMRo/gAgF8xnEUHAF5KQJejlNIRo8UAgF++yL8AAAFzXTwAAMsWET8I06VPmnxqPUhEoqcA AAJxKyQAAAAAAwDeP59OAAADAPE/CQQAAB4A+D8BAAAADwAAAEtlbXAsIERhdmlkIFAuAAACAfk/ AQAAAE0AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089RVhDSEFOR0VOU0EvT1U9TUlT U0kvQ049UkVDSVBJRU5UUy9DTj1EUEtFTVAxAAAAAB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1pbmlz dHJhdG9yAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAAwD9 P+QEAAADABlAAAAAAAMAGkAAAAAAHgAwQAEAAAAIAAAARFBLRU1QMQAeADFAAQAAAAgAAABEUEtF TVAxAB4AOEABAAAACAAAAERQS0VNUDEAHgA5QAEAAAACAAAALgAAAAMAdkD/////AwAJWQEAAAAD AAFuAAAAAAMAIYEDIAYAAAAAAMAAAAAAAABGAAAAAAGBAAAAAAAABQAigQMgBgAAAAAAwAAAAAAA AEYAAAAAAoEAAAAAAAAAAAAAAwAkgQMgBgAAAAAAwAAAAAAAAEYAAAAAE4EAAAEAAAALACWBAyAG AAAAAADAAAAAAAAARgAAAAAcgQAAAAAAAAsAJ4EDIAYAAAAAAMAAAAAAAABGAAAAACaBAAAAAAAA AwApgQMgBgAAAAAAwAAAAAAAAEYAAAAAEIEAAAAAAAADACqBAyAGAAAAAADAAAAAAAAARgAAAAAR gQAAAAAAAAMALYEDIAYAAAAAAMAAAAAAAABGAAAAACqBAAAAAAAAAwAwgQMgBgAAAAAAwAAAAAAA AEYAAAAAKYEAAAAAAAALADGBAyAGAAAAAADAAAAAAAAARgAAAAAkgQAAAAAAAAsAMoEDIAYAAAAA AMAAAAAAAABGAAAAACyBAAAAAAAAHgAzgQMgBgAAAAAAwAAAAAAAAEYAAAAAJ4EAAAEAAAABAAAA AAAAAAMANIEDIAYAAAAAAMAAAAAAAABGAAAAABKBAAABAAAAHgA1gQMgBgAAAAAAwAAAAAAAAEYA AAAAIYEAAAEAAAABAAAAAAAAAAsANoEDIAYAAAAAAMAAAAAAAABGAAAAAAOBAAAAAAAAAwA5gQMg BgAAAAAAwAAAAAAAAEYAAAAAI4EAAP///38LAIiBCCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAA AAMA7YEIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwDygQggBgAAAAAAwAAAAAAAAEYAAAAA A4UAAAAAAAADAPyBCCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAA4IIIAYAAAAAAMAAAAAA AABGAAAAABiFAAAAAAAACwDsggggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAALAPCCCCAGAAAA AADAAAAAAAAARgAAAACChQAAAAAAAEAA7IMIIAYAAAAAAMAAAAAAAABGAAAAAL+FAACQ+3c/tUjM AQsAKQAAAAAACwAjAAAAAAADAAYQlMggXgMABxA/CwAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAA ZQAAAElTVVBQT1NFQU5BQlVOREFOQ0VPRkNBVVRJT05JU1dBUlJBTlRFRCxHSVZFTlRIRU5VTUJF Uk9GRFVCSU9VU1BBVEVOVFNBTFJFQURZSVNTVUVELEJVVElTTlRBTUVUSE9EU1UAAAAAAgF/AAEA AABBAAAAPEMxQTQ3RjE1NDBERjMyNDZBOEQzMEM4NTNDMDVEMERBMDNERTIzMzlAREFCRUNLLm1p c3NpLm5jc2MubWlsPgAAAABLvg== ------_=_NextPart_001_01CC48B5.C8FB49FE-- ------------=_1311369893-23253-1-- From kyanha@kyanha.net Fri Jul 22 21:39:43 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D316721F8AD8 for ; Fri, 22 Jul 2011 21:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpByBXKTVp3K for ; Fri, 22 Jul 2011 21:39:43 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5362C21F86A4 for ; Fri, 22 Jul 2011 21:39:42 -0700 (PDT) Received: by pzk6 with SMTP id 6so4445929pzk.26 for ; Fri, 22 Jul 2011 21:39:42 -0700 (PDT) Received: by 10.68.10.34 with SMTP id f2mr954984pbb.296.1311395982632; Fri, 22 Jul 2011 21:39:42 -0700 (PDT) Received: from [10.49.134.41] ([166.205.140.190]) by mx.google.com with ESMTPS id i9sm2371097pbk.36.2011.07.22.21.39.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jul 2011 21:39:41 -0700 (PDT) From: Kyle Hamilton To: Erik Andersen In-Reply-To: X-Mailer: iPhone Mail (7E18) References: Message-Id: <66D6E5A5-9AF0-4D66-9D48-4FC997FB262A@kyanha.net> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7E18) Date: Fri, 22 Jul 2011 21:39:25 -0700 Cc: Directory list , SG17-Q11 , PKIX Subject: Re: [pkix] ForwardCertificationPath X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 04:39:43 -0000 On Jul 22, 2011, at 9:14, "Erik Andersen" wrote: > > ForwardCertificationPath ::= SEQUENCE OF CrossCertificates > > > > CrossCertificates ::= SET OF Certificate > > > > In particular, why is it a SET OF Certificate? > Plausible (to me) explanation (and I have no connection with any of the design document requirements, just speculation): To deal with the situation you find today: that there are many independent trust anchors (states), and devices are tied to their own state of ownership; so, you need to figure out a way back to your own certification hierarchy (in the event of, say, international treaties which only exist as long as the government is recognized as a legitimate government). The SET OF Certificate is the set of incoming trust certifications that the local trust anchor has. It may be any size, and no state is any greater or lesser than any other in the standards. This is also (if my guess is correct) the original purpose for these standards, to facilitate inter-state communications. The ITU is a working arm of the United Nations, and thus simply cannot be political. The goal of the UN is to facilitate and foster international community, not cause war by any kind of inter-state favoritism reflected in the standards. The system finally makes logical sense, and has a kind of incredibly elegant beauty, when it is viewed from that perspective. I expect that access to the inter-state working group minutes would be educational, but they are not available to me. -Kyle H From anders.rundgren@telia.com Fri Jul 22 23:34:30 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5203821F87BC for ; Fri, 22 Jul 2011 23:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3H228lSpvhTh for ; Fri, 22 Jul 2011 23:34:29 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 28FB921F87AF for ; Fri, 22 Jul 2011 23:34:28 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B00D4498D; Sat, 23 Jul 2011 08:34:25 +0200 Message-ID: <4E2A6B68.2030409@telia.com> Date: Sat, 23 Jul 2011 08:34:16 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Kemp, David P." References: <4E29DC48.6060305@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Secure Credential Cloning X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 06:34:30 -0000 On 2011-07-22 23:24, Kemp, David P. wrote: > I suppose an abundance of caution is warranted, given the number of > dubious patents already issued, but isn't a method supposed to be > non-obvious in order to be patentable? Yes, that was the original idea but is has been proven over and over that it doesn't work in practice for software methods. > You are requesting issuance of a credential, using the subject's > credential to authenticate the request. Is there anything novel about > that idea? Not really, it is rather the use of a strong credential to get a a strong "clone" and the mechanics to do it (including two-way usage of device IDs) that may be novel from a patent troll's perspective. > The new credential is NOT a clone; some fields MUST be > different (serial number, validity, subject public key, signature), some > fields MAY be different (issuer, extensions such as certificate policy > and key usage), but presumably in your use case the subject DN and the > subject alternative name extension MUST be copied from the > authenticating cert to the new cert. What a "clone" is in a biological sense is pretty clear. It has the same DNA but not the same flesh and blood. I just felt that the word "clone" was a bit cool and not entirely wrong either. I guess you would prefer "derived"? For the end-user it is rather a "copy" :-) How you distinguish a "cloned/derived/copied" credential from the original is outside this specification but would in the simplest [PKI] case only be the serial number and validity plus the fact that the public key would be different. > If there are no other mechanisms used to authenticate the requestor, the > assurance of the new credential will be less than the original. You mean that the assurance gets "diluted" by each "cloning"? > That is the same problem as with paper "breeder" credentials - if you can get > the DMV to renew a forged/stolen driver's license, or get some other > issuer to give you a new credential based on the license, then you have > a way of bootstrapping a dodgy credential into a perfectly legitimate > one. I believe there is a difference here; in this case the issuer is meant to be *identical* so having one or multiple stolen credentials should not make a big difference unless the identify thief is working with some kind of coordinated multi-lane attack on a user's assets. > I wouldn't want a hacker to be able to misuse my smart card to get > their cellphone provisioned with a legitimate credential containing my > name, so the issuance method should have other safeguards. There are of course an infinite number of things you could add during enrollment to mitigate this. The specification only deals with the technical part of the "cloning" and leaves policy to the deployers. Each trust-network will apply their own ideas and policies. >From your DoD watchtower the following claim could be noteworthy: I believe that this is a more likely candidate for future mobile government solutions than connecting external CAC cards to a device. A rudimentary predecessor to this scheme has already been put in production by at least one big government agency. Yes, yours truly designed the system for them :-) Anders > > Dave > > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Anders Rundgren > Sent: Friday, July 22, 2011 4:24 PM > To: pkix@ietf.org > Subject: [pkix] Secure Credential Cloning > > This posting is just an attempt keeping patent trolls away. > The described concept is already in production use (in various > variants), but hasn't been *publicly* documented AFAIK. > > Secure Credential Cloning > ========================= > > There are quite a bunch of efforts based on having credentials in the > cloud > as well as "syncing" them to various devices. This fits a certain > category > of credentials. However, banks, governments, and enterprises are > unlikely > to buy into this concept for various rational and historical reasons. > > FWIW, the SKS/KeyGen2 scheme addresses credential mobility/accessibility > in two different ways: > > - Through physical means (if using USB token form factor) > - Through credential "cloning" > > Cloning is not to be confused with copying; it is a process when you > get another *instance* of the same credential. Assume that you have a > government- or bank-credential (presumably in an awkward container > of their choice such as a regular smart card...), and that you would > rather use your "iPhone" as credential carrier. > > If the issuer accepts your choice of credential carrier (typically > listed on the issuer's site), you may login to the issuer using the > original credential and get a new one for the target device. > How can this be performed in a secure manner you may wonder? > > 1. The device has a device certificate which identifies the brand and > ID to the issuer during the issuance process > > 2. During enroll the user specifies the SHA1 (or similar) of the device > certificate so that the issuer is assured that it is talking to the > right container > > Note: no enrollment passwords are needed! > > A further advantage with cloning is that in case you lose a credential > it can be revoked while other instances of it are still usable making > it a sort of a credential backup solution as well. > > Anders Rundgren > http://webpki.org/auth-token-4-the-cloud.html From roberto@opazo.cl Sat Jul 23 09:00:51 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0906121F89C1 for ; Sat, 23 Jul 2011 09:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvG-nds8Z3V6 for ; Sat, 23 Jul 2011 09:00:50 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 354E321F8A7D for ; Sat, 23 Jul 2011 09:00:49 -0700 (PDT) Received: by qwc23 with SMTP id 23so2425279qwc.31 for ; Sat, 23 Jul 2011 09:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opazo.cl; s=google; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=LFDd/gQgXjW7oYaL+GVgFfwoWss9UoqrcMeybocJT+s=; b=hAjeYyC4mlxOMxIogjeavXC6fifm4wp2jeHpm20QthS3MiwiE5EUNRnWcEEiyy7oW2 +hpKWNT156w/iuyTb31bj5jxhMGH0GvC/5MH8wHDgDYpummyYPHBboJvC00Buu6O6QYy VNj7ljPBYFD4d6fRa4MrtkFqaVzRKgFk+CwfI= MIME-Version: 1.0 Received: by 10.224.204.66 with SMTP id fl2mr2194152qab.78.1311436845642; Sat, 23 Jul 2011 09:00:45 -0700 (PDT) Received: by 10.229.88.134 with HTTP; Sat, 23 Jul 2011 09:00:45 -0700 (PDT) Date: Sat, 23 Jul 2011 12:00:45 -0400 Message-ID: From: Roberto Opazo To: IETF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [pkix] Which is the new KPI research that is telling us how PKI is going on? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 16:00:51 -0000 Hello people: Could you please give me some references to have a real, objective opinion about this important question for all of us? Is PKI going well? I=92m looking for researches that show PKI growing in the world, but I=92m not been lucky. I=92m founding a lot of pessimism and it seems PKI is growing more in my very small and far country (Chile) than in the rest of the world. If you Google =93pki statistics=94 or =93pki growing=94, there are not obvi= ous references and there are a lot of very old researches. Which is the new PKI research that is telling us how PKI is going on? --=20 Best regards, Roberto Opazo Consulting partner at Vyreal Consulting Group www.vyreal.com From pala@isis.poly.edu Sat Jul 23 11:55:44 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CCA21F8B00 for ; Sat, 23 Jul 2011 11:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hO-h4Q0JppV for ; Sat, 23 Jul 2011 11:55:43 -0700 (PDT) Received: from isis.poly.edu (isis.poly.edu [128.238.66.15]) by ietfa.amsl.com (Postfix) with ESMTP id 19D3321F8AFF for ; Sat, 23 Jul 2011 11:55:42 -0700 (PDT) Received: (qmail 6784 invoked from network); 23 Jul 2011 18:55:41 -0000 Received: from unknown (HELO ?192.168.100.100?) (madwolf@24.0.161.170) by isis.poly.edu with CAMELLIA256-SHA encrypted SMTP; 23 Jul 2011 18:55:41 -0000 Message-ID: <4E2B1936.2050702@isis.poly.edu> Date: Sat, 23 Jul 2011 14:55:50 -0400 From: Massimiliano Pala Organization: NYU Poly User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 18:55:44 -0000 On 07/23/2011 12:00 PM, Roberto Opazo wrote: > Hello people: > > Could you please give me some references to have a real, objective > opinion about this important question for all of us? > > Is PKI going well? > > I’m looking for researches that show PKI growing in the world, but I’m > not been lucky. I’m founding a lot of pessimism and it seems PKI is > growing more in my very small and far country (Chile) than in the rest > of the world. > > If you Google “pki statistics” or “pki growing”, there are not obvious > references and there are a lot of very old researches. > > Which is the new PKI research that is telling us how PKI is going on? I would say that PKIs have now become the required building block for strong authentication and communications both on the Internet and for industry/companies/organizations. Indeed, all the auth systems that today implement "strong" authentication rely on public-key technology (e.g., governments, cloud and grid computing, etc.). What we need today is to provide a support system for PK for the Internet that would allow simple interactions among parties that use this technology. Cheers, Max -- tel.718-260-4009 | web: http://member.acm.org/~openca/ Massimiliano Pala, Ph.D. Director, OpenCA Labs Professor, NYU Poly From anders.rundgren@telia.com Sat Jul 23 13:05:05 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6251621F8B65 for ; Sat, 23 Jul 2011 13:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQ8hp8Pz61jQ for ; Sat, 23 Jul 2011 13:05:04 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 73DFE21F8B5C for ; Sat, 23 Jul 2011 13:04:58 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA0346189C; Sat, 23 Jul 2011 22:04:56 +0200 Message-ID: <4E2B2960.8090109@telia.com> Date: Sat, 23 Jul 2011 22:04:48 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Roberto Opazo References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: IETF Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 20:05:05 -0000 On 2011-07-23 18:00, Roberto Opazo wrote: > Hello people: > > Could you please give me some references to have a real, objective > opinion about this important question for all of us? Hello Roberto! I think that anyone claiming to be objective is liar so here is a list of what I call "PKI hurdles". The Microsoft Problem #1: ======================== Assume you have an organization with AD running in W2K8SR2 and all clients run W7SP1. Now one would believe that buying a bunch of smart cards and connecting to "CertServ" would be all that it takes, right? No way! Self-service? No way! You need a *very pricey consultant* and tons of alien software. Why would anybody except cost-insensitive government agencies put up with that? The Consumer PKI Problem: ========================= Assume that your country have issued e-IDs for their citizens. But the computers are not equipped with card readers! - Who are supposed to pay for readers? - Who is supposed to pay for a card when hardly any bank accepts it? The On-line Bank Problem #1 =========================== On-line banks often want to use PKI but have in spite of being (usually...) among the richest organizations in the world, not spent a cent on developing a dirt-cheap USB-token that fits into their clients' computers. The On-line Bank Problem #2 =========================== Due to On-line Bank Problem #1 they typically try "soft" PKI. Then they pretty immediately run into Microsoft Problem #2 which is that "CertEnroll" is piece of junk and therefore *they are forced developing their own software* which of course cause major support issues and skyrocketing costs. The SDO Problem: ================ Standards groups concentrate on small things they understand and therefore protocols are typically disconnected from the middleware which in turn is disconnected from the hardware. So it is all darkness and gloom? Absolutely not! Fortunately there are new vendors that sell amazingly popular computing devices that can be easily deployed with PKI without adding any additional client software or hardware: http://images.apple.com/iphone/business/docs/iPhone_OTA_Enrollment_Configuration.pdf I could add lots of other things but e-mail isn't for writing novels :-) Best, Anders > > Is PKI going well? > > I’m looking for researches that show PKI growing in the world, but I’m > not been lucky. I’m founding a lot of pessimism and it seems PKI is > growing more in my very small and far country (Chile) than in the rest > of the world. > > If you Google “pki statistics” or “pki growing”, there are not obvious > references and there are a lot of very old researches. > > Which is the new PKI research that is telling us how PKI is going on? > From pgut001@login01.cs.auckland.ac.nz Sat Jul 23 20:49:30 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B5A21F8BD9 for ; Sat, 23 Jul 2011 20:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.64 X-Spam-Level: X-Spam-Status: No, score=-3.64 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 MLyDkkjUr2QW for ; Sat, 23 Jul 2011 20:49:29 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9544F21F8BD4 for ; Sat, 23 Jul 2011 20:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311479369; x=1343015369; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pkix@ietf.org,=20roberto@opazo.cl|Subject:=20Re: =20[pkix]=20Which=20is=20the=20new=20KPI=20research=20tha t=20is=20telling=20us=20how=20PKI=20is=20going=20on? |In-Reply-To:=20|Message-Id:=20|Date:=20Sun,=2024=20Jul =202011=2015:49:27=20+1200; bh=58zPF0uTloh58OzwmO5QxR1R4oegXclUOBCObOJ9CQ0=; b=GRN3nZXGyVOr1XVl33tGDw5Az9P4kF9g/71oQy+YlKrofkKHh7NmepfB +pibyyVi0WF8uJpnWS2nJwe9vixYhCeSTxTpTqsYthZhDo0LwFZopW70z XKc+IvpqbOKAgtPCmlcYVeBOORghyEj8NN9F7sN8IVAynLyJlZ6g5jc7C E=; X-IronPort-AV: E=Sophos;i="4.67,254,1309694400"; d="scan'208";a="73638094" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Jul 2011 15:49:27 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qkph1-0001UH-Gy; Sun, 24 Jul 2011 15:49:27 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qkph1-00064o-74; Sun, 24 Jul 2011 15:49:27 +1200 From: Peter Gutmann To: pkix@ietf.org, roberto@opazo.cl In-Reply-To: Message-Id: Date: Sun, 24 Jul 2011 15:49:27 +1200 Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 24 Jul 2011 03:49:30 -0000 Roberto Opazo writes: >Is PKI going well? > >I=92m looking for researches that show PKI growing in the world, but I=92m >not been lucky. You already have your answer: You're looking for evidence that PKI is doing well, and haven't found much (or possibly any). Your question has been answered. Peter. From swilson@lockstep.com.au Sat Jul 23 21:10:28 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F5021F8BF2 for ; Sat, 23 Jul 2011 21:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qb9+-1BrBi8R for ; Sat, 23 Jul 2011 21:10:27 -0700 (PDT) Received: from smtp192.iad.emailsrvr.com (smtp192.iad.emailsrvr.com [207.97.245.192]) by ietfa.amsl.com (Postfix) with ESMTP id CE53721F8BE0 for ; Sat, 23 Jul 2011 21:10:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp59.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 5682D3F0B16; Sun, 24 Jul 2011 00:10:26 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp59.relay.iad1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id 654693F0B15; Sun, 24 Jul 2011 00:10:23 -0400 (EDT) Message-ID: <4E2B9B22.6090102@lockstep.com.au> Date: Sun, 24 Jul 2011 14:10:10 +1000 From: Stephen Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Roberto Opazo References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070904050108080105070609" Cc: IETF Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 04:10:28 -0000 This is a multi-part message in MIME format. --------------070904050108080105070609 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Roberto, I believe the reason PKI looks ill still is that there are two different interpretations of the word. (1) Some use the word PKI to mean a system where a third party CA issues certificates for "identification" usually for a fee. This is the original vision of PKI from the early 1990s. It almost universally failed. Notably, post offices worldwide (including US, Australia, Hong Kong, Malaysia and I think the UK) tried in vain to make money selling certificates. Steve Kent has called these "Big CAs". This model failed mainly because it turns out that general purpose identity certificates are pretty much useless. Authorisation in e-business is more important than authentication (see e.g. http://lockstep.com.au/blog/2011/01/22/forget-authentication). As Steve Kent also pointed out, Big CAs acted as though there is only one 'true identity'. All a Big CA can do is check personal identity but in real e-business, diverse digital identities are more important: e.g. employee number, professional licence number, association membership, account number, customer reference number etc. Big CAs cannot easily verify these. There is one arguable exception to the rule that Big PKI failed: SSL server certificates. Clearly these proved to be a sustainable business. (2) Some use the work PKI to refer to the technology of X.509 certificates (and other standards), CA servers, RAs, key media and so on. There are many applications and business environments where PKI technology and special purpose certificates are working very well. I have long argued that "closed" PKI is the _general_ use case and that "open PKI" (with general purpose identity certificates) is a very special case with very little point (see http://lockstep.com.au/library/pki/public_key_superstructure). Some examples of successful closed PKIs: - ICAO electronic passports - Chip-and-PIN EMV DDA smartcards - health smartcards like Sesame Vitale (France) - healthcard provider smartcards in Taiwan, Austria and Australia - Skype - PIV cards - CAC (military ID cards) in US and Australia. So PKI is thriving, if you know where to look, and if we abandon the strawman idea of general purpose identity certificates. Cheers, Stephen Wilson Managing Director Lockstep Group Phone +61 (0)414 488 851 http://lockstep.com.au Lockstep Consulting provides independent specialist advice and analysis on digital identity and privacy.Lockstep Technologies develops unique new smart ID solutions that enhance privacy and prevent identity theft. On 24/07/2011 2:00 AM, Roberto Opazo wrote: > Hello people: > > Could you please give me some references to have a real, objective > opinion about this important question for all of us? > > Is PKI going well? > > I’m looking for researches that show PKI growing in the world, but I’m > not been lucky. I’m founding a lot of pessimism and it seems PKI is > growing more in my very small and far country (Chile) than in the rest > of the world. > > If you Google “pki statistics” or “pki growing”, there are not obvious > references and there are a lot of very old researches. > > Which is the new PKI research that is telling us how PKI is going on? > --------------070904050108080105070609 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Roberto,

I believe the reason PKI looks ill still is that there are two different interpretations of the word. 

(1) Some use the word PKI to mean a system where a third party CA issues certificates for "identification" usually for a fee.  This is the original vision of PKI from the early 1990s.  It almost universally failed.  Notably, post offices worldwide (including US, Australia, Hong Kong, Malaysia and I think the UK) tried in vain to make money selling certificates.  Steve Kent has called these "Big CAs".

This model failed mainly because it turns out that general purpose identity certificates are pretty much useless.  Authorisation in e-business is more important than authentication (see e.g. http://lockstep.com.au/blog/2011/01/22/forget-authentication).   As Steve Kent also pointed out, Big CAs acted as though there is only one 'true identity'.  All a Big CA can do is check personal identity but in real e-business, diverse digital identities are more important: e.g. employee number, professional licence number, association membership, account number, customer reference number etc.  Big CAs cannot easily verify these. 

There is one arguable exception to the rule that Big PKI failed: SSL server certificates.  Clearly these proved to be a sustainable business.


(2) Some use the work PKI to refer to the technology of X.509 certificates (and other standards), CA servers, RAs, key media and so on.  There are many applications and business environments where PKI technology and special purpose certificates are working very well.  I have long argued that "closed" PKI is the _general_ use case and that "open PKI" (with general purpose identity certificates) is a very special case with very little point (see http://lockstep.com.au/library/pki/public_key_superstructure). 

Some examples of successful closed PKIs:

- ICAO electronic passports
- Chip-and-PIN EMV DDA smartcards
- health smartcards like Sesame Vitale (France)
- healthcard provider smartcards in Taiwan, Austria and Australia
- Skype
- PIV cards
- CAC (military ID cards) in US and Australia.

So PKI is thriving, if you know where to look, and if we abandon the strawman idea of general purpose identity certificates.

Cheers,

Stephen Wilson
Managing Director
Lockstep Group

Phone +61 (0)414 488 851

http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.  Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.




On 24/07/2011 2:00 AM, Roberto Opazo wrote: 
Hello people:

Could you please give me some references to have a real, objective
opinion about this important question for all of us?

Is PKI going well?

I’m looking for researches that show PKI growing in the world, but I’m
not been lucky. I’m founding a lot of pessimism and it seems PKI is
growing more in my very small and far country (Chile) than in the rest
of the world.

If you Google “pki statistics” or “pki growing”, there are not obvious
references and there are a lot of very old researches.

Which is the new PKI research that is telling us how PKI is going on?
--------------070904050108080105070609-- From pgut001@login01.cs.auckland.ac.nz Sat Jul 23 21:27:43 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4ED21F8BF2 for ; Sat, 23 Jul 2011 21:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.638 X-Spam-Level: X-Spam-Status: No, score=-3.638 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 7VDzQKBmpivv for ; Sat, 23 Jul 2011 21:27:41 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5BB21F8BEE for ; Sat, 23 Jul 2011 21:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311481662; x=1343017662; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20swilson@lockstep.com.au|Subject:=20Re:=20[pkix]=20 Which=20is=20the=20new=20KPI=20research=20that=20is=20tel ling=20us=20how=20PKI=20is=09going=20on?|Cc:=20pkix@ietf. org|In-Reply-To:=20<4E2B9B22.6090102@lockstep.com.au> |Message-Id:=20|Date:=20Sun,=2024=20Jul=202011=2016:27:39=20+1200; bh=Cyu0x3xZr6Yhc9mZIrvk2+ssJxwaB4cP7NVi0rrfkFk=; b=QFFxbI0UcEwmCtMbcP0YB0V2xhUIjyRKq3oo+pRotAW/hFyixx46ABvE nrt6TiNMKT22pa8hGubfsxJB29mB8qL6fBsDG1EgTILkHxxV9qej4UQAV 9Wq+Y+w8IteoYdQbRfIqs/eGrcsEqFBDTkGa8yyE3NM6pBWZfr/utKoAV 0=; X-IronPort-AV: E=Sophos;i="4.67,254,1309694400"; d="scan'208";a="73640945" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Jul 2011 16:27:40 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QkqHz-0002YV-Iq; Sun, 24 Jul 2011 16:27:39 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QkqHz-0008Kt-Os; Sun, 24 Jul 2011 16:27:39 +1200 From: Peter Gutmann To: swilson@lockstep.com.au In-Reply-To: <4E2B9B22.6090102@lockstep.com.au> Message-Id: Date: Sun, 24 Jul 2011 16:27:39 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 24 Jul 2011 04:27:43 -0000 Stephen Wilson writes: >There is one arguable exception to the rule that Big PKI failed: SSL server >certificates. Clearly these proved to be a sustainable business. It depends what your success criteria are, it's a very successful business model (because it's a pure protection racket, "pay us money or your customers will be scared away by browser messages") so everyone has to pay a CA in order to run a business online (or at least one that uses SSL), but not a very successful security model (it does basically nothing to defeat phishing). My favourite example of SSL PKI in practice is: https://secondzion1.com/ (one of many, many similar sites). If you're nervous about going there, it's a site that trades in: Sale / Purchase of carding stuff, Sell CC + CVV. Enroll (COBs, full info). Sell & Buy accounts: banks, PP, MB and more. Search SSN, DOB, credit reports etc. ATM. Any cashout. Exchange, purchase, electronic currency. Drops for stuff. Hosting, servers, spam, adult and call services. Credit card fraud for sale topical working order. Selling online stores for online carding etc. and it's been certified by a commercial CA. In other words the CAs are issuing certificates to the very criminals that they're supposed to be protecting us from. >There are many applications and business environments where PKI technology and >special purpose certificates are working very well. I have long argued that >"closed" PKI is the _general_ use case and that "open PKI" (with general >purpose identity certificates) is a very special case with very little point I'd label that model the COI (community-of-interest) PKI, and that is a model that works: everyone signs up and agrees to play by the rules of the community, reponsibility and liability are allocated, and so on. >So PKI is thriving, if you know where to look, and if we abandon the strawman >idea of general purpose identity certificates. Unfortunately the strawman concept is still extremely popular (or maybe it's the "PKI as a silver bullet" concept), and for many users it's the only one that exists. It's unfortunate that there's not a stronger distinction drawn between the two... Peter. From anders.rundgren@telia.com Sat Jul 23 22:29:25 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2241121F8B72 for ; Sat, 23 Jul 2011 22:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbJJ4jThWp9t for ; Sat, 23 Jul 2011 22:29:24 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 00F4621F8A6C for ; Sat, 23 Jul 2011 22:29:23 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B00D63CCB; Sun, 24 Jul 2011 07:29:20 +0200 Message-ID: <4E2BADA7.3050607@telia.com> Date: Sun, 24 Jul 2011 07:29:11 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Roberto Opazo References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: IETF Subject: [pkix] The container issue. Re: Which is the new KPI research that is telling us how PKI is going on? 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, 24 Jul 2011 05:29:25 -0000 Roberto, That you can't buy a token for lets say $10 at an ordinary supplier of computers, in a form-factor that fits existing computers (USB), connect to a CA using a standard browser, and after some kind of authentication/authorization process get a certificate in the token, limits "PKI for individuals" to organizations with very "deep pockets" and ample of time. FWIW, I'm running (as a hobby) the currently only publicly known project for rectifying this situation. The project builds on a combination of Open Software and Open Hardware. Initially I tried to use standard smart cards but in most cases you cannot even get a datasheet (!) without an NDA, so it uses standard electronics. The tokens will be produced in China and India who haven't signed the http://www.wassenaar.org/participants/index.html treaty so there will be no limits. The idea is simply making PKI "a better password". Anders On 2011-07-23 18:00, Roberto Opazo wrote: > Hello people: > > Could you please give me some references to have a real, objective > opinion about this important question for all of us? > > Is PKI going well? > > I’m looking for researches that show PKI growing in the world, but I’m > not been lucky. I’m founding a lot of pessimism and it seems PKI is > growing more in my very small and far country (Chile) than in the rest > of the world. > > If you Google “pki statistics” or “pki growing”, there are not obvious > references and there are a lot of very old researches. > > Which is the new PKI research that is telling us how PKI is going on? > From swilson@lockstep.com.au Sun Jul 24 00:12:09 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4865621F86C1 for ; Sun, 24 Jul 2011 00:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V-xrFlaqx4m for ; Sun, 24 Jul 2011 00:12:06 -0700 (PDT) Received: from smtp162.iad.emailsrvr.com (smtp162.iad.emailsrvr.com [207.97.245.162]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5FE21F857E for ; Sun, 24 Jul 2011 00:12:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp56.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 0EB413D81E7; Sun, 24 Jul 2011 03:12:01 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp56.relay.iad1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id 4A2AD3D81CE; Sun, 24 Jul 2011 03:11:58 -0400 (EDT) Message-ID: <4E2BC5B3.2070306@lockstep.com.au> Date: Sun, 24 Jul 2011 17:11:47 +1000 From: Stephen Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Anders Rundgren References: <4E2BADA7.3050607@telia.com> In-Reply-To: <4E2BADA7.3050607@telia.com> Content-Type: multipart/alternative; boundary="------------030104030505040007030500" Cc: IETF Subject: Re: [pkix] The container issue. Re: Which is the new KPI research that is telling us how PKI is going on? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 07:12:09 -0000 This is a multi-part message in MIME format. --------------030104030505040007030500 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Anders, What do you imagine such a certificate would be used for? What exactly will the certificates mean to any Relying Party? "This is [probably] Anders Rundgren, so says some CA [see fine print]"? On the other hand, there actually are dozens of different certificates-for-individuals issued in closed communities of interest for special purposes. I have many personal certificates embedded in my Chip-and-PIN cards, my passport, my cell phone, my Skype client etc etc. There is no conspiracy behind the failure of open PKI. Rather, the fact is that there is no precedent in the real world for a single general purpose identity. There is no social/legal infrastructure for supporting such a thing, no demand for it, and plenty of privacy-related objections to ever really having it. Cheers, Steve. Stephen Wilson Managing Director Lockstep Group Phone +61 (0)414 488 851 http://lockstep.com.au Lockstep Consulting provides independent specialist advice and analysis on digital identity and privacy.Lockstep Technologies develops unique new smart ID solutions that enhance privacy and prevent identity theft. On 24/07/2011 3:29 PM, Anders Rundgren wrote: > Roberto, > > That you can't buy a token for lets say $10 at an ordinary > supplier of computers, in a form-factor that fits existing > computers (USB), connect to a CA using a standard browser, > and after some kind of authentication/authorization process > get a certificate in the token, limits "PKI for individuals" > to organizations with very "deep pockets" and ample of time. > > FWIW, I'm running (as a hobby) the currently only publicly > known project for rectifying this situation. > > The project builds on a combination of Open Software and > Open Hardware. Initially I tried to use standard smart cards > but in most cases you cannot even get a datasheet (!) without > an NDA, so it uses standard electronics. > > The tokens will be produced in China and India who haven't > signed the http://www.wassenaar.org/participants/index.html > treaty so there will be no limits. > > The idea is simply making PKI "a better password". > > Anders > > On 2011-07-23 18:00, Roberto Opazo wrote: >> Hello people: >> >> Could you please give me some references to have a real, objective >> opinion about this important question for all of us? >> >> Is PKI going well? >> >> I’m looking for researches that show PKI growing in the world, but I’m >> not been lucky. I’m founding a lot of pessimism and it seems PKI is >> growing more in my very small and far country (Chile) than in the rest >> of the world. >> >> If you Google “pki statistics” or “pki growing”, there are not obvious >> references and there are a lot of very old researches. >> >> Which is the new PKI research that is telling us how PKI is going on? >> > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > --------------030104030505040007030500 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Anders,

What do you imagine such a certificate would be used for?  What exactly will the certificates mean to any Relying Party?  "This is [probably] Anders Rundgren, so says some CA [see fine print]"? 

On the other hand, there actually are dozens of different certificates-for-individuals issued in closed communities of interest for special purposes.  I have many personal certificates embedded in my Chip-and-PIN cards, my passport, my cell phone, my Skype client etc etc. 

There is no conspiracy behind the failure of open PKI.  Rather, the fact is that there is no precedent in the real world for a single general purpose identity.  There is no social/legal infrastructure for supporting such a thing, no demand for it, and plenty of privacy-related objections to ever really having it.

Cheers,

Steve.

Stephen Wilson
Managing Director
Lockstep Group

Phone +61 (0)414 488 851

http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.  Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.




On 24/07/2011 3:29 PM, Anders Rundgren wrote: 
Roberto,

That you can't buy a token for lets say $10 at an ordinary
supplier of computers, in a form-factor that fits existing
computers (USB), connect to a CA using a standard browser,
and after some kind of authentication/authorization process
get a certificate in the token, limits "PKI for individuals"
to organizations with very "deep pockets" and ample of time.

FWIW, I'm running (as a hobby) the currently only publicly
known project for rectifying this situation.

The project builds on a combination of Open Software and
Open Hardware.  Initially I tried to use standard smart cards
but in most cases you cannot even get a datasheet (!) without
an NDA, so it uses standard electronics.

The tokens will be produced in China and India who haven't
signed the http://www.wassenaar.org/participants/index.html
treaty so there will be no limits.

The idea is simply making PKI "a better password".

Anders

On 2011-07-23 18:00, Roberto Opazo wrote:

Hello people:

Could you please give me some references to have a real, objective
opinion about this important question for all of us?

Is PKI going well?

I’m looking for researches that show PKI growing in the world, but I’m
not been lucky. I’m founding a lot of pessimism and it seems PKI is
growing more in my very small and far country (Chile) than in the rest
of the world.

If you Google “pki statistics” or “pki growing”, there are not obvious
references and there are a lot of very old researches.

Which is the new PKI research that is telling us how PKI is going on?



_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--------------030104030505040007030500-- From anders.rundgren@telia.com Sun Jul 24 01:37:21 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781B121F8A7E for ; Sun, 24 Jul 2011 01:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 Ou0qPkUC9OjF for ; Sun, 24 Jul 2011 01:37:20 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 1293E21F8A80 for ; Sun, 24 Jul 2011 01:37:19 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F0076D36E; Sun, 24 Jul 2011 10:37:16 +0200 Message-ID: <4E2BD9B2.801@telia.com> Date: Sun, 24 Jul 2011 10:37:06 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: swilson@lockstep.com.au References: <4E2BADA7.3050607@telia.com> <4E2BC5B3.2070306@lockstep.com.au> In-Reply-To: <4E2BC5B3.2070306@lockstep.com.au> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: IETF Subject: Re: [pkix] The container issue. Re: Which is the new KPI research that is telling us how PKI is going on? 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, 24 Jul 2011 08:37:21 -0000 On 2011-07-24 09:11, Stephen Wilson wrote: > > Anders, > > What do you imagine such a certificate would be used for? > What exactly will the certificates mean to any Relying Party? > "This is [probably] Anders Rundgren, so says some CA [see fine print]"? Stephen, This is a container solution. The "CA" I mentioned would in an enterprise setting be your local enterprise CA who's certificates would be used as passwords are used today. The difference compared to current solutions is that this concept works equally well if the enterprise has 10 or 100 000 employees although the authorization methods may surely differ. Also in contrast to current solutions the very same token can host hundreds of certificates belonging to different communities. I imagine that the e-governments and on-line banks in the EU having issued tenth of millions of "soft" certificates could consider using such a token if it (=whole "stack") reaches the state of commoditization needed for this to actually make sense. By increasing the end-user price with $1 the functionality could be added to USB memory sticks. Although this has been tried without success earlier, the predecessors IMHO were too focused on the business model, like charging money for each enrolled credential!!! Note: This concept in no way competes with passports, healthcards, EMV and similar centrally produced cards. NSTIC is an interesting in-between scheme where there probably will be a clash with the "traditionals". Last but not least: The scheme is intended to work identically in enhanced mobile phones. This is not a research project, vendor solution, or standardization effort. It is an attempt establishing an "industry" standard through an open implementation which runs all the way from browser, protocol, and middleware down to low-level crypto and electronics. Cheers, Anders > On the other hand, there actually are dozens of different certificates-for-individuals issued in closed communities of interest for special purposes. I have many personal certificates embedded in my > Chip-and-PIN cards, my passport, my cell phone, my Skype client etc etc. > > There is no conspiracy behind the failure of open PKI. Rather, the fact is that there is no precedent in the real world for a single general purpose identity. There is no social/legal infrastructure > for supporting such a thing, no demand for it, and plenty of privacy-related objections to ever really having it. > > Cheers, > > Steve. > > Stephen Wilson > Managing Director > Lockstep Group > > Phone +61 (0)414 488 851 > > http://lockstep.com.au > Lockstep Consulting provides independent specialist advice and analysis > on digital identity and privacy. Lockstep Technologies develops unique > new smart ID solutions that enhance privacy and prevent identity theft. > > > > > On 24/07/2011 3:29 PM, Anders Rundgren wrote: >> Roberto, >> >> That you can't buy a token for lets say $10 at an ordinary >> supplier of computers, in a form-factor that fits existing >> computers (USB), connect to a CA using a standard browser, >> and after some kind of authentication/authorization process >> get a certificate in the token, limits "PKI for individuals" >> to organizations with very "deep pockets" and ample of time. >> >> FWIW, I'm running (as a hobby) the currently only publicly >> known project for rectifying this situation. >> >> The project builds on a combination of Open Software and >> Open Hardware. Initially I tried to use standard smart cards >> but in most cases you cannot even get a datasheet (!) without >> an NDA, so it uses standard electronics. >> >> The tokens will be produced in China and India who haven't >> signed the http://www.wassenaar.org/participants/index.html >> treaty so there will be no limits. >> >> The idea is simply making PKI "a better password". >> >> Anders >> >> On 2011-07-23 18:00, Roberto Opazo wrote: >>> Hello people: >>> >>> Could you please give me some references to have a real, objective >>> opinion about this important question for all of us? >>> >>> Is PKI going well? >>> >>> I’m looking for researches that show PKI growing in the world, but I’m >>> not been lucky. I’m founding a lot of pessimism and it seems PKI is >>> growing more in my very small and far country (Chile) than in the rest >>> of the world. >>> >>> If you Google “pki statistics” or “pki growing”, there are not obvious >>> references and there are a lot of very old researches. >>> >>> Which is the new PKI research that is telling us how PKI is going on? >>> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> >> From era@x500.eu Sun Jul 24 02:46:20 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC23F21F84F2 for ; Sun, 24 Jul 2011 02:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.011 X-Spam-Level: * X-Spam-Status: No, score=1.011 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DK=1.009, 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 a6ELM6L4Iy-8 for ; Sun, 24 Jul 2011 02:46:20 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id E8CDD21F84F1 for ; Sun, 24 Jul 2011 02:46:19 -0700 (PDT) Received: from Morten ([94.191.235.3]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id HQS94016; Sun, 24 Jul 2011 11:46:16 +0200 From: "Erik Andersen" To: "Directory list" , "SG17-Q11" , "PKIX" Date: Sun, 24 Jul 2011 11:46:13 +0200 Message-ID: <000c01cc49e6$88d15e30$9a741a90$@eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CC49F7.4C5A2E30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxJ5oX+48bwi2ggRzupoao/Zxu/Zg== Content-Language: da Subject: [pkix] Intermediate CA vs. subject CA 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, 24 Jul 2011 09:46:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01CC49F7.4C5A2E30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The terms intermediate CA and subject CA are used in the PKIX publications and in X.509. I have not found any exact definitions of those term in any PKIX document, but found some in 8.1.2 of X.509, but I am not sure that these definition are generally accepted in the PKI community. According to an intermediate CA is an CA issuing cross-certificate, while the subject CA is the one for which the cross-certificate is issued. However, the two CAs could have both roles. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik ------=_NextPart_000_000D_01CC49F7.4C5A2E30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The terms = intermediate CA and subject CA are used in the PKIX publications and in = X.509. I have not found any exact definitions of those term in any PKIX = document, but found some in 8.1.2 of X.509, but I am not sure that these = definition are generally accepted in the PKI community.

 

According to = an intermediate CA is an CA issuing cross-certificate, while the subject = CA is the one for which the cross-certificate is issued. However, the = two CAs could have both roles.

 

Erik = Andersen

Andersen's = L-Service

Elsevej = 48,

DK-3500 = Vaerloese

Denmark=

Mobile: +45 2097 = 1490

e-amail: era@x500.eu

Skype: = andersen-erik

http://www.x500.eu/

http://www.x500standard.com/

http://dk.linkedin.com/in/andersenerik

 

------=_NextPart_000_000D_01CC49F7.4C5A2E30-- From anders.rundgren@telia.com Sun Jul 24 10:11:36 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FCC21F84F1 for ; Sun, 24 Jul 2011 10:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 vbgJLtzAYUAp for ; Sun, 24 Jul 2011 10:11:35 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id B7FBD21F84EC for ; Sun, 24 Jul 2011 10:11:35 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F0077BBCF for pkix@ietf.org; Sun, 24 Jul 2011 19:11:34 +0200 Message-ID: <4E2C523E.9010509@telia.com> Date: Sun, 24 Jul 2011 19:11:26 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "pkix@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Certificate Renewals in PKIX Protocols 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, 24 Jul 2011 17:11:36 -0000 This is a question to the list. If you create an initial certificate for a smart card in a trusted environment you you should be able to tell with a high certainty that the key-pair actually was created in the smart card, right? Now, if you perform a certificate renewal, the original key is supposed to vouch for the authenticity of the request, right? Here I feel slightly less convinced since anybody can create a key-pair and get it signed. Does any of the PKIX enrollment protocols support secure renewals in the field? Is it even possible without having an attestation mechanism that is securely distinguishable from ordinary signatures? Anders From pala@isis.poly.edu Sun Jul 24 14:03:41 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5D121F85A3 for ; Sun, 24 Jul 2011 14:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCtsva9WpojA for ; Sun, 24 Jul 2011 14:03:40 -0700 (PDT) Received: from isis.poly.edu (isis.poly.edu [128.238.66.15]) by ietfa.amsl.com (Postfix) with ESMTP id A884521F854E for ; Sun, 24 Jul 2011 14:03:40 -0700 (PDT) Received: (qmail 43714 invoked from network); 24 Jul 2011 21:03:36 -0000 Received: from unknown (HELO ?192.168.100.100?) (madwolf@24.0.161.170) by isis.poly.edu with CAMELLIA256-SHA encrypted SMTP; 24 Jul 2011 21:03:36 -0000 Message-ID: <4E2C88B3.3010207@isis.poly.edu> Date: Sun, 24 Jul 2011 17:03:47 -0400 From: Massimiliano Pala Organization: NYU Poly User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: pkix@ietf.org References: <4E2B9B22.6090102@lockstep.com.au> In-Reply-To: <4E2B9B22.6090102@lockstep.com.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 24 Jul 2011 21:03:41 -0000 Hello Stephen, Roberto, all, I would like to point out that even if authorization is usually what you want to achieve, it always starts with authentication. Be it via a simple Password, Key, Keypair, or a key+certificate. My point being, public-key technology is actually used as the basic block of any strong authentication *and* authorization system today.. because the technology itself works! One thing we shall all work for now, is to make this technology easier to deploy in open environments and/or allow for easy federated identities. In this space, I think, there's a lot of work to do (and we should have worked at it earlier!). Personally, I think that the next step in PKIs, since this is the technology we are using today and are going to use in the next 20/30 years, is to provide a support system for it that will allow the "closed" environment success to be extended to the "open" environment. One point that I agree here with is that generic-pkis do not really have traction, but purpose oriented ones or "closed" ones that are going to be federated (e.g., Grid Computing) are really successful (world wide: look at TAGPMA, IGTF, EUPMA, etc.) A lot of work has been done in the standardization of the certificates (although sometimes we got lost on very.. small details!), but now we need to provide a common ground that can ease the usage of public key technology for the Internet (after all, we have a DNS.. but we don't have a support system for PK... why?!?!?!). An example of the lack of support for PK is the deployment of DNSSEC: everybody agrees that's not the best solution.. but there's nothing better available today that could foster interoperable ``Internet'' security. Anybody on-board to start this huge-but-needed project ? Maybe a new WG like `Support (System) for Internet Trust Infrastructures` could provide a good starting point ? Cheers, Max On 07/24/2011 12:10 AM, Stephen Wilson wrote: > > Roberto, > > I believe the reason PKI looks ill still is that there are two different interpretations > of the word. [...] > (2) Some use the work PKI to refer to the technology of X.509 certificates (and other > standards), CA servers, RAs, key media and so on. There are many applications and > business environments where PKI technology and special purpose certificates are working > very well. I have long argued that "closed" PKI is the _general_ use case and that "open > PKI" (with general purpose identity certificates) is a very special case with very little > point (see http://lockstep.com.au/library/pki/public_key_superstructure). [...] > So PKI is thriving, if you know where to look, and if we abandon the strawman idea of > general purpose identity certificates. -- tel.718-260-4009 | web: http://member.acm.org/~openca/ Massimiliano Pala, Ph.D. Director, OpenCA Labs Professor, NYU Poly From pala@isis.poly.edu Sun Jul 24 14:13:51 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0A821F8610 for ; Sun, 24 Jul 2011 14:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 fMZ3ps89cOjW for ; Sun, 24 Jul 2011 14:13:50 -0700 (PDT) Received: from isis.poly.edu (isis.poly.edu [128.238.66.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0D98221F854E for ; Sun, 24 Jul 2011 14:13:49 -0700 (PDT) Received: (qmail 43877 invoked from network); 24 Jul 2011 21:13:48 -0000 Received: from unknown (HELO ?192.168.100.100?) (madwolf@24.0.161.170) by isis.poly.edu with CAMELLIA256-SHA encrypted SMTP; 24 Jul 2011 21:13:48 -0000 Message-ID: <4E2C8B17.3080803@isis.poly.edu> Date: Sun, 24 Jul 2011 17:13:59 -0400 From: Massimiliano Pala Organization: NYU Poly User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 24 Jul 2011 21:13:51 -0000 On 07/24/2011 12:27 AM, Peter Gutmann wrote: > Stephen Wilson writes: [...] > It depends what your success criteria are, it's a very successful business > model (because it's a pure protection racket, "pay us money or your customers > will be scared away by browser messages") so everyone has to pay a CA in order > to run a business online (or at least one that uses SSL), but not a very > successful security model (it does basically nothing to defeat phishing). My > favourite example of SSL PKI in practice is: I would argue that that's more a failure of who is designing and developing applications rather than who's issuing the certificates. Since the usability of applications from this point of view is ridiculous, I would blame browser vendors rather than PKIs in general - they failed their users with respect of usability. Think about the case where simple http connections (no SSL/TLS) are displayed, to the user, more trustworthy than non-trusted https (SSL/TLS) once.. Bad.. Bad.. Bad.. browsers and who took such bad decisions.. !!! > https://secondzion1.com/ [...] > and it's been certified by a commercial CA. In other words the CAs are issuing > certificates to the very criminals that they're supposed to be protecting us > from. Commercial CAs have their flaws, some are better than others. But since the user has no way to distinguish among them (e.g., they are forced to trust all of them at once by the application vendors!!!), it is quite scary! [...] > I'd label that model the COI (community-of-interest) PKI, and that is a model > that works: everyone signs up and agrees to play by the rules of the > community, reponsibility and liability are allocated, and so on. That's the way it is supposed to be: the user capable of saying "now I want to submit my tax returns to my gov agency, I want to trust only that!" or "now I am at work, trust my organization's CA to authenticate my colleagues". And, of course, extending it to the federated-identities case... Community-Driven + Interoperability and Availability in the Internet is the key in today's online world (or, otherwise called, Internet of things...). Just my 2 cents... -- tel.718-260-4009 | web: http://member.acm.org/~openca/ Massimiliano Pala, Ph.D. Director, OpenCA Labs Professor, NYU Poly From internet-drafts@ietf.org Sun Jul 24 17:59:57 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A135321F8743; Sun, 24 Jul 2011 17:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szxok0cHzM-c; Sun, 24 Jul 2011 17:59:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441C321F856B; Sun, 24 Jul 2011 17:59:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.56 Message-ID: <20110725005957.18927.40817.idtracker@ietfa.amsl.com> Date: Sun, 24 Jul 2011 17:59:57 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-rfc5272-bis-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 00:59:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : Certificate Management over CMS (CMC) Updates Author(s) : Jim Schaad Filename : draft-ietf-pkix-rfc5272-bis-04.txt Pages : 39 Date : 2011-07-24 This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273 and RFC 5274. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc5272-bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-rfc5272-bis-04.txt From roberto@opazo.cl Sun Jul 24 20:26:51 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E89E21F8557 for ; Sun, 24 Jul 2011 20:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgrOfKgMO2pr for ; Sun, 24 Jul 2011 20:26:50 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 563DE21F8551 for ; Sun, 24 Jul 2011 20:26:50 -0700 (PDT) Received: by qyk29 with SMTP id 29so2701413qyk.10 for ; Sun, 24 Jul 2011 20:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opazo.cl; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=BGO0rb33l+Er+FxISY8zoVq6KFSCDZIG3Mpy9Lim2IE=; b=ho3xYErxPQNDI8b1M6gmcoipk+8NyMldu2q33Yvu21k6MSRJb4BRI/kZfZu/sW15hp Ae/nHM5byuaccQ5fU/MaW2vXV06JgCVe7owDF4fRJzbhFen/N/Hhauj0IxKc0DKwqrvd qSFXGwrtiUd4V4WVhZ/Ef4oCylClcgdHHtyeo= MIME-Version: 1.0 Received: by 10.229.68.94 with SMTP id u30mr3022201qci.92.1311564407609; Sun, 24 Jul 2011 20:26:47 -0700 (PDT) Received: by 10.229.88.134 with HTTP; Sun, 24 Jul 2011 20:26:47 -0700 (PDT) In-Reply-To: <4E2C8B17.3080803@isis.poly.edu> References: <4E2C8B17.3080803@isis.poly.edu> Date: Sun, 24 Jul 2011 23:26:47 -0400 Message-ID: From: Roberto Opazo To: pkix@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 03:26:51 -0000 Thanks everybody. Yes, my question was too wide. I=92m thinking in PKI used to authenticate people. Not web servers or invisible certificates for devices or applications. I would like to share the Chilean experience in a few points and numbers: * 5 CA=92s certified by government to sign (sell) trustable certificates. This is to certify people in an open national PKI. * About 60.000 issued certificates. Sounds few, but it=92s not so small number in a country with less than 200.000 companies with accountability. * Companies using electronic invoice: 33.000. All of them interchange their documents in an electronic way. * Examples of documents than are been digitally signed: Electronic Invoices, technical reviews of vehicles, insurance policies, environmental impact assessments, factoring, book works and some others. * Even some banks are madding poor act of presence using certificates with a small group of customers. I still can=92t believe there is no research about global use of X.509 people certificates. 2011/7/24 Massimiliano Pala : > On 07/24/2011 12:27 AM, Peter Gutmann wrote: >> >> Stephen Wilson =A0writes: > > [...] >> >> It depends what your success criteria are, it's a very successful busine= ss >> model (because it's a pure protection racket, "pay us money or your >> customers >> will be scared away by browser messages") so everyone has to pay a CA in >> order >> to run a business online (or at least one that uses SSL), but not a very >> successful security model (it does basically nothing to defeat phishing)= . >> =A0My >> favourite example of SSL PKI in practice is: > > I would argue that that's more a failure of who is designing and developi= ng > applications rather than who's issuing the certificates. Since the usabil= ity > of applications from this point of view is ridiculous, I would blame brow= ser > vendors rather than PKIs in general - they failed their users with respec= t > of > usability. > > Think about the case where simple http connections (no SSL/TLS) are > displayed, > to the user, more trustworthy than non-trusted https (SSL/TLS) once.. Bad= .. > Bad.. > Bad.. browsers and who took such bad decisions.. !!! > >> =A0 https://secondzion1.com/ > > [...] >> >> and it's been certified by a commercial CA. =A0In other words the CAs ar= e >> issuing >> certificates to the very criminals that they're supposed to be protectin= g >> us >> from. > > Commercial CAs have their flaws, some are better than others. But since t= he > user > has no way to distinguish among them (e.g., they are forced to trust all = of > them > at once by the application vendors!!!), it is quite scary! > > [...] >> >> I'd label that model the COI (community-of-interest) PKI, and that is a >> model >> that works: everyone signs up and agrees to play by the rules of the >> community, reponsibility and liability are allocated, and so on. > > That's the way it is supposed to be: the user capable of saying "now I wa= nt > to > submit my tax returns to my gov agency, I want to trust only that!" or "n= ow > I > am at work, trust my organization's CA to authenticate my colleagues". An= d, > of course, extending it to the federated-identities case... > > Community-Driven + Interoperability and Availability in the Internet is t= he > key in today's online world (or, otherwise called, Internet of things...)= . > > Just my 2 cents... > > -- > > tel.718-260-4009 | web: http://member.acm.org/~openca/ > > Massimiliano Pala, Ph.D. > Director, OpenCA Labs > Professor, NYU Poly > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --=20 Saludos, Roberto Opazo From pritikin@cisco.com Sun Jul 24 20:42:02 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC02921F8686 for ; Sun, 24 Jul 2011 20:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCfAND315Vrv for ; Sun, 24 Jul 2011 20:42:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E538721F8681 for ; Sun, 24 Jul 2011 20:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=4261; q=dns/txt; s=iport; t=1311565322; x=1312774922; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0uC4sm2GR/8o5FSFFOGoiJtkEYdlm0uxZhQ9Llzh2RI=; b=RFkw1nr5mDbTI1Jy4t/iPK4bfobbT92JNVzag9RK9qe0kij2YVUfLloM xhv18tNKRKd1jxk0vz90RpVyx6E+8PoivSwuei9E+GJbxb3EnqIa1Li6T ItsO1Dz9w9lkTfCFQJIlkT8dod4Z4e0izvdc2FzLwKs0R1jgMP7Rv1oPK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPfkLE6rRDoH/2dsb2JhbAA0AQEBAQIBAQEBEQFlCwUKAgwYFwccFAwMOR4gB6cud4h8BKF9jn6OOwKDIhKCKl8Eh1WLG4UHi3g X-IronPort-AV: E=Sophos;i="4.67,258,1309737600"; d="scan'208";a="5981016" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jul 2011 03:42:01 +0000 Received: from [10.21.75.62] ([10.21.75.62]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6P3fmbL017779; Mon, 25 Jul 2011 03:41:49 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Max Pritikin In-Reply-To: <4E2B9B22.6090102@lockstep.com.au> Date: Sun, 24 Jul 2011 21:41:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7E9CC5CB-E02B-41DF-A357-10E5222C2DAB@cisco.com> References: <4E2B9B22.6090102@lockstep.com.au> To: swilson@lockstep.com.au X-Mailer: Apple Mail (2.1084) Cc: IETF Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 03:42:03 -0000 > There are many applications and business environments where PKI = technology and special purpose certificates are working very well. = [Stephen Wilson has] long argued that "closed" PKI is the _general_ use = case and that "open PKI" (with general purpose identity certificates) is = a very special case with very little point +1, I think this is a very important point. Even in that context client certificate use has lagged behind server = certificate use.=20 - max On Jul 23, 2011, at 10:10 PM, Stephen Wilson wrote: >=20 > Roberto,=20 >=20 > I believe the reason PKI looks ill still is that there are two = different interpretations of the word. =20 >=20 > (1) Some use the word PKI to mean a system where a third party CA = issues certificates for "identification" usually for a fee. This is the = original vision of PKI from the early 1990s. It almost universally = failed. Notably, post offices worldwide (including US, Australia, Hong = Kong, Malaysia and I think the UK) tried in vain to make money selling = certificates. Steve Kent has called these "Big CAs".=20 >=20 > This model failed mainly because it turns out that general purpose = identity certificates are pretty much useless. Authorisation in = e-business is more important than authentication (see e.g. = http://lockstep.com.au/blog/2011/01/22/forget-authentication). As = Steve Kent also pointed out, Big CAs acted as though there is only one = 'true identity'. All a Big CA can do is check personal identity but in = real e-business, diverse digital identities are more important: e.g. = employee number, professional licence number, association membership, = account number, customer reference number etc. Big CAs cannot easily = verify these. =20 >=20 > There is one arguable exception to the rule that Big PKI failed: SSL = server certificates. Clearly these proved to be a sustainable business.=20= >=20 >=20 > (2) Some use the work PKI to refer to the technology of X.509 = certificates (and other standards), CA servers, RAs, key media and so = on. There are many applications and business environments where PKI = technology and special purpose certificates are working very well. I = have long argued that "closed" PKI is the _general_ use case and that = "open PKI" (with general purpose identity certificates) is a very = special case with very little point (see = http://lockstep.com.au/library/pki/public_key_superstructure). =20 >=20 > Some examples of successful closed PKIs:=20 >=20 > - ICAO electronic passports=20 > - Chip-and-PIN EMV DDA smartcards=20 > - health smartcards like Sesame Vitale (France)=20 > - healthcard provider smartcards in Taiwan, Austria and Australia=20 > - Skype=20 > - PIV cards=20 > - CAC (military ID cards) in US and Australia.=20 >=20 > So PKI is thriving, if you know where to look, and if we abandon the = strawman idea of general purpose identity certificates.=20 >=20 > Cheers,=20 >=20 > Stephen Wilson > Managing Director > Lockstep Group >=20 > Phone +61 (0)414 488 851 >=20 > http://lockstep.com.au > Lockstep Consulting provides independent specialist advice and = analysis=20 > on digital identity and privacy. Lockstep Technologies develops = unique=20 > new smart ID solutions that enhance privacy and prevent identity = theft. >=20 >=20 >=20 >=20 > On 24/07/2011 2:00 AM, Roberto Opazo wrote: >> Hello people: >>=20 >> Could you please give me some references to have a real, objective >> opinion about this important question for all of us? >>=20 >> Is PKI going well? >>=20 >> I=92m looking for researches that show PKI growing in the world, but = I=92m >> not been lucky. I=92m founding a lot of pessimism and it seems PKI is >> growing more in my very small and far country (Chile) than in the = rest >> of the world. >>=20 >> If you Google =93pki statistics=94 or =93pki growing=94, there are = not obvious >> references and there are a lot of very old researches. >>=20 >> Which is the new PKI research that is telling us how PKI is going on? >>=20 >>=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From pgut001@login01.cs.auckland.ac.nz Sun Jul 24 21:24:37 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03BD21F8663 for ; Sun, 24 Jul 2011 21:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.636 X-Spam-Level: X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 uXMIjyZcfwwm for ; Sun, 24 Jul 2011 21:24:37 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5F99C21F8658 for ; Sun, 24 Jul 2011 21:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311567877; x=1343103877; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pkix@ietf.org,=20roberto@opazo.cl|Subject:=20Re: =20[pkix]=20Which=20is=20the=20new=20KPI=20research=20tha t=20is=20telling=20us=20how=20PKI=20is=20going=20on? |In-Reply-To:=20|Message-Id:=20|Date:=20Mon,=2025=20Jul =202011=2016:24:33=20+1200; bh=S1oV6P8SoOXBkFdAYOkIKoLw/jWqIAc8Dm3DXywtnyA=; b=Bv0FjVbnce8w5ZJqFd96yfyA6V5AnPJct5y/LIGJqyI39uEv8ojT1yzr xMpG/kytn5xJhxuVM2SJdaFnqVMjFnALLNfuolu2ehlH+mgZqc9+uxca0 rjab3MSZu5Qjgnalt6pKEreAVSpDuEFKT147vedAtIGFVy3jlFw+X8oIB 4=; X-IronPort-AV: E=Sophos;i="4.67,258,1309694400"; d="scan'208";a="73867094" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Jul 2011 16:24:34 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QlCiX-0005Jo-Hs; Mon, 25 Jul 2011 16:24:33 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QlCiX-0001I4-Fy; Mon, 25 Jul 2011 16:24:33 +1200 From: Peter Gutmann To: pkix@ietf.org, roberto@opazo.cl In-Reply-To: Message-Id: Date: Mon, 25 Jul 2011 16:24:33 +1200 Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 04:24:37 -0000 Roberto Opazo writes: >I still can=92t believe there is no research about global use of X.509 people >certificates. Ah, now that you've narrowed the scope down, it is possible to answer your question. There's been quite a bit of research into this by HCI people (so you've probably been looking in the wrong place for information). The consensus is that client-side/end-user PKI is effectively impossible to use by most users. There have been various proposed alternative ways of dealing with certs that (according to the researchers) are usable, but none of them have ever been adopted. The first study in this area that I know of, "In Search of Usable Security: Five Lessons from the Field" by Balfanz, Durfee, Grinter and Smetters, carried out with highly technical users (mostly PhDs in computer science), found that they took over two hours to set up a certificate for their own use, and rated it as the most difficult computer task they'd ever been asked to perform. There have been numerous further studies by HCI people since then, with roughly the same results. So you need to look at HCI publications, not standard security ones, for information. Peter. From swilson@lockstep.com.au Sun Jul 24 21:27:23 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE71711E8080 for ; Sun, 24 Jul 2011 21:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 GheZcrQe1ugc for ; Sun, 24 Jul 2011 21:27:22 -0700 (PDT) Received: from smtp192.iad.emailsrvr.com (smtp192.iad.emailsrvr.com [207.97.245.192]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5B711E807C for ; Sun, 24 Jul 2011 21:27:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp49.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id D656B190322; Mon, 25 Jul 2011 00:27:21 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp49.relay.iad1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id 7A3F419030A; Mon, 25 Jul 2011 00:27:19 -0400 (EDT) Message-ID: <4E2CEF92.2020006@lockstep.com.au> Date: Mon, 25 Jul 2011 14:22:42 +1000 From: Stephen Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Roberto Opazo References: <4E2C8B17.3080803@isis.poly.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: pkix@ietf.org Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 04:27:24 -0000 Roberto, I think you will find comparable systems in ... - Scandinavia, using the "BankID" technology in cooperation between banks and governments - Taiwan, where they have had a government issued PKI smartcard for B2G transactions for a long time - Parts of Europe where e-invoicing using EU Qualified Digital Signatures and keys (maybe Italy) In many places like Australia, simple B2G transactions like tax returns etc. have operated with simpler cheaper authentication technologies. Where there is just one Relying Party, the advantages of PKI are less, because it is straightforward to manage risk via shared secrets. But it sounds like the Chilean experience is quite strong. Is your system growing or is it stagnant? Cheers, Steve Wilson Lockstep http://lockstep.com.au On 25/07/2011 1:26 PM, Roberto Opazo wrote: > Thanks everybody. > > Yes, my question was too wide. > > I’m thinking in PKI used to authenticate people. Not web servers or > invisible certificates for devices or applications. > > I would like to share the Chilean experience in a few points and numbers: > > * 5 CA’s certified by government to sign (sell) trustable > certificates. This is to certify people in an open national PKI. > > * About 60.000 issued certificates. Sounds few, but it’s not so small > number in a country with less than 200.000 companies with > accountability. > > * Companies using electronic invoice: 33.000. All of them interchange > their documents in an electronic way. > > * Examples of documents than are been digitally signed: Electronic > Invoices, technical reviews of vehicles, insurance policies, > environmental impact assessments, factoring, book works and some > others. > > * Even some banks are madding poor act of presence using certificates > with a small group of customers. > > I still can’t believe there is no research about global use of X.509 > people certificates. > > > 2011/7/24 Massimiliano Pala: >> On 07/24/2011 12:27 AM, Peter Gutmann wrote: >>> >>> Stephen Wilson writes: >> >> [...] >>> >>> It depends what your success criteria are, it's a very successful business >>> model (because it's a pure protection racket, "pay us money or your >>> customers >>> will be scared away by browser messages") so everyone has to pay a CA in >>> order >>> to run a business online (or at least one that uses SSL), but not a very >>> successful security model (it does basically nothing to defeat phishing). >>> My >>> favourite example of SSL PKI in practice is: >> >> I would argue that that's more a failure of who is designing and developing >> applications rather than who's issuing the certificates. Since the usability >> of applications from this point of view is ridiculous, I would blame browser >> vendors rather than PKIs in general - they failed their users with respect >> of >> usability. >> >> Think about the case where simple http connections (no SSL/TLS) are >> displayed, >> to the user, more trustworthy than non-trusted https (SSL/TLS) once.. Bad.. >> Bad.. >> Bad.. browsers and who took such bad decisions.. !!! >> >>> https://secondzion1.com/ >> >> [...] >>> >>> and it's been certified by a commercial CA. In other words the CAs are >>> issuing >>> certificates to the very criminals that they're supposed to be protecting >>> us >>> from. >> >> Commercial CAs have their flaws, some are better than others. But since the >> user >> has no way to distinguish among them (e.g., they are forced to trust all of >> them >> at once by the application vendors!!!), it is quite scary! >> >> [...] >>> >>> I'd label that model the COI (community-of-interest) PKI, and that is a >>> model >>> that works: everyone signs up and agrees to play by the rules of the >>> community, reponsibility and liability are allocated, and so on. >> >> That's the way it is supposed to be: the user capable of saying "now I want >> to >> submit my tax returns to my gov agency, I want to trust only that!" or "now >> I >> am at work, trust my organization's CA to authenticate my colleagues". And, >> of course, extending it to the federated-identities case... >> >> Community-Driven + Interoperability and Availability in the Internet is the >> key in today's online world (or, otherwise called, Internet of things...). >> >> Just my 2 cents... >> >> -- >> >> tel.718-260-4009 | web: http://member.acm.org/~openca/ >> >> Massimiliano Pala, Ph.D. >> Director, OpenCA Labs >> Professor, NYU Poly >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > > > From pgut001@login01.cs.auckland.ac.nz Sun Jul 24 21:28:47 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FFE11E807C for ; Sun, 24 Jul 2011 21:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.634 X-Spam-Level: X-Spam-Status: No, score=-3.634 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 fOdi1kR4rzYc for ; Sun, 24 Jul 2011 21:28:46 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5546F11E8084 for ; Sun, 24 Jul 2011 21:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311568127; x=1343104127; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pritikin@cisco.com,=20swilson@lockstep.com.au |Subject:=20Re:=20[pkix]=20Which=20is=20the=20new=20KPI =20research=20that=20is=20telling=20us=20how=20PKI=20is =09going=20on?|Cc:=20pkix@ietf.org|In-Reply-To:=20<7E9CC5 CB-E02B-41DF-A357-10E5222C2DAB@cisco.com>|Message-Id:=20< E1QlCmX-0001Qy-Lt@login01.fos.auckland.ac.nz>|Date:=20Mon ,=2025=20Jul=202011=2016:28:41=20+1200; bh=fN14KeVwxZ/YRsMqfRKaPWDs5oe+IpZuNB86abdbhpc=; b=BOmr+ixh6d3gPp069W2SHX2mx6BQlLTfi6aQiSEkQVxi1WklUIxzs+nn 7QpC/NRRieiG1P2Om15fzulPe3AmLoli64rkfoD0/GxCDfYSARMLF7rL9 k1m1Y5wGPjCyUq1awLp6d0vEshK2LASgJ4Vj6fiVOO+DbeGDzCaf/ZwHS A=; X-IronPort-AV: E=Sophos;i="4.67,258,1309694400"; d="scan'208";a="73868105" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Jul 2011 16:28:45 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QlCmX-0005ZW-IS; Mon, 25 Jul 2011 16:28:41 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QlCmX-0001Qy-Lt; Mon, 25 Jul 2011 16:28:41 +1200 From: Peter Gutmann To: pritikin@cisco.com, swilson@lockstep.com.au In-Reply-To: <7E9CC5CB-E02B-41DF-A357-10E5222C2DAB@cisco.com> Message-Id: Date: Mon, 25 Jul 2011 16:28:41 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 04:28:47 -0000 Max Pritikin writes: >Even in that context client certificate use has lagged behind server >certificate use. The reason why client certs have seen next to zero adoption is because of the issues given in my previous message. For server certs you get your sysadmin to set up the single cert that's needed in a once-a-year effort, and if it takes him (usually a 'him' :-) two days of work to sort out then that's OK. That just doesn't work for end-users. Client-side certs aren't used because they don't work (at the HCI level), not because of any organised action to avoid them. Peter. From pgut001@login01.cs.auckland.ac.nz Sun Jul 24 21:39:19 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D3811E8084 for ; Sun, 24 Jul 2011 21:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 YTSUWOb9LdTU for ; Sun, 24 Jul 2011 21:39:18 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 16BE011E807C for ; Sun, 24 Jul 2011 21:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311568758; x=1343104758; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20anders.rundgren@telia.com,=20pkix@ietf.org |Subject:=20Re:=20[pkix]=20Certificate=20Renewals=20in=20 PKIX=20Protocols|In-Reply-To:=20<4E2C523E.9010509@telia.c om>|Message-Id:=20|Date:=20Mon,=2025=20Jul=202011=2016:39:17=20+1200; bh=wH2+yij7g7Zw6wxJjbqWjRx6cMW2p4NQYUzhb+ifnCc=; b=C2gUFk1HpdIZhExKhZSKcOCZtflt+U0s9gMYAi/ln2WVSweqKDlDRSnT gHr2UFyoF2+Pj0lEoBsleuK5TO6WHWELTnseoo/eWQBjQjKfNH8d09qle +tzzAY9wM/8dICafTXRJo1byzgLlsu+JP5P8+5WDFKD59myOjbEgJFP/D I=; X-IronPort-AV: E=Sophos;i="4.67,258,1309694400"; d="scan'208";a="73870465" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Jul 2011 16:39:17 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QlCwn-00065h-Gr; Mon, 25 Jul 2011 16:39:17 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QlCwn-0001ik-5z; Mon, 25 Jul 2011 16:39:17 +1200 From: Peter Gutmann To: anders.rundgren@telia.com, pkix@ietf.org In-Reply-To: <4E2C523E.9010509@telia.com> Message-Id: Date: Mon, 25 Jul 2011 16:39:17 +1200 Subject: Re: [pkix] Certificate Renewals in PKIX Protocols 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, 25 Jul 2011 04:39:19 -0000 Anders Rundgren writes: >If you create an initial certificate for a smart card in a trusted >environment you you should be able to tell with a high certainty that the >key- pair actually was created in the smart card, right? Not necessarily. In some cases the keys are generated externally and loaded into the card to save time. (This was a serious problem a while back when I refused to accept keys that weren't generated on the card, at which point I found out just how many cards did their keygen on the host PC (in the card driver) because doing it on the card was too slow. Some drivers also lied about this, claiming on-card generation when it was on the host PC). Peter. From matt@mattmccutchen.net Sun Jul 24 21:43:50 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23EE21F86C4 for ; Sun, 24 Jul 2011 21:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3KZC4VaVTqK for ; Sun, 24 Jul 2011 21:43:50 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9FF21F86BD for ; Sun, 24 Jul 2011 21:43:50 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id D246B348070; Sun, 24 Jul 2011 21:43:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=r++t+qqOlk47GTFA6UZ28egBKezw7YqxCjjBtdMElpY 8BhbE+ZPWTSi/PD9TiVEcy3XjOIxC2RQaMBugURR7f/7YHmGL7Nr143Su15fQFc2 uikLqUU3VP8mwXKIOrxGYgwrPQZHlvXfbREujAr5PIMkQToa+YbWVR0Bp27Mok8Y = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=wkxh8ybPKgVSKvyoaFlMSs2JxHM=; b=FwHpawL7Oe iAKAS2qNfsvvtikBjrfPIh6CqaAGzwA2fGrUpkQn0YntpIyi1lOl9wBOKUFfMYJ6 nnLAyyeVGYuYfxJ+CJw2M9c4Tse/ABf/3mW+0/STzT9JQey9n+9jXgfWlxfolHT6 lL8k4XR5oDuVtnSoIcnha6Vn2XG4dfxv4= Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPSA id 55A1034806F; Sun, 24 Jul 2011 21:43:49 -0700 (PDT) From: Matt McCutchen To: Massimiliano Pala In-Reply-To: <4E2C8B17.3080803@isis.poly.edu> References: <4E2C8B17.3080803@isis.poly.edu> Content-Type: text/plain; charset="UTF-8" Date: Mon, 25 Jul 2011 00:43:45 -0400 Message-ID: <1311569025.10022.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: [pkix] Tangent: browsers (Re: Which is the new KPI research that is telling us how PKI is going on?) 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, 25 Jul 2011 04:43:50 -0000 On Sun, 2011-07-24 at 17:13 -0400, Massimiliano Pala wrote: > Think about the case where simple http connections (no SSL/TLS) are displayed, > to the user, more trustworthy than non-trusted https (SSL/TLS) once.. Bad.. Bad.. > Bad.. browsers and who took such bad decisions.. !!! Read https://bugzilla.mozilla.org/show_bug.cgi?id=566008#c10 and you will understand why this is. -- Matt From roberto@opazo.cl Sun Jul 24 21:45:06 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F5621F86FF for ; Sun, 24 Jul 2011 21:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7YTxVKprSVZ for ; Sun, 24 Jul 2011 21:45:06 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2868921F8743 for ; Sun, 24 Jul 2011 21:45:06 -0700 (PDT) Received: by qwc23 with SMTP id 23so2930024qwc.31 for ; Sun, 24 Jul 2011 21:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opazo.cl; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wZRPQC1SGWbWSMZDwvtW/L9PNq1IlkljJmyPBh1uE3I=; b=oEd26WXf4fImgkNUsmGWmIJXZmo5OeQ4VDkZ3m98DNMvvRR/rXYoxd5rzclWMCDUsq /5QdN/NLij+p6PtTU7sj3qZNrcuCo35kkXZtbEF8igcSN/DPGaQMY7m5WF24jaiWdcpe gx62tUktG5HysK8yEP1oqRMOf90iDFEAhFBbo= MIME-Version: 1.0 Received: by 10.229.25.13 with SMTP id x13mr395qcb.130.1311569105594; Sun, 24 Jul 2011 21:45:05 -0700 (PDT) Received: by 10.229.88.134 with HTTP; Sun, 24 Jul 2011 21:45:05 -0700 (PDT) In-Reply-To: References: <7E9CC5CB-E02B-41DF-A357-10E5222C2DAB@cisco.com> Date: Mon, 25 Jul 2011 00:45:05 -0400 Message-ID: From: Roberto Opazo To: Peter Gutmann Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 04:45:07 -0000 Peter, Stephen: Thanks a lot I=92ll follow this references. 2011/7/25 Peter Gutmann : > Max Pritikin writes: > >>Even in that context client certificate use has lagged behind server >>certificate use. > > The reason why client certs have seen next to zero adoption is because of= the > issues given in my previous message. =A0For server certs you get your sys= admin > to set up the single cert that's needed in a once-a-year effort, and if i= t > takes him (usually a 'him' :-) two days of work to sort out then that's O= K. > That just doesn't work for end-users. =A0Client-side certs aren't used be= cause > they don't work (at the HCI level), not because of any organised action t= o > avoid them. > > Peter. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --=20 Saludos, Roberto Opazo From pgut001@login01.cs.auckland.ac.nz Sun Jul 24 21:49:06 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5F021F871E for ; Sun, 24 Jul 2011 21:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[AWL=-0.032, 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 H9TRHOjnHFTX for ; Sun, 24 Jul 2011 21:49:05 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id AB39921F86FF for ; Sun, 24 Jul 2011 21:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311569346; x=1343105346; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pala@isis.poly.edu,=20pkix@ietf.org|Subject:=20Re: =20[pkix]=20Which=20is=20the=20new=20KPI=20research=20tha t=20is=20telling=20us=20how=20PKI=20is=09going=20on? |In-Reply-To:=20<4E2C8B17.3080803@isis.poly.edu> |Message-Id:=20|Date:=20Mon,=2025=20Jul=202011=2016:49:04=20+1200; bh=xLy6W60S0NV2EIU2IVX086uFf4ImyHys7aSD4yQXfSQ=; b=ryvhpnD7+jKHLhZvQYznEE5Xa7IMQ2JavZYNKwt1iICd0gFvS3fWBcvP 2vmCyz0ixAGHnliFOZhbUzVjLpSVexO9QgrEDk0JIyY0gynOKDZYEPm6p zkvOGgsgYYlUYqfQGsriQM3AJcMi76733n3cwtoGnWe0qH2LMYGsfCZcQ U=; X-IronPort-AV: E=Sophos;i="4.67,258,1309694400"; d="scan'208";a="73874266" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Jul 2011 16:49:05 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QlD6G-0006Vo-Ij; Mon, 25 Jul 2011 16:49:04 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QlD6G-0002Zp-Lg; Mon, 25 Jul 2011 16:49:04 +1200 From: Peter Gutmann To: pala@isis.poly.edu, pkix@ietf.org In-Reply-To: <4E2C8B17.3080803@isis.poly.edu> Message-Id: Date: Mon, 25 Jul 2011 16:49:04 +1200 Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 04:49:06 -0000 Massimiliano Pala writes: >I would argue that that's more a failure of who is designing and developing >applications rather than who's issuing the certificates. Since the usability >of applications from this point of view is ridiculous, I would blame browser >vendors rather than PKIs in general - they failed their users with respect of >usability. Oh, absolutely. The CAs aren't in business for their health, they're in business to return a profit to shareholders. The way to do this is to minimise expenses (the less checking you do, the better) and maximise revenue (the more certs you sell, the better). I'm not faulting them for that, it would be economically irrational to run your business in any other manner. The problem isn't really the CAs, it's the browser vendors. According to the browser vendors, the only thing that can indicate "goodness" for a site is whether they've got a certificate. No matter how diligent and scrupulous a CA is in checking sites, the browsers treat their certs identically to the most negligent, unscrupulous CA of the lot (which incentivises the race to the bottom that we've already seen). What's more, any browser will happily take users to a site claiming to belong to a major bank that's hosted on a botnet running on a Windows XP Home machine in Kazakhstan and that contains drive-by Javascript-driven malware (pretty much every warning sign you can think of), but the only time they'll bother raising an alarm is if the site contains a non-commercial-CA-signed cerficate. (Blatant self-promotion: I'm doing a talk on this problem at EuroPKI in just over a month :-). Peter. From pgut001@login01.cs.auckland.ac.nz Sun Jul 24 22:25:38 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B130D21F86AF for ; Sun, 24 Jul 2011 22:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 HllGAmKt7AES for ; Sun, 24 Jul 2011 22:25:37 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 97AF121F866A for ; Sun, 24 Jul 2011 22:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311571538; x=1343107538; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20swilson@lockstep.com.au|Subject:=20Re:=20[pkix]=20 Which=20is=20the=20new=20KPI=20research=20that=20is=20tel ling=20us=20how=20PKI=20is=20going=20on?|Cc:=20pkix@ietf. org|In-Reply-To:=20<4E2CEF92.2020006@lockstep.com.au> |Message-Id:=20|Date:=20Mon,=2025=20Jul=202011=2017:25:28=20+1200; bh=GtfsNCRkS7DW8wJEtla6OeUYAtdapfPnyJsCWzQhrRA=; b=js2vh+m1V/CXz29ijPHJ+MZJKo1LsyuRjdbaQ5Xmp7jU2/7zpqhAr670 rydyWJ8+IxfsiwaL5wIdkxVn54o1Qa899g1arw9ZVRTAAtT8/wpEqw1/D QWFF8nBTpWMQ7gYGBLqmuzZsWJkyT96gqWtc7GE59fxV/qAqHzeP+1VIw c=; X-IronPort-AV: E=Sophos;i="4.67,258,1309694400"; d="scan'208";a="73883088" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Jul 2011 17:25:29 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QlDfU-0007rA-Ia; Mon, 25 Jul 2011 17:25:28 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QlDfU-0004nA-N2; Mon, 25 Jul 2011 17:25:28 +1200 From: Peter Gutmann To: swilson@lockstep.com.au In-Reply-To: <4E2CEF92.2020006@lockstep.com.au> Message-Id: Date: Mon, 25 Jul 2011 17:25:28 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 05:25:38 -0000 Stephen Wilson writes: >I think you will find comparable systems in ... > >- Scandinavia, using the "BankID" technology in cooperation between banks and >governments I'm not sure I'd use BankID as a good example, see "Weaknesses in BankID, a PKI-Substitute Deployed by Norwegian Banks" by Kristian Gjøsteen and "Risk Assessment of a National Security Infrastructure" by Kjell Hole et al. BankID is a quite bizarre infrastructure, the story I heard was that they intended to deploy client-side PKI, found it was more or less impossible, and then because of the existing investment couldn't throw away the PKI stuff so they buried it where it wouldn't have any effect while still being able to claim they were using PKI. Actually it's more a counterexample to client-side PKI use :-). >- Parts of Europe where e-invoicing using EU Qualified Digital Signatures and >keys (maybe Italy) That hasn't been such a success either. In Germany it's often preferable to do an end-run around the system than to jump through its endless hoops (I have refs for the numerous creative ways that users have come up with this, but they're all in German). >- Taiwan, where they have had a government issued PKI smartcard for B2G >transactions for a long time I don't have any third-party info on how well this is really doing in practice. I guess a generalisation of the above is that you'd need to look at third- party assessments of how something actually works, not reports by the people running the thing. In all of the above there are glowing assessments by the managers telling everyone how good a job they've done, and then when you look at independent, third-party assessments or user feedback on actually using the system you get a very different story. Peter. From anders.rundgren@telia.com Sun Jul 24 22:33:02 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16EB21F85C0 for ; Sun, 24 Jul 2011 22:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 T49BvpBnqRKz for ; Sun, 24 Jul 2011 22:33:01 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 378AE21F85B8 for ; Sun, 24 Jul 2011 22:33:01 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA03491A25; Mon, 25 Jul 2011 07:32:51 +0200 Message-ID: <4E2CFFF9.3090003@telia.com> Date: Mon, 25 Jul 2011 07:32:41 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Certificate Renewals in PKIX Protocols 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, 25 Jul 2011 05:33:02 -0000 On 2011-07-25 06:39, Peter Gutmann wrote: > Anders Rundgren writes: > >> If you create an initial certificate for a smart card in a trusted >> environment you you should be able to tell with a high certainty that the >> key- pair actually was created in the smart card, right? > > Not necessarily. In some cases the keys are generated externally and loaded > into the card to save time. > > (This was a serious problem a while back when I refused to accept keys that > weren't generated on the card, at which point I found out just how many cards > did their keygen on the host PC (in the card driver) because doing it on the > card was too slow. Some drivers also lied about this, claiming on-card > generation when it was on the host PC). > If the trusted environment is a card production facility this is IMO perfectly OK but that wasn't the issue. My question was really about *renewals* when the trust level is reduced, like in the field or when a device is doing unmanned renewals. A IMHO weird example of the latter is the ICAO/BSI scheme for EAC (Extended Access Control) used by all governments in the world (!) where they require that keys must reside in HSMs but be automatically renewed on a frequent basis. Since HSMs usually can't attest "I did this key" (and there is no place in the protocol for such an attestation either...), IMO makes the HSM "prescription" dubious since the renewal system isn't tamperproof. I may be wrong, but it *seems* that PKIX protocols lack support for secure renewals. Anders From anders.rundgren@telia.com Sun Jul 24 22:43:54 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD5C21F88DD for ; Sun, 24 Jul 2011 22:43:54 -0700 (PDT) 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.018, 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 LkxICICipul9 for ; Sun, 24 Jul 2011 22:43:53 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 89C9421F88DC for ; Sun, 24 Jul 2011 22:43:53 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F00787813; Mon, 25 Jul 2011 07:43:46 +0200 Message-ID: <4E2D0289.60707@telia.com> Date: Mon, 25 Jul 2011 07:43:37 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: pkix@ietf.org Subject: [pkix] BankID. Re: Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 05:43:54 -0000 BankID in Norway use server-side versions of client-PKI and let the users authentication with OTP or similar. BankID in Sweden use client-side PKI but since the "PC" platforms vendors do not support on-line enrollment of certificates in a reasonable way ("there is no business case"), they write their own browser PKI client and they are by far not alone doing that. There's obviously an *ocean* separating the different parties. This is the main motivation behind for the project earlier mentioned. Rather than waiting for the PKI equivalent of the middle-east conflict to end, "under the radar" build something that actually works! :-) Anders On 2011-07-25 07:25, Peter Gutmann wrote: > Stephen Wilson writes: > >> I think you will find comparable systems in ... >> >> - Scandinavia, using the "BankID" technology in cooperation between banks and >> governments > > I'm not sure I'd use BankID as a good example, see "Weaknesses in BankID, a > PKI-Substitute Deployed by Norwegian Banks" by Kristian Gjøsteen and "Risk > Assessment of a National Security Infrastructure" by Kjell Hole et al. BankID > is a quite bizarre infrastructure, the story I heard was that they intended to > deploy client-side PKI, found it was more or less impossible, and then because > of the existing investment couldn't throw away the PKI stuff so they buried it > where it wouldn't have any effect while still being able to claim they were > using PKI. > > Actually it's more a counterexample to client-side PKI use :-). > >> - Parts of Europe where e-invoicing using EU Qualified Digital Signatures and >> keys (maybe Italy) > > That hasn't been such a success either. In Germany it's often preferable to > do an end-run around the system than to jump through its endless hoops (I have > refs for the numerous creative ways that users have come up with this, but > they're all in German). > >> - Taiwan, where they have had a government issued PKI smartcard for B2G >> transactions for a long time > > I don't have any third-party info on how well this is really doing in > practice. > > I guess a generalisation of the above is that you'd need to look at third- > party assessments of how something actually works, not reports by the people > running the thing. In all of the above there are glowing assessments by the > managers telling everyone how good a job they've done, and then when you look > at independent, third-party assessments or user feedback on actually using the > system you get a very different story. > > Peter. > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From pgut001@login01.cs.auckland.ac.nz Sun Jul 24 22:44:38 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC3021F88DD for ; Sun, 24 Jul 2011 22:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 upCJZ+5s97RE for ; Sun, 24 Jul 2011 22:44:38 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0A63C21F88DC for ; Sun, 24 Jul 2011 22:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311572678; x=1343108678; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20anders.rundgren@telia.com,=20pgut001@cs.auckland.a c.nz|Subject:=20Re:=20[pkix]=20Certificate=20Renewals=20i n=20PKIX=20Protocols|Cc:=20pkix@ietf.org|In-Reply-To:=20< 4E2CFFF9.3090003@telia.com>|Message-Id:=20|Date:=20Mon,=2025=20Jul =202011=2017:44:37=20+1200; bh=tZcP5tzU80Zjc35JLJtBQCmC/vTwT2c6XO2cHnWaIoo=; b=kKI2mRDDkH5/gOgHshqd7W84qxKicnUPFCFncOgdROFKUMgVnxyMz+G6 qj3lR0taa3GueRJPD45vnONFM1J9FSLuTMTP7bPQmaSRL8AuODxDDpBC8 y2bHQXuQ0TKg6NjnKcMhdbghxqr7uGEP5K4ZD34F3MiywIaibS2fzUEws 8=; X-IronPort-AV: E=Sophos;i="4.67,258,1309694400"; d="scan'208";a="73886266" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Jul 2011 17:44:37 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QlDy1-0008Vl-Gw; Mon, 25 Jul 2011 17:44:37 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QlDy1-0005os-6P; Mon, 25 Jul 2011 17:44:37 +1200 From: Peter Gutmann To: anders.rundgren@telia.com, pgut001@cs.auckland.ac.nz In-Reply-To: <4E2CFFF9.3090003@telia.com> Message-Id: Date: Mon, 25 Jul 2011 17:44:37 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] Certificate Renewals in PKIX Protocols 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, 25 Jul 2011 05:44:39 -0000 Anders Rundgren writes: >I may be wrong, but it *seems* that PKIX protocols lack support for secure >renewals. What specifically do you mean by "support"? If you run the whole protocol in the HSM (or whatever) and sign the new request with the old key, then you've got what you want. You'd need some means of signalling this, either implicitly or via something like an OID in the request, but at that point it becomes an ecumen^H^H^H^Hpolicy matter. Peter. From anders.rundgren@telia.com Sun Jul 24 22:52:46 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0862921F8AD6 for ; Sun, 24 Jul 2011 22:52:46 -0700 (PDT) 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 PNQFnYJEOwZ8 for ; Sun, 24 Jul 2011 22:52:45 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 4227021F8AD1 for ; Sun, 24 Jul 2011 22:52:45 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F00787AE9; Mon, 25 Jul 2011 07:52:41 +0200 Message-ID: <4E2D049F.7040302@telia.com> Date: Mon, 25 Jul 2011 07:52:31 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Certificate Renewals in PKIX Protocols 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, 25 Jul 2011 05:52:46 -0000 On 2011-07-25 07:44, Peter Gutmann wrote: > Anders Rundgren writes: > >> I may be wrong, but it *seems* that PKIX protocols lack support for secure >> renewals. > > What specifically do you mean by "support"? If you run the whole protocol in > the HSM (or whatever) and sign the new request with the old key, then you've > got what you want. You'd need some means of signalling this, either > implicitly or via something like an OID in the request, but at that point it > becomes an ecumen^H^H^H^Hpolicy matter. Peter, a $5 TPM can attest authenticity of generated keys using cryptographic methods. It can't run networked protocols. I.e. the latter must "support" the TPM's attestation capability if you want secure (with respect to key origin...) renewals. Anders From pgut001@login01.cs.auckland.ac.nz Sun Jul 24 23:06:50 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175A222800F for ; Sun, 24 Jul 2011 23:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 tn2aAbbrXNzH for ; Sun, 24 Jul 2011 23:06:48 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 35CA222800D for ; Sun, 24 Jul 2011 23:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311574008; x=1343110008; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20anders.rundgren@telia.com,=20pgut001@cs.auckland.a c.nz|Subject:=20Re:=20[pkix]=20Certificate=20Renewals=20i n=20PKIX=20Protocols|Cc:=20pkix@ietf.org|In-Reply-To:=20< 4E2D049F.7040302@telia.com>|Message-Id:=20|Date:=20Mon,=2025=20Jul =202011=2018:06:45=20+1200; bh=mHq5PRP9frhQxwgqePLGSoShCsJwUVJOhozcF14XbBU=; b=lAff5HUSAnnMj8NnQLkzFO95FDAzOZigObMgkVTJyxxWcI8iI+BEx2h/ 8wpXI1dp752R81pjDCORW0tssw2GMyhu3RVtJ75Z1wyEryUUWwrYjTkij cEN4KU5omSRkm5mVl0a7l+IYnHtcLcC+WXH76Gkjrx36q4E0hhc9tCnA/ g=; X-IronPort-AV: E=Sophos;i="4.67,258,1309694400"; d="scan'208";a="73888405" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Jul 2011 18:06:46 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QlEJR-0000n3-J6; Mon, 25 Jul 2011 18:06:45 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QlEJR-00078P-SU; Mon, 25 Jul 2011 18:06:45 +1200 From: Peter Gutmann To: anders.rundgren@telia.com, pgut001@cs.auckland.ac.nz In-Reply-To: <4E2D049F.7040302@telia.com> Message-Id: Date: Mon, 25 Jul 2011 18:06:45 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] Certificate Renewals in PKIX Protocols 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, 25 Jul 2011 06:06:50 -0000 Anders Rundgren writes: >Peter, a $5 TPM can attest authenticity of generated keys using cryptographic >methods. It can't run networked protocols. I.e. the latter must "support" >the TPM's attestation capability if you want secure (with respect to key >origin...) renewals. But how would this work? Is there any OS, or environment, in which TPM attestation actually works? Or to use a more specific example, Joe Sixpack is running a Win7 laptop that happens to be one of the few with a TPM in it. Then what? Peter. From swilson@lockstep.com.au Sun Jul 24 23:07:34 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5422A11E8086 for ; Sun, 24 Jul 2011 23:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 eTrI3-6ptyrJ for ; Sun, 24 Jul 2011 23:07:33 -0700 (PDT) Received: from smtp182.dfw.emailsrvr.com (smtp182.dfw.emailsrvr.com [67.192.241.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1A24411E8084 for ; Sun, 24 Jul 2011 23:07:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp18.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id A4DB1268047; Mon, 25 Jul 2011 02:07:32 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp18.relay.dfw1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id 520172680A1; Mon, 25 Jul 2011 02:07:30 -0400 (EDT) Message-ID: <4E2D0818.3000900@lockstep.com.au> Date: Mon, 25 Jul 2011 16:07:20 +1000 From: Stephen Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Anders Rundgren , Peter Gutmann References: <4E2D0289.60707@telia.com> In-Reply-To: <4E2D0289.60707@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pkix@ietf.org Subject: Re: [pkix] BankID. Re: Which is the new KPI research that is telling us how PKI is going on? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 06:07:34 -0000 Peter: I certainly agree that BankID is problematic. I was only using it as an example of the vanilla personal certificate programs that Roberto is looking for. I maintain that none of these generic "Big PKI" programs are really very useful. Experience shows that no CA is going to warrant general purpose certificates for a nice wide range of apps. A particular limitation of BankID is that it has achieved a restricted form of federation between banks and governments by way of legislation. I suspect that it is riddled with fine print. Anders: I must say I find your rhetorical metaphors about the middle east, oceans and radars very confusing. Many of us are frustrated with (or bemused by) conventional PKI, but can we speak in plain language, not riddles please? I agree there are hardware and operating system level interoperability problems, and getting smartcards to work is not as easy as it should be. But I also remember when printers did not plug and play, and I remember when CDs had to be burned using special equipment. These problems were solved over time. I believe that the plastic card is such a universally easy to use form factor that in time, PC and OS vendors will solve these niggly issues, and that we will be able to do things like (a) pop an EMV card into a slot and do POS transactions over the Internet, or (b) use a smart health card to securely access Personal EHRs. See also http://www.abc.net.au/tv/newinventors/txt/s2423212.htm. Cheers, Steve Wilson On 25/07/2011 3:43 PM, Anders Rundgren wrote: > BankID in Norway use server-side versions of client-PKI > and let the users authentication with OTP or similar. > > BankID in Sweden use client-side PKI but since the "PC" platforms > vendors do not support on-line enrollment of certificates > in a reasonable way ("there is no business case"), they > write their own browser PKI client and they are by far not > alone doing that. > > There's obviously an *ocean* separating the different parties. > > This is the main motivation behind for the project earlier mentioned. > Rather than waiting for the PKI equivalent of the middle-east conflict > to end, "under the radar" build something that actually works! :-) > > Anders > > On 2011-07-25 07:25, Peter Gutmann wrote: >> Stephen Wilson writes: >> >>> I think you will find comparable systems in ... >>> >>> - Scandinavia, using the "BankID" technology in cooperation between banks and >>> governments >> >> I'm not sure I'd use BankID as a good example, see "Weaknesses in BankID, a >> PKI-Substitute Deployed by Norwegian Banks" by Kristian Gjøsteen and "Risk >> Assessment of a National Security Infrastructure" by Kjell Hole et al. BankID >> is a quite bizarre infrastructure, the story I heard was that they intended to >> deploy client-side PKI, found it was more or less impossible, and then because >> of the existing investment couldn't throw away the PKI stuff so they buried it >> where it wouldn't have any effect while still being able to claim they were >> using PKI. >> >> Actually it's more a counterexample to client-side PKI use :-). >> >>> - Parts of Europe where e-invoicing using EU Qualified Digital Signatures and >>> keys (maybe Italy) >> >> That hasn't been such a success either. In Germany it's often preferable to >> do an end-run around the system than to jump through its endless hoops (I have >> refs for the numerous creative ways that users have come up with this, but >> they're all in German). >> >>> - Taiwan, where they have had a government issued PKI smartcard for B2G >>> transactions for a long time >> >> I don't have any third-party info on how well this is really doing in >> practice. >> >> I guess a generalisation of the above is that you'd need to look at third- >> party assessments of how something actually works, not reports by the people >> running the thing. In all of the above there are glowing assessments by the >> managers telling everyone how good a job they've done, and then when you look >> at independent, third-party assessments or user feedback on actually using the >> system you get a very different story. >> >> Peter. >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > From anders.rundgren@telia.com Sun Jul 24 23:22:16 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7795621F8AF0 for ; Sun, 24 Jul 2011 23:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 K1o+yMyYiKdZ for ; Sun, 24 Jul 2011 23:22:16 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id ACE5D21F8AEA for ; Sun, 24 Jul 2011 23:22:15 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B00D8FDA5; Mon, 25 Jul 2011 08:22:11 +0200 Message-ID: <4E2D0B89.7030903@telia.com> Date: Mon, 25 Jul 2011 08:22:01 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Certificate Renewals in PKIX Protocols 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, 25 Jul 2011 06:22:16 -0000 On 2011-07-25 08:06, Peter Gutmann wrote: > Anders Rundgren writes: > >> Peter, a $5 TPM can attest authenticity of generated keys using cryptographic >> methods. It can't run networked protocols. I.e. the latter must "support" >> the TPM's attestation capability if you want secure (with respect to key >> origin...) renewals. > > But how would this work? Is there any OS, or environment, in which TPM > attestation actually works? Or to use a more specific example, Joe Sixpack is > running a Win7 laptop that happens to be one of the few with a TPM in it. > Then what? In order for something to happen it must (in addition to filling a need), also be technically feasible. In this particular case I claim that that there are fundamental things lacking, like attestation support in PKIX protocols. The majority of the 0.5 BN TPMs shipped had/have nothing to do. Anders From anders.rundgren@telia.com Sun Jul 24 23:33:35 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1127B21F85B5 for ; Sun, 24 Jul 2011 23:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 xF3s3WBiipBp for ; Sun, 24 Jul 2011 23:33:34 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id CCA9821F84FA for ; Sun, 24 Jul 2011 23:33:33 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F00788CBB; Mon, 25 Jul 2011 08:33:31 +0200 Message-ID: <4E2D0E31.1030105@telia.com> Date: Mon, 25 Jul 2011 08:33:21 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: swilson@lockstep.com.au References: <4E2D0289.60707@telia.com> <4E2D0818.3000900@lockstep.com.au> In-Reply-To: <4E2D0818.3000900@lockstep.com.au> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: pkix@ietf.org Subject: Re: [pkix] BankID. Re: Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 06:33:35 -0000 On 2011-07-25 08:07, Stephen Wilson wrote: > > Peter: I certainly agree that BankID is problematic. I was only using it > as an example of the vanilla personal certificate programs that Roberto > is looking for. I maintain that none of these generic "Big PKI" > programs are really very useful. Experience shows that no CA is going > to warrant general purpose certificates for a nice wide range of apps. > A particular limitation of BankID is that it has achieved a restricted > form of federation between banks and governments by way of legislation. > I suspect that it is riddled with fine print. > > Anders: I must say I find your rhetorical metaphors about the middle > east, oceans and radars very confusing. Many of us are frustrated with > (or bemused by) conventional PKI, but can we speak in plain language, > not riddles please? No riddles here: http://www.ietf.org/mail-archive/web/pkix/current/msg29497.html > I agree there are hardware and operating system level interoperability > problems, and getting smartcards to work is not as easy as it should > be. But I also remember when printers did not plug and play, and I > remember when CDs had to be burned using special equipment. These > problems were solved over time. I believe that the plastic card is such > a universally easy to use form factor that in time, PC and OS vendors > will solve these niggly issues, and that we will be able to do things > like (a) pop an EMV card into a slot and do POS transactions over the > Internet, or (b) use a smart health card to securely access Personal EHRs. > > See also http://www.abc.net.au/tv/newinventors/txt/s2423212.htm. Vendors are no better that their customers and for PKI the USG is primary customer (seen from a US vendor perspective) and the USG buys essentially one vendor's client OS. Combining the slowest customer group you can find, with a space where there is no competition doesn't exactly spur progress. The USG doesn't care s--t about consumer PKI, they never had such a program. I.e. "there is no business case". I heard it directly from the PMs so I should know... Naturally there will be local suppliers of unique solutions like BankID but how interesting is this? You are working in another segment, be happy for that :-) Anders > > Cheers, > > Steve Wilson > > > > On 25/07/2011 3:43 PM, Anders Rundgren wrote: >> BankID in Norway use server-side versions of client-PKI >> and let the users authentication with OTP or similar. >> >> BankID in Sweden use client-side PKI but since the "PC" platforms >> vendors do not support on-line enrollment of certificates >> in a reasonable way ("there is no business case"), they >> write their own browser PKI client and they are by far not >> alone doing that. >> >> There's obviously an *ocean* separating the different parties. >> >> This is the main motivation behind for the project earlier mentioned. >> Rather than waiting for the PKI equivalent of the middle-east conflict >> to end, "under the radar" build something that actually works! :-) >> >> Anders >> >> On 2011-07-25 07:25, Peter Gutmann wrote: >>> Stephen Wilson writes: >>> >>>> I think you will find comparable systems in ... >>>> >>>> - Scandinavia, using the "BankID" technology in cooperation between banks and >>>> governments >>> >>> I'm not sure I'd use BankID as a good example, see "Weaknesses in BankID, a >>> PKI-Substitute Deployed by Norwegian Banks" by Kristian Gjøsteen and "Risk >>> Assessment of a National Security Infrastructure" by Kjell Hole et al. BankID >>> is a quite bizarre infrastructure, the story I heard was that they intended to >>> deploy client-side PKI, found it was more or less impossible, and then because >>> of the existing investment couldn't throw away the PKI stuff so they buried it >>> where it wouldn't have any effect while still being able to claim they were >>> using PKI. >>> >>> Actually it's more a counterexample to client-side PKI use :-). >>> >>>> - Parts of Europe where e-invoicing using EU Qualified Digital Signatures and >>>> keys (maybe Italy) >>> >>> That hasn't been such a success either. In Germany it's often preferable to >>> do an end-run around the system than to jump through its endless hoops (I have >>> refs for the numerous creative ways that users have come up with this, but >>> they're all in German). >>> >>>> - Taiwan, where they have had a government issued PKI smartcard for B2G >>>> transactions for a long time >>> >>> I don't have any third-party info on how well this is really doing in >>> practice. >>> >>> I guess a generalisation of the above is that you'd need to look at third- >>> party assessments of how something actually works, not reports by the people >>> running the thing. In all of the above there are glowing assessments by the >>> managers telling everyone how good a job they've done, and then when you look >>> at independent, third-party assessments or user feedback on actually using the >>> system you get a very different story. >>> >>> Peter. >>> >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> >> > > From pgut001@login01.cs.auckland.ac.nz Sun Jul 24 23:59:28 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFD821F8AFF for ; Sun, 24 Jul 2011 23:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 CYjoxOBWNxiA for ; Sun, 24 Jul 2011 23:59:28 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id EDD7521F8AFD for ; Sun, 24 Jul 2011 23:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311577168; x=1343113168; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20anders.rundgren@telia.com,=20pgut001@cs.auckland.a c.nz|Subject:=20Re:=20[pkix]=20Certificate=20Renewals=20i n=20PKIX=20Protocols|Cc:=20pkix@ietf.org|In-Reply-To:=20< 4E2D0B89.7030903@telia.com>|Message-Id:=20|Date:=20Mon,=2025=20Jul =202011=2018:59:26=20+1200; bh=nGyosmR5JXu5VkX/cegNFJUaWojCpPQyqaIJx1qQELo=; b=eZuJptDtrH4NimO6P3sffP9QCLDdcp75QBFPP9n4JoHGTB9OBd/2qmbM L30kFDyVswCPe3RSgcZifeIUzKDWo/+7HEzESJhCZTOjVoWpRo/sz8dUE rZFi3bq2ncH07lUdJHYvfPB4XQ4mvL360KR1zAzI5QPGv0xwJAR2xcbdf E=; X-IronPort-AV: E=Sophos;i="4.67,259,1309694400"; d="scan'208";a="73894658" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Jul 2011 18:59:26 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QlF8Q-0002T3-H2; Mon, 25 Jul 2011 18:59:26 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QlF8Q-00016o-7t; Mon, 25 Jul 2011 18:59:26 +1200 From: Peter Gutmann To: anders.rundgren@telia.com, pgut001@cs.auckland.ac.nz In-Reply-To: <4E2D0B89.7030903@telia.com> Message-Id: Date: Mon, 25 Jul 2011 18:59:26 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] Certificate Renewals in PKIX Protocols 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, 25 Jul 2011 06:59:28 -0000 Anders Rundgren writes: >In order for something to happen it must (in addition to filling a need), >also be technically feasible. In this particular case I claim that that >there are fundamental things lacking, like attestation support in PKIX >protocols. You still haven't explained what it is that you're going to attest. PKIX protocols all have extension support so you can add your own extension with whatever semantics you want, but what're you going to attest? That a TPM was installed and powered on? >The majority of the 0.5 BN TPMs shipped had/have nothing to do. Only "the majority"? Peter. From anders.rundgren@telia.com Mon Jul 25 00:20:27 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0F921F85AC for ; Mon, 25 Jul 2011 00:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 e4XDLl4T4Znw for ; Mon, 25 Jul 2011 00:20:26 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 07CF721F84F0 for ; Mon, 25 Jul 2011 00:20:25 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B00D9319A; Mon, 25 Jul 2011 09:20:19 +0200 Message-ID: <4E2D1929.5050501@telia.com> Date: Mon, 25 Jul 2011 09:20:09 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Certificate Renewals in PKIX Protocols 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, 25 Jul 2011 07:20:27 -0000 On 2011-07-25 08:59, Peter Gutmann wrote: > Anders Rundgren writes: > >> In order for something to happen it must (in addition to filling a need), >> also be technically feasible. In this particular case I claim that that >> there are fundamental things lacking, like attestation support in PKIX >> protocols. > > You still haven't explained what it is that you're going to attest. TPM: "I did this key". With a dedicated attestation key. > "PKIX protocols all have extension support so you can add your own extension with > whatever semantics you want, This was essentially the answer I was looking for. I skimmed through the CMC RFC and didn't find a single reference to "middleware", "cryptographic module", or "container". PKIX: Yes, CMC is supposed to be entirely universal, stupid! AR: You mean it doesn't fit anything *really* well? Anders From pgut001@login01.cs.auckland.ac.nz Mon Jul 25 00:24:29 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8022221F8AED for ; Mon, 25 Jul 2011 00:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 uUiMinpsMshG for ; Mon, 25 Jul 2011 00:24:28 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 916FB21F8AD6 for ; Mon, 25 Jul 2011 00:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311578669; x=1343114669; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20anders.rundgren@telia.com,=20pgut001@cs.auckland.a c.nz|Subject:=20Re:=20[pkix]=20Certificate=20Renewals=20i n=20PKIX=20Protocols|Cc:=20pkix@ietf.org|In-Reply-To:=20< 4E2D1929.5050501@telia.com>|Message-Id:=20|Date:=20Mon,=2025=20Jul =202011=2019:24:26=20+1200; bh=YDZelPFQ2blnpxtLFrv5CP/4ADsOMU85zQVo/M/zTpk=; b=sz0gc7eKKfc8QKgdzhWrXAbhaAPr8z/TyoOJbOdsFvdNHll5RhObs5JR 0kWxSHpNaUrVynYfkaFyTyNzb3X2qU17CEhu5LEnF3Tr68d9WJs3cRCjv +nGtyuN1Qj4TH9iwuwVzRrWA1fFFTdjC+l0wxBa3cMlzh+ur0pd4V0fPX I=; X-IronPort-AV: E=Sophos;i="4.67,259,1309694400"; d="scan'208";a="73896571" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Jul 2011 19:24:27 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QlFWc-0003E0-IR; Mon, 25 Jul 2011 19:24:26 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QlFWc-0002oU-Ly; Mon, 25 Jul 2011 19:24:26 +1200 From: Peter Gutmann To: anders.rundgren@telia.com, pgut001@cs.auckland.ac.nz In-Reply-To: <4E2D1929.5050501@telia.com> Message-Id: Date: Mon, 25 Jul 2011 19:24:26 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] Certificate Renewals in PKIX Protocols 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, 25 Jul 2011 07:24:29 -0000 Anders Rundgren writes: >I skimmed through the CMC RFC and didn't find a single reference to >"middleware", "cryptographic module", or "container". Presumably because it's agnostic to that sort of thing. If you want attestation that the TPM did the key, define an extension consisting of sign( key hash, TPM ID ) or whatever you want. If the TPM can talk at a slightly higher level, you don't even need that, it can sign its ID into the PKCS #10 request. Peter. From anders.rundgren@telia.com Mon Jul 25 00:32:18 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C3D21F8AFA for ; Mon, 25 Jul 2011 00:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 29eP0j6Hh8j9 for ; Mon, 25 Jul 2011 00:32:17 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id B979321F8AF1 for ; Mon, 25 Jul 2011 00:32:17 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA03497ABD; Mon, 25 Jul 2011 09:32:16 +0200 Message-ID: <4E2D1BF6.9030307@telia.com> Date: Mon, 25 Jul 2011 09:32:06 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "pkix@ietf.org" , Roberto Opazo X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] "CertEnroll". Re: Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 07:32:18 -0000 Roberto, There's no need for deep studies to understand why simple PKI (=can be deployed as easy as passwords) is not happening. It is enough looking at "CertEnroll" that is shipped with the OS that on average has 80% of the "PC" market. "CertEnroll" (and its underpinnings), doesn't meet any reasonable expectations, regardless if you are interested in functionality, security, privacy, or platform neutrality. My guess is that BankID have more users of their proprietary enrollment system than Microsoft's counterpart has globally. Anders From anders.rundgren@telia.com Mon Jul 25 00:37:13 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683CE21F8B00 for ; Mon, 25 Jul 2011 00:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 9OJwkNj9oCa0 for ; Mon, 25 Jul 2011 00:37:12 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id C406121F850E for ; Mon, 25 Jul 2011 00:37:12 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F0078B5D4; Mon, 25 Jul 2011 09:37:11 +0200 Message-ID: <4E2D1D1D.1030708@telia.com> Date: Mon, 25 Jul 2011 09:37:01 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "pkix@ietf.org" , Roberto Opazo X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] TLS client cert auth. Re: Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 07:37:13 -0000 Roberto, There's no need for deep studies to understand why simple PKI (=can be deployed as easy as passwords) is not happening. TLS client-cert-authentication as implemented in browsers is a really bad system, there's not even a "logout" mechanism! "Clear SSL state" or similar browser features do not work for any but experts. I don't believe that TLS-c-c-a will ever become mainstream, it will remain a mechanism for static secure tunnels between computers. Anders From peter.sylvester@edelweb.fr Mon Jul 25 00:57:24 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8547B21F89A1 for ; Mon, 25 Jul 2011 00:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 mtdlfRX9m804 for ; Mon, 25 Jul 2011 00:57:24 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id E5D4D21F87C5 for ; Mon, 25 Jul 2011 00:57:23 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id CF9C77FF4 for ; Mon, 25 Jul 2011 09:57:22 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 9F19E1702C for ; Mon, 25 Jul 2011 09:57:22 +0200 (CEST) Received: from [78.251.54.39] (unknown [78.251.54.39]) by smtps.on-x.com (Postfix) with ESMTP id 746BC782B for ; Mon, 25 Jul 2011 09:57:22 +0200 (CEST) Message-ID: <4E2D21E1.3030709@edelweb.fr> Date: Mon, 25 Jul 2011 09:57:21 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: "'pkix@ietf.org'" References: <4E2C8B17.3080803@isis.poly.edu> <4E2CEF92.2020006@lockstep.com.au> In-Reply-To: <4E2CEF92.2020006@lockstep.com.au> Content-Type: multipart/alternative; boundary="------------090008040708050704090509" Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 07:57:24 -0000 This is a multi-part message in MIME format. --------------090008040708050704090509 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit hi, > - Parts of Europe where e-invoicing using EU Qualified Digital Signatures and keys (maybe Italy) last year a EU directive 2006/112/EC amendment as removed the requirement for signatures (I guess because of the high percentage of electronic invoices that are exchanged since decades without anything like that). /The authenticity of the origin, the integrity of the content and the legibility of an invoice, whether in paper or in electronic form, shall be ensured from the point in time of issue until the end of the period for storage of the invoice. This may be achieved by any business controls which create a reliable audit trail between an invoice and a supply of goods or services/ Peter --------------090008040708050704090509 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit hi,

- Parts of Europe where e-invoicing using EU Qualified Digital Signatures and keys (maybe Italy)
last year a EU directive 2006/112/EC amendment as removed the requirement
for signatures (I guess because of the high percentage of electronic invoices
that are exchanged since decades without anything like that).

The authenticity of the origin, the integrity of the content and the legibility of an invoice, whether in paper or in electronic form, shall be ensured from the point in time of issue until the end of the period for storage of the invoice. This may be achieved by any business controls which create a reliable audit trail between an invoice and a supply of goods or services

Peter
--------------090008040708050704090509-- From ggm+ietf@apnic.net Mon Jul 25 01:09:10 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5161F21F8B10 for ; Mon, 25 Jul 2011 01:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1ib12o+FQdp for ; Mon, 25 Jul 2011 01:09:09 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0B521F89C1 for ; Mon, 25 Jul 2011 01:09:09 -0700 (PDT) Received: from dhcp-40ae.meeting.ietf.org (unknown [130.129.64.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2AEAFB691B for ; Mon, 25 Jul 2011 18:09:05 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: George Michaelson In-Reply-To: <4E2D21E1.3030709@edelweb.fr> Date: Mon, 25 Jul 2011 04:08:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E2C8B17.3080803@isis.poly.edu> <4E2CEF92.2020006@lockstep.com.au> <4E2D21E1.3030709@edelweb.fr> To: pkix@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 08:09:10 -0000 ATO PKI in Australia is not mandatory. You can manage to find = intermediaries to work on your behalf without having first-class direct = entry access only via PKI. (willing to be corrected on that one, but = thats my current understanding. It may differ for BI level tax = operations but when I did GST submit for a not-for-profit and that was = AFTER PKI rollout, I didn't need to use the PKI to submit my GST returns = then) at least one Australian client-side bank PKI was mandated 'we make the = keys' which shipped to you on a 3.5" floppy. A frisson there. Thank = goodness for the security of write-enable tabs! (not) I think the HCI factors are true. Whoever posted "there is no logout" = said something which has been nagging me for years and years. Why are = all browsers so crap at letting you securely dis-associate from your = bindings made with your ID? I have also recently been musing on the shipped list of TA. Its unfair = to objectify a single recent TA installation. In fact, I think we've = been terribly remiss in accepting ab-initio ANY installed TA state. = Classic chicken-and-egg: nobody was going to accept the HCI implications = of hand installing an OOB TA blob, but we've wound up blithely = *believing* the 'trusted' flags which emit from a system which = pre-shipped to us with certain assumptions wired in that are never = exposed to us in a way we can really make sense of. As an ex-GOSIP days OSI person, can I make one plea to remind people = some behaviours in this space vest from models of what we think we know = about structured nameforms from a time when the global Internet was = counted in thousands, and scaling problems related to the 3M computer: a = Meg of memory, a Megapixel and 1 MHZ of CPU... -G= From pgut001@login01.cs.auckland.ac.nz Mon Jul 25 01:28:08 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCE321F86B1 for ; Mon, 25 Jul 2011 01:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.624 X-Spam-Level: X-Spam-Status: No, score=-3.624 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 bY+xIyA7n43K for ; Mon, 25 Jul 2011 01:28:08 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id A8DC621F85FF for ; Mon, 25 Jul 2011 01:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311582488; x=1343118488; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20peter.sylvester@edelweb.fr,=20pkix@ietf.org |Subject:=20Re:=20[pkix]=20Which=20is=20the=20new=20KPI =20research=20that=20is=20telling=20us=20how=20PKI=20is =20going=20on?|In-Reply-To:=20<4E2D21E1.3030709@edelweb.f r>|Message-Id:=20|Date:=20Mon,=2025=20Jul=202011=2020:28:04=20+1200; bh=jNzC48EOCPoNhuYGPQcgPRuu9RH0la4kZWzsRoWdTkU=; b=GgOrPHnaKzsIhoP4bkccdMCBv47fe2ojprl+EwXGgJ20xkMhi1l/Qng6 fj1MjShXJE92hDjO3iCwdvp+KcLF//5P8wSWUfTYPrYVulH681v6M4IcH i+LVmNz3UHrBAX819BH3/7l67mJQSoAsywtn90WX/00oXDO8GvZ/WJ9uJ w=; X-IronPort-AV: E=Sophos;i="4.67,259,1309694400"; d="scan'208";a="73901414" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Jul 2011 20:28:04 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QlGWC-00055H-Gy; Mon, 25 Jul 2011 20:28:04 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QlGWC-000665-7M; Mon, 25 Jul 2011 20:28:04 +1200 From: Peter Gutmann To: peter.sylvester@edelweb.fr, pkix@ietf.org In-Reply-To: <4E2D21E1.3030709@edelweb.fr> Message-Id: Date: Mon, 25 Jul 2011 20:28:04 +1200 Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 08:28:08 -0000 Peter Sylvester writes: >/The authenticity of the origin, the integrity of the content and the >legibility of an invoice, whether in paper or in electronic form, shall be >ensured from the point in time of issue until the end of the period for >storage of the invoice. This may be achieved by any business controls which >create a reliable audit trail between an invoice and a supply of goods or >services/ Thus the suggestion made in one German article on the topic that the most effective actual mechanism for complying with the law is (and I quote): find | xargs cat | lpr (from "Gesetzgeber laesst Anwender im Regen stehen", Nils Magnus). Peter. From anders.rundgren@telia.com Mon Jul 25 02:00:11 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B1621F8AAC for ; Mon, 25 Jul 2011 02:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 5mKdUdFBT4Fx for ; Mon, 25 Jul 2011 02:00:10 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4A50021F8B38 for ; Mon, 25 Jul 2011 02:00:10 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B00D9B1C4; Mon, 25 Jul 2011 11:00:05 +0200 Message-ID: <4E2D308A.8000209@telia.com> Date: Mon, 25 Jul 2011 10:59:54 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: George Michaelson References: <4E2C8B17.3080803@isis.poly.edu> <4E2CEF92.2020006@lockstep.com.au> <4E2D21E1.3030709@edelweb.fr> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 09:00:11 -0000 On 2011-07-25 10:08, George Michaelson wrote: > I think the HCI factors are true. Whoever posted "there is no logout" said > something which has been nagging me for years and years. Why are all > browsers so crap at letting you securely dis-associate from your bindings > made with your ID? Here is my take on your question: - The browser vendors have mainly US origin - Their primary "home market" for PKI is the US Government - The US government isn't working with "PKI for people" but with things that are more related to Homeland Security The USGs newly formed NSTIC program will fail unless they understand that what you call the HCI factors, needs a lot more attention, maybe even fundamental changes in schemes that security experts claim are "ready". HTTPS using client certificates will IMO never become mainstream unless the protocol is augmented with an interoperable logout solution. This may not be a problem because many deployers have already replaced this with "homebrewed" solutions since they anyway was forced writing their own enroll and signature solution. Anders From pritikin@cisco.com Mon Jul 25 06:08:05 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4676721F8A64 for ; Mon, 25 Jul 2011 06:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQkZ7yPLFGng for ; Mon, 25 Jul 2011 06:08:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7894221F8A55 for ; Mon, 25 Jul 2011 06:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=1941; q=dns/txt; s=iport; t=1311599284; x=1312808884; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=PsylKwTqMSUW71FyDPT1UPDal5bYY4EjQ70ucdpe+mI=; b=ZEvAGtT802wfsqGGSAzqOZNnPHuyl2D/VIZEm3cuh80+WO3xPvNPBqij djhf4zvWoiTrB+JyAqM/21PSLbwaW5UYiV2sLYYcPsrp8lHjv6mdRjWTw b4q4Ybkzvxu2w2hXunq5F5TajK6X9Ez+x6fS6Qswf4Ohx6GB2XMjwFMh0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADtqLU6tJXG9/2dsb2JhbAA0AQEBAQIBAQEBEQErOgsFDAwvIxQYOQcXIAenMHeIfASiIJ1wgySCPF8Eh1WLG5B/ X-IronPort-AV: E=Sophos;i="4.67,261,1309737600"; d="scan'208";a="6105664" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 25 Jul 2011 13:08:04 +0000 Received: from rtp-vpn3-304.cisco.com (rtp-vpn3-304.cisco.com [10.82.217.50]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6PD83Dj028410; Mon, 25 Jul 2011 13:08:03 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: <4E2C523E.9010509@telia.com> Date: Mon, 25 Jul 2011 07:08:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E2C523E.9010509@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1084) Cc: "pkix@ietf.org" Subject: Re: [pkix] Certificate Renewals in PKIX Protocols 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, 25 Jul 2011 13:08:05 -0000 On Jul 24, 2011, at 11:11 AM, Anders Rundgren wrote: > This is a question to the list. >=20 > If you create an initial certificate for a smart card in a trusted = environment you > you should be able to tell with a high certainty that the key-pair = actually was > created in the smart card, right? Effectively the card must have an identity it can assert. The approach = I've taken here is to assume a device certificate held by the card = itself (something like IEEE 802.1AR). Thus the enrollment protocol needs = to be able to leverage that ID in addition to the user's identity. > Now, if you perform a certificate renewal, the original key is = supposed to > vouch for the authenticity of the request, right? Here I feel = slightly less > convinced since anybody can create a key-pair and get it signed. >=20 > Does any of the PKIX enrollment protocols support secure renewals in > the field? Is it even possible without having an attestation = mechanism > that is securely distinguishable from ordinary signatures? CMC doesn't define renew well although it can be implemented. CMP does a = better job in this regard, but your concern seems to be less about the = actual messages than how to use the messages when combined with a smart = card. The SCEP implementations such as the iphone solution you've = provided links to provides something that meets your initial certificate = using a particular device (iphone instead of smart card) but SCEP does a = very poor job as CA rekey. I think we have the technology pieces in the various pkix protocols but = not a clean discussion of how they should be used. (Thus my interest in = EST, as a profile for clarification rather than inventing a bunch of new = stuff). - max >=20 > Anders >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From kent@bbn.com Mon Jul 25 06:39:38 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0968321F8713 for ; Mon, 25 Jul 2011 06:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFJMPRi+leH2 for ; Mon, 25 Jul 2011 06:39:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB2021F862F for ; Mon, 25 Jul 2011 06:39:37 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39897 helo=[130.129.71.153]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QlLNg-000DII-7P for pkix@ietf.org; Mon, 25 Jul 2011 09:39:36 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 25 Jul 2011 09:39:34 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] draft-ietf-pkix-rfc5272-bis-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 13:39:38 -0000 Folks, Jim has posted a revised version of this doc, with a brief secruity considerations section. The SC section cites 5273 and 5274, and notes that a few change appear in section 2.12 of this version. Please review this SC section and section 2.12 and comment on the list if there are any concerns. Thanks, Steve From kent@bbn.com Mon Jul 25 09:12:29 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A6911E816A for ; Mon, 25 Jul 2011 09:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.548 X-Spam-Level: X-Spam-Status: No, score=-106.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvudD14QkWkM for ; Mon, 25 Jul 2011 09:12:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8647621F8610 for ; Mon, 25 Jul 2011 07:52:22 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57037 helo=[130.129.71.153]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QlMW6-000NaN-38 for pkix@ietf.org; Mon, 25 Jul 2011 10:52:22 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 25 Jul 2011 10:51:07 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] thanks 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, 25 Jul 2011 16:12:29 -0000 To all presenters for getting slides to me. They are available for viewing at the IETF 81 web site. Steve From anders.rundgren@telia.com Mon Jul 25 09:22:45 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5D721F8540 for ; Mon, 25 Jul 2011 09:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 O78TxQ2D0LRO for ; Mon, 25 Jul 2011 09:22:44 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 51E3121F84CF for ; Mon, 25 Jul 2011 09:22:38 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F007A4690; Mon, 25 Jul 2011 18:22:35 +0200 Message-ID: <4E2D9840.7050304@telia.com> Date: Mon, 25 Jul 2011 18:22:24 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Max Pritikin References: <4E2C523E.9010509@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Certificate Renewals in PKIX Protocols 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, 25 Jul 2011 16:22:45 -0000 On 2011-07-25 15:08, Max Pritikin wrote: > I think we have the technology pieces in the various pkix > protocols but not a clean discussion of how they should be used. It all depends on what your target audience is. It is not mentioned in the EST draft. > (Thus my interest in EST, as a profile for clarification rather > than inventing a bunch of new stuff). Inventing a bunch of new stuff may turn out to be easier than [insanely] extending something that was designed in another time and for another purpose. For some people new options mean "an opportunity" for other people it means just "another way of screwing up". The trust anchor stuff recently discussed is an example. According to Dr. Kent vendors SHOULD (or MUST) also support TAs that are not X.509 certificates. However, only a tiny fraction do that. Who is wrong, the RFC or the Vendors? >From my user/vendor perspective the RFC is wrong. There MAY be other TA forms had been more reasonable. Anders From tmiller@mitre.org Mon Jul 25 11:26:36 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC2121F8B19 for ; Mon, 25 Jul 2011 11:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7HUoeE1PZJS for ; Mon, 25 Jul 2011 11:26:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id CF80821F8B05 for ; Mon, 25 Jul 2011 11:26:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3B2AC21B1D6B; Mon, 25 Jul 2011 14:26:35 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2C7B621B1C70; Mon, 25 Jul 2011 14:26:35 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Mon, 25 Jul 2011 14:26:34 -0400 From: "Miller, Timothy J." To: Roberto Opazo Date: Mon, 25 Jul 2011 14:26:32 -0400 Thread-Topic: [pkix] Which is the new KPI research that is telling us how PKI is going on? Thread-Index: AcxK+GGAoVSS74l/TY2CSigMXlDsOw== Message-ID: <7D0315D5-F403-4692-9909-1799517E778D@mitre.org> References: <4E2C8B17.3080803@isis.poly.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-1-451227031"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 25 Jul 2011 18:26:36 -0000 --Apple-Mail-1-451227031 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 24, 2011, at 10:26 PM, Roberto Opazo wrote: > I=92m thinking in PKI used to authenticate people. Not web servers or > invisible certificates for devices or applications. I support a 10+ year old X.509 PKI with 4+ million users performing = multiple authentication operations per day in many different contexts, = from site and system authentication to legal document signing. But even = with multiple bridging arrangements it's still accurate to call it a = closed community. Success is all in how you measure. -- T --Apple-Mail-1-451227031 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA3MjUxODI2MzJaMCMGCSqGSIb3DQEJBDEWBBQPtJrOYp3PnEAcVOnO Ii/s3MCIUzByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgImqxUg7MUZsFbzixTAQ6b+Rq36x+YCLR839 mZ+t3zcJ0mXbcIF0t4UA6rNQcq0OxUqV87fl7ttygFtMG0PPC/J/u3n5FYvLwtO4vA4Z/0K3hqiQ GjrbGNspJD9PFvIL5QCb5p/c2wnsEuughCsOFLj0a7LEN5tmRI8Lhl85H5m5AAAAAAAA --Apple-Mail-1-451227031-- From kent@bbn.com Mon Jul 25 11:43:26 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2456F21F8BE4 for ; Mon, 25 Jul 2011 11:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYGjkce8zhBS for ; Mon, 25 Jul 2011 11:43:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id AA27521F8AA8 for ; Mon, 25 Jul 2011 11:43:25 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37801 helo=[130.129.18.170]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QlQ7h-000HQc-7I for pkix@ietf.org; Mon, 25 Jul 2011 14:43:25 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 25 Jul 2011 14:43:23 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] minutes 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, 25 Jul 2011 18:43:26 -0000 the first draft if the minutes has been posted. Please send comments, corrections, etc. to me. Thanks, Steve From kent@bbn.com Mon Jul 25 11:44:59 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01E021F8C0B for ; Mon, 25 Jul 2011 11:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PKZxc0yQz1F for ; Mon, 25 Jul 2011 11:44:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id ED32121F8BDF for ; Mon, 25 Jul 2011 11:44:58 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37805 helo=[130.129.18.170]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QlQ96-000HRo-4U for pkix@ietf.org; Mon, 25 Jul 2011 14:44:52 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 25 Jul 2011 14:44:50 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] well, ... 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, 25 Jul 2011 18:44:59 -0000 Meeting material manager is having problems, so minutes are not yet posted ... Steve From swilson@lockstep.com.au Mon Jul 25 11:50:31 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B6521F8C26 for ; Mon, 25 Jul 2011 11:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 rRs7aEuguIVc for ; Mon, 25 Jul 2011 11:50:30 -0700 (PDT) Received: from smtp142.dfw.emailsrvr.com (smtp142.dfw.emailsrvr.com [67.192.241.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA4A21F8C0B for ; Mon, 25 Jul 2011 11:50:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp14.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id B8223298498; Mon, 25 Jul 2011 14:50:29 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp14.relay.dfw1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id 4737F2983D5; Mon, 25 Jul 2011 14:50:27 -0400 (EDT) Message-ID: <4E2DBA93.1010802@lockstep.com.au> Date: Tue, 26 Jul 2011 04:48:51 +1000 From: Stephen Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Miller, Timothy J." References: <4E2C8B17.3080803@isis.poly.edu> <7D0315D5-F403-4692-9909-1799517E778D@mitre.org> In-Reply-To: <7D0315D5-F403-4692-9909-1799517E778D@mitre.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 18:50:31 -0000 On 26/07/2011 4:26 AM, Miller, Timothy J. wrote: > I support a 10+ year old X.509 PKI with 4+ million users performing > multiple authentication operations per day in many different contexts, > from site and system authentication to legal document signing. But > even with multiple bridging arrangements it's still accurate to call > it a closed community. No "buts"! At some scale, and in some dimension, all applications are closed. For instance, the Visa/MasterCard system is closed even if it covers the globe. Closure is a good thing! We need boundaries on what digital certificates mean, and what they may be used for. The vain pursuit of "open" PKI is one of the things that made Big PKI overly complicated, and it still distracts people. People think PKI has failed because you cannot get a certificate that proves who you are without qualification on every cyber domain. Cheers, Steve Wilson Lockstep http://lockstep.com.au/library/pki From kent@bbn.com Mon Jul 25 14:29:40 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D9F21F86A4 for ; Mon, 25 Jul 2011 14:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGiPIDan9122 for ; Mon, 25 Jul 2011 14:29:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id EE66221F869E for ; Mon, 25 Jul 2011 14:29:39 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58502 helo=[130.129.71.153]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QlSiY-0004dJ-Hu for pkix@ietf.org; Mon, 25 Jul 2011 17:29:38 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 25 Jul 2011 17:26:33 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] another doc for WG consideration 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, 25 Jul 2011 21:29:40 -0000 There was a presentation on extending CMC to accommodate scenarios in which a CA/AR generates the key pair for the subject. I'd like to hear comments from the WG about adopting this as a work item as well. Steve From kent@bbn.com Mon Jul 25 14:29:41 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A6421F869E for ; Mon, 25 Jul 2011 14:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPX4nj+RPAE0 for ; Mon, 25 Jul 2011 14:29:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1864021F86A0 for ; Mon, 25 Jul 2011 14:29:40 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58502 helo=[130.129.71.153]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QlSiZ-0004dJ-Cu for pkix@ietf.org; Mon, 25 Jul 2011 17:29:39 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 25 Jul 2011 17:29:34 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-900493117==_ma============" Subject: [pkix] minutes, old style 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, 25 Jul 2011 21:29:41 -0000 --============_-900493117==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" PKIX WG Meeting July 25, 2011 Edited by Steve Kent Co-Chairs: Stephen Kent Stefan Santesson The PKIX WG met once, for 2 hours, during the 81st IETF. A total of approximately 41 individuals participated in the meeting. Document Status Review - Steve Kent (BBN Technologies) There has been significant progress in document status since the previous meeting. - 2 new RFCs published since Prague (6170 & 6277) - 0 documents in the RFC Editor's queue: certificate-image & OCSP agility - 0 documents in IESG processing - 7 I-Ds in process in the WG: CMC Updates (WGLC done, awaiting security considerations review, 5280 clarifications, OCSP Update, Transport Protocols for CMP, Internet mail addresses in X.509, S/MIME Capabilities for public keys, CAA - 1 non-WG document to be discussed: EST (certificate Enrollment over Secure Transport) (Slides) PKIX WG Documents DNS Certification Authority Authorization (CAA) Resource Record- Phillip Hallam-Baker (Comodo) The I-D is intended to address the problem that arises due to the potential for an arbitrary CA (among the set of trust anchors embedded in many browsers, and OSes), to issue a certificate for any arbitrary web site. The proposed means of addressing this problem is to augment the DNS RR for a web site with info identifying the CA that has been authorized to issue an X.509 certificate for the web site in question. The current draft does not address issues such as CA accountability, of client (RP) validation of this info. The principle rationale for this added DNS data is to enable the major public CAs to detect when a "rogue" CA issues a certificate inappropriately. (PHB says that the major public CA players regularly scan the DNS and would detect such behavior.) There are a number of details still to be worked out, which are noted in the slides. At the microphone, suggestions were offered for improving the readability of the document, and asking why RPs are explicitly warned to not make use of this record. There is a sense that the document needs to be extensively re-written, to better present the rationale for this work, and explain why web site users (and the public TA set) would be motivated to make use of this technology. There is agreement that DNSSEC is not strictly required for these records, although it would be helpful, e.g., for accountability. (Slides) Comments on CAA - Paul Hoffman (VPN Consortium) Paul's slides address two issues in the CAA draft. He wants to see the RP text be removed, period. His other concern is how a CA is identified in the CAA record. Paul suggests use of free form text (in UTF8) to identify the CA. This is very flexible, and accommodates the various types of IDs that Phillip noted. This approach is potentially ambiguous, complicates checking by CAs, but does make life easier for DNS administrators/users. Paul explicitly wants to make life easier for the latter class, because it is much, much bigger. At the microphone, comments were against adopting only the free text form of CA ID, worries about use of UTF8, etc. Also, given the extensive use of RAs, under various TAs, there is potential for a lot of confusion and ambiguity that may undermine some of the security guarantees. All of this is viewed as useful input to the next version of the CAA document. (slides) Presentations on non-WG Topics (seeking WG adoption) Enrollment Over Secure Transport- Max Pritkin (Cisco) This document proposes a new, simplified certificate issuance protocol, based on the simple CMC message formats. The protocol relies on messages being carried over TLS to achieve security between the client and a CA (or RA). The current version contains a requirements section that can be moved to a separate document. One of the principle changes in the most recent version of EST is inclusion of a PoP capability. The PoP method adopted here is based on channel-binding derived from the TLS session. This requires access to the TLS layer, to acquire this data. This method requires a CA to rely on an RA to have verified the PoP data, and pass it on to te CA, if the client does not establish a direct TLS connection to the CA. Also, the "attested" method of PoP is included here to enable a device to use a manufacturer-issued certificate to be a basis for issuance of another certificate. A straw poll of attendees showed most were in favor of adopting EST as WG item, with no one objecting. Steve said he would ask for adoption on the PKIX list. (Slides) CMC Extensions: Server Side Key Generation & Key Escrow- Sean Turner (IECA) This document is a resurrection of an old draft that Jim wrote long ago. It is intended to support environments where clients are not viewed as having good key generation capabilities (e.g., poor RNG or not enough computational power to do key gen and check in a reasonable time). Also, some environments (e.g., some government and commercial contexts) do want key escrow, which is easy to provide if a CA (or RA) generate a key pair for the client. The WG needs to decide if it wants to adopt this document, given that the previous version died (for lack of interest). There are some other open issues, as discussed on the slides. At the microphone, several folks voiced support for adopting this work. (Slides) --============_-900493117==_ma============ Content-Type: text/html; charset="us-ascii" minutes, old style
PKIX WG Meeting July 25, 2011

Edited by Steve Kent
Co-Chairs: Stephen Kent <kent@bbn.com>
 Stefan Santesson <stefans@aaa-sec.com>

The PKIX WG met once, for 2 hours, during the 81st IETF. A total of approximately 41 individuals participated in the meeting.


Document Status Review - Steve Kent (BBN Technologies)
There has been significant progress in document status since the previous meeting.
-    2 new RFCs published since Prague (6170 & 6277)
-        0 documents in the RFC Editor's queue: certificate-image & OCSP agility
-        0 documents in IESG processing
- 7 I-Ds in process in the WG: CMC Updates (WGLC done, awaiting security considerations review, 5280 clarifications, OCSP Update, Transport Protocols for CMP, Internet mail addresses in X.509, S/MIME Capabilities for public keys, CAA
-        1 non-WG document to be discussed: EST (certificate Enrollment over Secure Transport)
(Slides)

PKIX WG Documents

DNS Certification Authority Authorization (CAA) Resource Record- Phillip Hallam-Baker (Comodo)
The I-D is intended to address the problem that arises due to the potential for an arbitrary CA (among the set of trust anchors embedded in many browsers, and OSes), to issue a certificate for any arbitrary web site. The proposed means of addressing this problem is to augment the DNS RR for a web site with info identifying the CA that has been authorized to issue an X.509 certificate for the web site in question. The current draft does not address issues such as CA accountability, of client (RP) validation of this info. The principle rationale for this added DNS data is to enable the major public CAs to detect when a "rogue" CA issues a certificate inappropriately.  (PHB says that the major public CA players regularly scan the DNS and would detect such behavior.) There are a number of details still to be worked out, which are noted in the slides.  At the microphone, suggestions were offered for improving the readability of the document, and asking why RPs are explicitly warned to not make use of this record. There is a sense that the document needs to be extensively re-written, to better present the rationale for this work, and explain why web site users (and the public TA set) would be motivated to make use of this technology. There is agreement that DNSSEC is not strictly required for these records, although it would be helpful, e.g., for accountability. (Slides)


Comments on CAA - Paul Hoffman (VPN Consortium)
Paul's slides address two issues in the CAA draft. He wants to see the RP text be removed, period.  His other concern is how a CA is identified in the CAA record. Paul suggests use of free form text (in UTF8) to identify the CA. This is very flexible, and accommodates the various types of IDs that Phillip noted.  This approach is potentially ambiguous, complicates checking by CAs, but does make life easier for DNS administrators/users. Paul explicitly wants to make life easier for the latter class, because it is much, much bigger. At the microphone, comments were against adopting only the free text form of CA ID, worries about use of UTF8, etc. Also, given the extensive use of RAs, under various TAs, there is potential for a lot of confusion and ambiguity that may undermine some of the security guarantees. All of this is viewed as useful input to the next version of the CAA document. (slides)


Presentations on non-WG Topics (seeking WG adoption)

Enrollment Over Secure Transport- Max Pritkin (Cisco)
This document proposes a new, simplified certificate issuance protocol, based on the simple CMC message formats. The protocol relies on messages being carried over TLS to achieve security between the client and a CA (or RA). The current version contains a requirements section that can be moved to a separate document. One of the principle changes in the most recent version of EST is inclusion of a PoP capability. The PoP method adopted here is based on channel-binding derived from the TLS session. This requires access to the TLS layer, to acquire this data. This method requires a CA to rely on an RA to have verified the PoP data, and pass it on to te CA, if the client does not establish a direct TLS connection to the CA. Also, the "attested" method of PoP is included here to enable a device to use a manufacturer-issued certificate to be a basis for issuance of another certificate. A straw poll of attendees showed most were in favor of adopting EST as WG item, with no one objecting.  Steve said he would ask for adoption on the PKIX list.
(Slides)

CMC Extensions: Server Side Key Generation & Key Escrow- Sean Turner (IECA)
This document is a resurrection of an old draft that Jim wrote long ago. It is intended to support environments where clients are not viewed as having good key generation capabilities (e.g., poor RNG or not enough computational power to do key gen and check in a reasonable time). Also, some environments (e.g., some government and commercial contexts) do want key escrow, which is easy to provide if a CA (or RA) generate a key pair for the client. The WG needs to decide if it wants to adopt this document, given that the previous version died (for lack of interest). There are some other open issues, as discussed on the slides. At the microphone, several folks voiced support for adopting this work. (Slides)
--============_-900493117==_ma============-- From kent@bbn.com Mon Jul 25 14:29:48 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6668D21F86BF for ; Mon, 25 Jul 2011 14:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx5sb91V30u8 for ; Mon, 25 Jul 2011 14:29:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 700D621F86AA for ; Mon, 25 Jul 2011 14:29:46 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:60103 helo=[130.129.71.153]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QlSif-000JgS-VB for pkix@ietf.org; Mon, 25 Jul 2011 17:29:46 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 25 Jul 2011 17:29:44 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] New WG item poll 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, 25 Jul 2011 21:29:48 -0000 At the PKIX meeting a straw poll indicated fairly strong support for adopting the ETS work as a new WG item. I am now initiating a 2 week on-list poll for this. Steve From melinda.shore@gmail.com Mon Jul 25 14:37:15 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A0411E80D1 for ; Mon, 25 Jul 2011 14:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyiSxfSrln3J for ; Mon, 25 Jul 2011 14:37:15 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1268111E80BA for ; Mon, 25 Jul 2011 14:37:14 -0700 (PDT) Received: by gxk19 with SMTP id 19so2915233gxk.31 for ; Mon, 25 Jul 2011 14:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5Ac/diRXRvUhyofERq7WmUFPdMSUV8z6jv3NAB9YHPI=; b=BQMrHBA2MoGE+MrH4AwKWwKDgR45j5xtybfxkE6JnoBlqnEZ8EU7rsxAy5nRN22mGU IVOpHzJ0E3/A2947lEFj3nkqen1DGnLZTcgO6BtR5s571P4JIXyKClj6H2XW0blTlqVb R7yuMn5dhgNTVx/Ci2doT2z2h7UiRwiu+QdSo= Received: by 10.142.122.26 with SMTP id u26mr3245646wfc.353.1311629834135; Mon, 25 Jul 2011 14:37:14 -0700 (PDT) Received: from [137.229.12.236] (drake.swits.alaska.edu [137.229.12.236]) by mx.google.com with ESMTPS id o3sm2097116wfd.9.2011.07.25.14.37.12 (version=SSLv3 cipher=OTHER); Mon, 25 Jul 2011 14:37:13 -0700 (PDT) Message-ID: <4E2DE20A.9010705@gmail.com> Date: Mon, 25 Jul 2011 13:37:14 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] New WG item poll 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, 25 Jul 2011 21:37:15 -0000 On 07/25/2011 01:29 PM, Stephen Kent wrote: > At the PKIX meeting a straw poll indicated fairly strong support for > adopting the ETS work as a new WG item. EST? If so, it's a definite "yes" from me. Melinda From housley@vigilsec.com Mon Jul 25 15:06:46 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3EB11E80D7 for ; Mon, 25 Jul 2011 15:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSvqRFml6LSG for ; Mon, 25 Jul 2011 15:06:46 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0626C11E80C7 for ; Mon, 25 Jul 2011 15:06:46 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 7598DF2406C; Mon, 25 Jul 2011 18:07:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id KJzWeCJj8J6o; Mon, 25 Jul 2011 18:06:30 -0400 (EDT) Received: from dhcp-227d.meeting.ietf.org (unknown [130.129.34.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id BC2E1F2404C; Mon, 25 Jul 2011 18:07:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Mon, 25 Jul 2011 18:06:43 -0400 Content-Transfer-Encoding: 7bit Message-Id: <7F634EFC-5056-4CEC-98B3-B86FB6AB0BE8@vigilsec.com> References: To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] New WG item poll 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, 25 Jul 2011 22:06:46 -0000 I support bringing this work into the PKIX WG. Russ On Jul 25, 2011, at 5:29 PM, Stephen Kent wrote: > At the PKIX meeting a straw poll indicated fairly strong support for > adopting the ETS work as a new WG item. > > I am now initiating a 2 week on-list poll for this. > > Steve > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From DPKemp@missi.ncsc.mil Mon Jul 25 15:10:28 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB8D21F888A for ; Mon, 25 Jul 2011 15:10:28 -0700 (PDT) X-Quarantine-ID: X-Amavis-Modified: Mail body modified (defanged) by ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat 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 dnFpEUbpnTr8 for ; Mon, 25 Jul 2011 15:10:27 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1311631828-2430-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1875621F84FC for ; Mon, 25 Jul 2011 15:10:27 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p6PMA4LU037079 for ; Mon, 25 Jul 2011 18:10:04 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 18:10:11 -0400 Date: Mon, 25 Jul 2011 18:10:04 -0400 Message-ID: In-Reply-To: References: <4E2C8B17.3080803@isis.poly.edu> <4E2CEF92.2020006@lockstep.com.au> <4E2D21E1.3030709@edelweb.fr> From: "Kemp, David P." To: Subject: Re: [pkix] Which is the new KPI research that is telling us how PKIis going on? 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, 25 Jul 2011 22:10:28 -0000 This is a multi-part message in MIME format... ------------=_1311631828-2430-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1311631828-2430-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Return-Path: Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1875621F84FC for ; Mon, 25 Jul 2011 15:10:27 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p6PMA4LU037079 for ; Mon, 25 Jul 2011 18:10:04 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 18:10:11 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC4B17.9B690791" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [pkix] Which is the new KPI research that is telling us how PKIis going on? Date: Mon, 25 Jul 2011 18:10:04 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Which is the new KPI research that is telling us how PKIis going on? Thread-Index: AcxKokeHZqVe5ssHSEysAXb+FKHTowAbJ13A References: <4E2C8B17.3080803@isis.poly.edu> <4E2CEF92.2020006@lockstep.com.au> <4E2D21E1.3030709@edelweb.fr> From: "Kemp, David P." To: X-OriginalArrivalTime: 25 Jul 2011 22:10:11.0828 (UTC) FILETIME=[9F71FB40:01CC4B17] This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4B17.9B690791 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: George Michaelson > I think the HCI factors are true. Whoever posted > "there is no logout" said something which has been nagging > me for years and years. Why are all browsers so crap at > letting you securely dis-associate from your bindings made > with your ID? Of course there is a logout - just kill the browser and restart it :-). I have no idea why, when browsers now support a "no history" private browsing mode in addition to the traditional cookie/history wipe, there couldn't also be a TLS state wipe (with or without deactivating the keystore) - it would be a trivial piece of UI to implement. =20 > I have also recently been musing on the shipped list of TA. > Its unfair to objectify a single recent TA installation. > In fact, I think we've been terribly remiss in accepting > ab-initio ANY installed TA state. Classic chicken-and-egg: > nobody was going to accept the HCI implications of hand > installing an OOB TA blob, but we've wound up blithely > *believing* the 'trusted' flags which emit from a system > which pre-shipped to us with certain assumptions wired in > that are never exposed to us in a way we can really make > sense of. On what basis can an individual make a decision to trust *anything*, including a news article with an AP byline, or a tweet from someone with a name that seems familiar? This is not an HCI issue, it's a human nature issue. Organizations are in a somewhat better position to establish criteria that must be met before extending trust to an partner, and audited in order to maintain the relationship. =20 It's unfair to object to "blithely believing" something related to PKI in particular - we all are exposed to new information every day, and we subject it to varying degrees of cynicism and analysis, but we never formally establish personal criteria for acceptance of *anything*. The inconvenience of installing OOB TA blobs is unrelated to trust. A system could be shipped with TAs present but unflagged, and a set of "manufacturer-approved" flag settings. Importing a new TA to the unflagged list should be trivial. But the user still has the problem of deciding to flag each one separately (based on what?) or accepting the manufacturer default list (also based on what?). Dave ------_=_NextPart_001_01CC4B17.9B690791 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgYWAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAUAAAAFJFOiBbcGtpeF0gV2hpY2gg aXMgdGhlIG5ldyBLUEkgcmVzZWFyY2ggdGhhdCBpcyB0ZWxsaW5nIHVzIGhvdyBQS0lpcyBnb2lu ZyBvbj8AUhsBBYADAA4AAADbBwcAGQASAAoABAABACMBASCAAwAOAAAA2wcHABkAEgAKAAUAAQAk AQEJgAEAIQAAAEMyNzg1MzQzQTAzQzZENENBQURBMTFCQTM0MzM5QzAxACEHAQOQBgBwEAAARgAA AAsAAgABAAAAAwAmAAAAAAALACsAAAAAAAMALgAAAAAAAwA2AAAAAABAADkAEBD2mhdLzAEeAD0A AQAAAAUAAABSRTogAAAAAAIBRwABAAAAMwAAAGM9VVM7YT0gO3A9RXhjaGFuZ2VOU0E7bD1EQUJF Q0stMTEwNzI1MjIxMDA1Wi00MzcxAAAeAHAAAQAAAEwAAABbcGtpeF0gV2hpY2ggaXMgdGhlIG5l dyBLUEkgcmVzZWFyY2ggdGhhdCBpcyB0ZWxsaW5nIHVzIGhvdyBQS0lpcyBnb2luZyBvbj8AAgFx AAEAAAAbAAAAAcxKokeHZqVe5ssHSEysAXb+FKHTowAbJ13AAB4AGgwBAAAADwAAAEtlbXAsIERh dmlkIFAuAAAeAB0OAQAAAEwAAABbcGtpeF0gV2hpY2ggaXMgdGhlIG5ldyBLUEkgcmVzZWFyY2gg dGhhdCBpcyB0ZWxsaW5nIHVzIGhvdyBQS0lpcyBnb2luZyBvbj8AAgEJEAEAAACoBgAApAYAAJYK AABMWkZ1os2ZKAMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IR JQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQ8wsJAWQz NhZQC6YK4wqE1QqALR2yTwUQZwuAB0DDBdAHkHNhZ2Udsxz0wkYDYTogR2UFsB7gxwXQDeAT4GVs cwIgHPpAPiBJIHRoC4BrUyIRIGBIQyIAZgDQdE8FsAQgCsAgYHRyClAuQCBXaG9ldhKBcNxvcw6w CzEhpCIigSORoQQAIG5vIBewZwhgyHQiIB7AaWQmwANwYxQgIjFnIHciMBPQIHsT4AQgYgnhJhAe 0B4xZ88hhgeAIvAFsXllE/EjcO5uJwAqEyQCeSNzB0ADILpiA2B3FBAjUSDwIAUAVGFwI3B0IYZs FCB0/SeCeQhgJsAFkAhwINArQNpkBAAtKDAg8GMHMA6w7yLwA2EuAgXAYguALuAnkH8EIADAAQAh hgPwIiAwBEnkRD8c+k9mLJAIYRQQCyJyJcRhJkUgLSBq8nUkwCBrAxADICKCK+U/KmMYICTACsAF QDHAIDr4LSkuHPoiABPgJGAmEucm8CogJ7F5LCexKIEr5+MmIAfgc3VwJKA3ETRwXiImISIwJMAF sHkmsHD9BRB2L4Ir4yeCBGIl4AOg/zEALuAtwAIgIhAmMCKCI8AvMQA+Ax5hBaBvNXBlL3M7tTGh cGU5kCWUM3FseGRuJzsxIOEoUTRhVJ5MBfA24S+RQIIgKDGz/wWxMbI0wjkhIyA8YieCIoLIa2V5 O9JlKTTxN0H+d0FSQhQjwDxgBzEkkAiQamMgYG8zUFUiATjxbf0LUGUHgAIwJAAc6yHiOJO/QdMY IEfQAjAusShjbTUw9yeCPjIikXMiMDrwCYAmQLM7wUfyVEE3pSHhdAQgNHVuIwBpBcA+YW9i9moF kC3AZitBJsAngS2Q/0rlTaE9kTbhK7BE4QIgTdiPA6AjAjmQIgZ3ZSc4sXsoYw6wcgUQAmArQBgg bXsEAj2iY0fQBTAo+QGgLecLgD4CEMBOWVEGTQFQ4ftCsyQAQwtgBBAN4CyQJ9FNRYBuLxAqgC1l KNA69yGGJiAG4GRAYSgxJnBFA/8mMFVUIndIkg3gUYMEIEgBPxPgKoAhhlEVJ4IDkU9P3kJQ0gJg T0A5kGI00VN0f0ZxKoE64F+xMcEuoSGGKu8oYE0wJFAngSoic0GgI9D9JMInIvALYDDBJ8RUwQVA /y/DT+FFoUjQMTcn0zxAHvD/TLY+YTUwMaRH0AAgC3EjcP0EEHVIoF0kA/AYIT2RIYb3IiAs8CNz biRTDsAkoWdH/z2iWuFAYUEhA5EYICuhK0B/AMBFgCGGFBAAgEfiN6tP9wOgJ8BqgWIoMCXxbPID kfMwckdQZHUeYW2iNGEFgV8EAD4mY3JiQABweSdjKvs5kAuAYwpAMJI0YWrwLBA/I3EtwHQgQvIx 0QORQVD9KFB5XtFAsQWxRwFTcBQg/y+0JyICIHV2KKEpoWpjFBC/SNAEICMAVNBNMArAP0kw/lQ7 sSXkOzEDoFxzaLFAsXUxwCc0Umho0AORHlB0Ly6Be4RJIR4AZwBwaXr/XRUjgmwzJyJv5C2hJHQ+ B/820mFRTLAskTHABnFHAWpy/0vRf6IpkX+iKdEgYA7BCfBfdFNy5FuSA6AKsXRq8HL7OZAqcmF0 QSTRPZIFsASB/z5SAMALgGhTIoIukV0UTMHfSS1OYHwhTq4+UiJhVihRn2KFJrEnN4fjZ0RQS1yR /4TkDeBBYArBNQBswSuiI4L/a1l0wT2RKdEAwD4TJFIuwf9skIV0bME60IqUN0E+YTxwnzwAJ4IB AAnCXWNjeQMA/3JBZTGFoh5RRaAEAGAGauX/kMNtYoD4QKAUAD9EgaYp0v9VVABwR9RzSDeremA9 ggWg/m4kYAMACfBH1F55X1l6k/9OoI0ZY2NJIVfxZYNBNEIS/0y2MbNNsAQgZrFuYXARNNF3TqFk AR7gZIV1LkFNYyLtA4F1IwIugXIvEDrwA2B9JGBkJrBj8qPyLcIq8Un/SKAXwXRnUNI+ZaL3TSRM sPdGhkclSSFCNNGoQzZCJMD/NYIoIiKCpXECYKBhSAFyIv+D9CYwpfNEgUOheBEUEAqxey+BLrEo cDFNAT4xb+I//0YAmTdFBqSKRGEjAEFgBUDdTTMoQdSvjDerRDihHPoCfbZQHgA1EAEAAABBAAAA PEMxQTQ3RjE1NDBERjMyNDZBOEQzMEM4NTNDMDVEMERBMDNERTIzNjJAREFCRUNLLm1pc3NpLm5j c2MubWlsPgAAAAAeADkQAQAAAAYBAAA8RTFRa3FIei0wMDA4S3QtT3NAbG9naW4wMS5mb3MuYXVj a2xhbmQuYWMubno+CTw0RTJDOEIxNy4zMDgwODAzQGlzaXMucG9seS5lZHU+CTxDQUNjM1kwM1lM R1F3SG5GZTBrU0JUakhEX3VvRXhwNUhfT2NNa1ZqaFZZQXdKX1pmY3dAbWFpbC5nbWFpbC5jb20+ PDRFMkNFRjkyLjIwMjAwMDZAbG9ja3N0ZXAuY29tLmF1PiA8NEUyRDIxRTEuMzAzMDcwOUBlZGVs d2ViLmZyPiA8QTBBNjM1QzAtNjY2RC00RDE1LTlGN0ItNkE3RjQzMTAwRkJDQGFwbmljLm5ldD4A AAAeAEIQAQAAADEAAAA8QTBBNjM1QzAtNjY2RC00RDE1LTlGN0ItNkE3RjQzMTAwRkJDQGFwbmlj Lm5ldD4AAAAAAwCAEP////8fAPMQAQAAALAAAABSAEUAJQAzAEEAIABbAHAAawBpAHgAXQAgAFcA aABpAGMAaAAgAGkAcwAgAHQAaABlACAAbgBlAHcAIABLAFAASQAgAHIAZQBzAGUAYQByAGMAaAAg AHQAaABhAHQAIABpAHMAIAB0AGUAbABsAGkAbgBnACAAdQBzACAAaABvAHcAIABQAEsASQBpAHMA IABnAG8AaQBuAGcAIABvAG4AJQAzAEYALgBFAE0ATAAAAAsA9hAAAAAAQAAHMJEHaZsXS8wBQAAI MGLzdJsXS8wBAgEQMAEAAABGAAAAAAAAAJJj8pZU/tMRo/gAgF8xnEUHAF5KQJejlNIRo8UAgF++ yL8AAAFzXTwAAMsWET8I06VPmnxqPUhEoqcAAAJxKyYAAAAAAwDeP59OAAADAPE/CQQAAB4A+D8B AAAADwAAAEtlbXAsIERhdmlkIFAuAAACAfk/AQAAAE0AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEA AAAAAAAAL089RVhDSEFOR0VOU0EvT1U9TUlTU0kvQ049UkVDSVBJRU5UUy9DTj1EUEtFTVAxAAAA AB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DI wEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAAAAMAGkAAAAAAHgAwQAEAAAAI AAAARFBLRU1QMQAeADFAAQAAAAgAAABEUEtFTVAxAB4AOEABAAAACAAAAERQS0VNUDEAHgA5QAEA AAACAAAALgAAAAMAdkD/////AwAJWQEAAAADAAFuAAAAAAMAIYEDIAYAAAAAAMAAAAAAAABGAAAA AAGBAAAAAAAABQAigQMgBgAAAAAAwAAAAAAAAEYAAAAAAoEAAAAAAAAAAAAAAwAkgQMgBgAAAAAA wAAAAAAAAEYAAAAAE4EAAAEAAAALACWBAyAGAAAAAADAAAAAAAAARgAAAAAcgQAAAAAAAAsAJ4ED IAYAAAAAAMAAAAAAAABGAAAAACaBAAAAAAAAAwApgQMgBgAAAAAAwAAAAAAAAEYAAAAAEIEAAAAA AAADACqBAyAGAAAAAADAAAAAAAAARgAAAAARgQAAAAAAAAMALYEDIAYAAAAAAMAAAAAAAABGAAAA ACqBAAAAAAAAAwAwgQMgBgAAAAAAwAAAAAAAAEYAAAAAKYEAAAAAAAALADGBAyAGAAAAAADAAAAA AAAARgAAAAAkgQAAAAAAAAsAMoEDIAYAAAAAAMAAAAAAAABGAAAAACyBAAAAAAAAHgAzgQMgBgAA AAAAwAAAAAAAAEYAAAAAJ4EAAAEAAAABAAAAAAAAAAMANIEDIAYAAAAAAMAAAAAAAABGAAAAABKB AAABAAAAHgA1gQMgBgAAAAAAwAAAAAAAAEYAAAAAIYEAAAEAAAABAAAAAAAAAAsANoEDIAYAAAAA AMAAAAAAAABGAAAAAAOBAAAAAAAAAwA5gQMgBgAAAAAAwAAAAAAAAEYAAAAAI4EAAP///38LAIiB CCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMA7YEIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAA AAAACwDygQggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAPyBCCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAA4IIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAACwDsggggBgAAAAAAwAAA AAAAAEYAAAAABoUAAAAAAAALAPCCCCAGAAAAAADAAAAAAAAARgAAAACChQAAAAAAAEAA7IMIIAYA AAAAAMAAAAAAAABGAAAAAL+FAADwrxGCF0vMAQsAKQAAAAAACwAjAAAAAAADAAYQQQKFDQMABxAm BwAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAC0tLS0tT1JJR0lOQUxNRVNTQUdFLS0tLS1G Uk9NOkdFT1JHRU1JQ0hBRUxTT05JVEhJTktUSEVIQ0lGQUNUT1JTQVJFVFJVRVdIT0VWRVJQT1NU RUQiVEhFUkVJU05PTE9HT1UAAAAAAgF/AAEAAABBAAAAPEMxQTQ3RjE1NDBERjMyNDZBOEQzMEM4 NTNDMDVEMERBMDNERTIzNjJAREFCRUNLLm1pc3NpLm5jc2MubWlsPgAAAAChKg== ------_=_NextPart_001_01CC4B17.9B690791-- ------------=_1311631828-2430-1-- From pala@isis.poly.edu Mon Jul 25 15:18:42 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818A421F8BDE for ; Mon, 25 Jul 2011 15:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 eZE7JFqSSIJJ for ; Mon, 25 Jul 2011 15:18:41 -0700 (PDT) Received: from isis.poly.edu (isis.poly.edu [128.238.66.15]) by ietfa.amsl.com (Postfix) with ESMTP id 78DEF21F8BD3 for ; Mon, 25 Jul 2011 15:18:41 -0700 (PDT) Received: (qmail 76106 invoked from network); 25 Jul 2011 22:18:36 -0000 Received: from unknown (HELO ?10.63.26.177?) (madwolf@166.205.13.131) by isis.poly.edu with AES128-SHA encrypted SMTP; 25 Jul 2011 22:18:36 -0000 References: <4E2C8B17.3080803@isis.poly.edu> <1311569025.10022.17.camel@localhost> From: Max Pala Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (8A293) In-Reply-To: <1311569025.10022.17.camel@localhost> Message-Id: <6984433C-7959-448E-AD83-9E8938536AF1@isis.poly.edu> Date: Mon, 25 Jul 2011 16:18:21 -0600 To: Matt McCutchen , pkix@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPhone Mail 8A293) Subject: Re: [pkix] Tangent: browsers (Re: Which is the new KPI research that is telling us how PKI is going on?) 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, 25 Jul 2011 22:18:42 -0000 Hi Matt, I understand what the browser vendors point of view is. The problem is the a= ssumption that to users can give any value to https:// vs http:// . Plenty o= f research demonstrated that that is not true. One of the few elements that u= sers can recognize is the lock.. Not the protocol identifier. After all, encrypting contents to an "unknown" or "unveriifed" party is no d= ifferent than not encrypting it at all. That's the point. It is still an "un= trusted" connection.. Exactly as an http:// one. If browser vendors implemented the concept of trusted/not-trusted not based o= n just an "s" the world could have been a better place.. But, and this is my= speculation, the real reason behind this choice was liability (and probably= some influence from commercial CAs, not security..). An example o this.. EV= certs.. Just my 2 cents.. --- Cheers, Max On Jul 24, 2011, at 10:43 PM, Matt McCutchen wrote:= > On Sun, 2011-07-24 at 17:13 -0400, Massimiliano Pala wrote: >> Think about the case where simple http connections (no SSL/TLS) are displ= ayed, >> to the user, more trustworthy than non-trusted https (SSL/TLS) once.. Bad= .. Bad.. >> Bad.. browsers and who took such bad decisions.. !!! >=20 > Read https://bugzilla.mozilla.org/show_bug.cgi?id=3D566008#c10 and you > will understand why this is. >=20 > --=20 > Matt >=20 From anders.rundgren@telia.com Mon Jul 25 15:44:53 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8428911E80D0 for ; Mon, 25 Jul 2011 15:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 EHoiI76tQS8U for ; Mon, 25 Jul 2011 15:44:53 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id E831411E80CF for ; Mon, 25 Jul 2011 15:44:52 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F007B0DC1 for pkix@ietf.org; Tue, 26 Jul 2011 00:44:51 +0200 Message-ID: <4E2DF1D8.7060501@telia.com> Date: Tue, 26 Jul 2011 00:44:40 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] New WG item poll 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, 25 Jul 2011 22:44:53 -0000 > At the PKIX meeting a straw poll indicated fairly strong support for > adopting the ETS work as a new WG item. The slides were pretty but the idea sucks. OTOH it is free world so if people want to spend time on a topic which Apple already have deployed a better version of they should of course do it. It is a YES. Anders From pgut001@login01.cs.auckland.ac.nz Mon Jul 25 20:14:36 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7177021F86DC for ; Mon, 25 Jul 2011 20:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.623 X-Spam-Level: X-Spam-Status: No, score=-3.623 tagged_above=-999 required=5 tests=[AWL=-0.024, 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 XiXyJK7ynmuW for ; Mon, 25 Jul 2011 20:14:35 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9937A21F86CA for ; Mon, 25 Jul 2011 20:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311650076; x=1343186076; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20matt@mattmccutchen.net,=20pala@isis.poly.edu,=20pk ix@ietf.org|Subject:=20Re:=20[pkix]=20Tangent:=20browsers =20(Re:=20Which=20is=20the=20new=20KPI=20research=20that =20is=20telling=20us=20how=20PKI=20is=20going=20on?) |In-Reply-To:=20<6984433C-7959-448E-AD83-9E8938536AF1@isi s.poly.edu>|Message-Id:=20|Date:=20Tue,=2026=20Jul=202011=2015:14:32 =20+1200; bh=F9iti25EePkONKK56AVG9hMCw2aFXLTg8hzkmAtgA7s=; b=HeLmkm6ataK81xf4Suad+lJ37SAMfAERVb2RjpvBvCD5zWD8jyj8teQE GObs+RWPhRWRVHelg7gorBFpp40wAgmt3grktEfxzbn0Suh2TTADhNyCk fvQuLHhqQElfAYZqwufAfgXBMXk60UwvaUhSzgmMJ9irjhjK4XTMnXdWz U=; X-IronPort-AV: E=Sophos;i="4.67,266,1309694400"; d="scan'208";a="74084981" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 26 Jul 2011 15:14:32 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QlY6K-0005Dg-IN; Tue, 26 Jul 2011 15:14:32 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QlY6K-00008y-LF; Tue, 26 Jul 2011 15:14:32 +1200 From: Peter Gutmann To: matt@mattmccutchen.net, pala@isis.poly.edu, pkix@ietf.org In-Reply-To: <6984433C-7959-448E-AD83-9E8938536AF1@isis.poly.edu> Message-Id: Date: Tue, 26 Jul 2011 15:14:32 +1200 Subject: Re: [pkix] Tangent: browsers (Re: Which is the new KPI research that is telling us how PKI is going on?) 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, 26 Jul 2011 03:14:36 -0000 Max Pala writes: >After all, encrypting contents to an "unknown" or "unveriifed" party is no >different than not encrypting it at all. That's the point. It is still an >"untrusted" connection.. Exactly as an http:// one. That's a misconception created (or caused) by crypto purists. In one of the few real cases where encryption of HTTP traffic would actually be useful, 802.11 sniffing/Firesheep-style attacks, encryption with anon-DH (which SSL PKI is in effect anyway, as you point out the only real indicator is padlock/no padlock which anon-DH gives you just as well) would be enough to stop the attack dead in its tracks. Peter. From tmiller@mitre.org Tue Jul 26 06:03:18 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD4221F8B27 for ; Tue, 26 Jul 2011 06:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfGXov7rGsIO for ; Tue, 26 Jul 2011 06:03:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8F20621F8B30 for ; Tue, 26 Jul 2011 06:03:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C1F9521B09FF; Tue, 26 Jul 2011 09:03:16 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B974F21B0902; Tue, 26 Jul 2011 09:03:16 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 26 Jul 2011 09:03:16 -0400 From: "Miller, Timothy J." To: Peter Gutmann Date: Tue, 26 Jul 2011 09:03:18 -0400 Thread-Topic: [pkix] Tangent: browsers (Re: Which is the new KPI research that is telling us how PKI is going on?) Thread-Index: AcxLlGIZUfwZ7qBFRZmcoggRuYJEmw== Message-ID: <111BE2BC-8215-4B1F-A673-581A9E9690E3@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-1-518233080"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Tangent: browsers (Re: Which is the new KPI research that is telling us how PKI is going on?) 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, 26 Jul 2011 13:03:18 -0000 --Apple-Mail-1-518233080 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Concur. Confidentiality without authentication has plenty of uses. -- T On Jul 25, 2011, at 10:14 PM, Peter Gutmann wrote: > Max Pala writes: >=20 >> After all, encrypting contents to an "unknown" or "unveriifed" party = is no >> different than not encrypting it at all. That's the point. It is = still an >> "untrusted" connection.. Exactly as an http:// one. >=20 > That's a misconception created (or caused) by crypto purists. In one = of the > few real cases where encryption of HTTP traffic would actually be = useful, > 802.11 sniffing/Firesheep-style attacks, encryption with anon-DH = (which SSL > PKI is in effect anyway, as you point out the only real indicator is > padlock/no padlock which anon-DH gives you just as well) would be = enough to > stop the attack dead in its tracks. >=20 > Peter. >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-1-518233080 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA3MjYxMzAzMThaMCMGCSqGSIb3DQEJBDEWBBRUuEdVlI3Eu5tVubiT EZPBze/KFjByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgIon3GY5zvT+xX+Kg7OIZ+V7PqW5RU8x+ON+ L1wm8CSt/dcgwvFz5R1UH1Ap5lHZfYyyT0Scx/w6upZ6KbsKxv/viK1kUiCVG0iBUCiXX4Wfve1C S4pjYtIE460xkr2eUDO7pYbU/YHWTpTu506fAr5C0ztDoSR/cwprEKNzo2BUAAAAAAAA --Apple-Mail-1-518233080-- From ynir@checkpoint.com Tue Jul 26 06:38:17 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B5621F8B1B for ; Tue, 26 Jul 2011 06:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.476 X-Spam-Level: X-Spam-Status: No, score=-10.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 tEQRs42MjmDX for ; Tue, 26 Jul 2011 06:38:16 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E55F621F8B19 for ; Tue, 26 Jul 2011 06:38:13 -0700 (PDT) X-CheckPoint: {4E2ED0D9-20-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6QDbmvR015492; Tue, 26 Jul 2011 16:37:48 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 26 Jul 2011 16:37:48 +0300 From: Yoav Nir To: "Miller, Timothy J." Date: Tue, 26 Jul 2011 16:37:46 +0300 Thread-Topic: [pkix] Tangent: browsers (Re: Which is the new KPI research that is telling us how PKI is going on?) Thread-Index: AcxLmTTfhorkp5v9QCGJj0o63fVDuA== Message-ID: <1E851B43-084F-4ABC-BADB-71CF9D4C281D@checkpoint.com> References: <111BE2BC-8215-4B1F-A673-581A9E9690E3@mitre.org> In-Reply-To: <111BE2BC-8215-4B1F-A673-581A9E9690E3@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-3-520301090"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Tangent: browsers (Re: Which is the new KPI research that is telling us how PKI is going on?) 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, 26 Jul 2011 13:38:17 -0000 --Apple-Mail-3-520301090 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If nothing else, it makes the attacker work harder. It's very easy to listen in on HTTP in the LAN or the WLAN. It's = feasible even out of the LAN Go to HTTPS and you need to be an active attacker. That's a whole = different level of effort. On Jul 26, 2011, at 9:03 AM, Miller, Timothy J. wrote: > Concur. Confidentiality without authentication has plenty of uses. >=20 > -- T >=20 > On Jul 25, 2011, at 10:14 PM, Peter Gutmann wrote: >=20 >> Max Pala writes: >>=20 >>> After all, encrypting contents to an "unknown" or "unveriifed" party = is no >>> different than not encrypting it at all. That's the point. It is = still an >>> "untrusted" connection.. Exactly as an http:// one. >>=20 >> That's a misconception created (or caused) by crypto purists. In one = of the >> few real cases where encryption of HTTP traffic would actually be = useful, >> 802.11 sniffing/Firesheep-style attacks, encryption with anon-DH = (which SSL >> PKI is in effect anyway, as you point out the only real indicator is >> padlock/no padlock which anon-DH gives you just as well) would be = enough to >> stop the attack dead in its tracks. >>=20 >> Peter. >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >=20 > --Apple-Mail-3-520301090 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBScwggQPoAMC AQICEBW9tBlVg9WZf9zHij2h3zMwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwNzIxMDAwMDAwWhcNMTIwNzIwMjM1OTU5WjAkMSIwIAYJKoZI hvcNAQkBFhN5bmlyQGNoZWNrcG9pbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxha8w2xboHPbsj9HBz/1LdG2kwp++sXC5I0izECjJRravnWdnlDqTSRx7outPOk4zkfP/jtO ZiFl35/W/ZgiVilKNrCAcIk4J4VYdbhUItos2Z1ydt1JcY6F24faWNNns2hV/cF6pNELNTxPYIsY HrVy7Cq7/oywfHQimKbL4cVZvUF34P57gZKrxKBEkw3cUAzch7bQ8pTtewjvFW+cjpDqPaFSZyGJ VfbBtAg3RBjlOolfp2VlTmLGW3gRxg9hi7XAxjJf417I9b1hz0NpTnhSr7n38zMEyUdhqr2Wb37b yFNmhF+dWeBUX/RzgdIeqO/whtI1+gH8ZNuzpAV1UQIDAQABo4IB4zCCAd8wHwYDVR0jBBgwFoAU ehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFPzBjRi9Qe40hv+WSad/Om18V8HmMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEF BQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVF bWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETeW5pckBjaGVj a3BvaW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAkLgfz4ztXKON97ZHaqFhBfxO3QGPhx76iB1U 9LevFF/AsfS0ap2IWzGDocGJze17FZTjM41vCpRORCKCAdek+u+6RO95zx8VQaZybicBNCGBb4LP 1h8GvtmrT/+JpdtETJp9i1KIEwn8hn9Q4aMdkk8S2QkemBmhzGXdcQ5nCxyCQHk1hcRSDhC1qfME DPGlKMxqDpMHrFmiI6vdCVBhufX7xECsGXOJDqMWMPg7YE0fubg50T8ehNHJ2Mvm8JpYIGwTIC3v V9egV4ghYxHXm6u1zbXZUD+3pV9cNKbboB1FjuVqzKIiuNnzsZ3StcasZRYaxlwaHAU4uAuNyzbN 3jGCA6swggOnAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UE AxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZ VYPVmX/cx4o9od8zMAkGBSsOAwIaBQCgggHXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTExMDcyNjEzMzc0NlowIwYJKoZIhvcNAQkEMRYEFJa7acFeGbvEdNW8ulG/ EncCQciFMIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEBW9tBlVg9WZf9zHij2h3zMwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZVYPVmX/cx4o9od8zMA0GCSqGSIb3DQEBAQUA BIIBAJlgEo/QVBgLQlzK4QMOukiZY/DWvCB2lc+8QO4NI4tNTPAyqarbB/RqeA2uk3g4a+gMl0ow C3g7x7xigHyMOUc9HPo3YNl1//nIBd2Khf+jxUFGt2H75XCrU7aTsXaPoy9olt5anQ9owL7ytfVK 1KV3Lr8FXAkyFBbm1E7ytjtSfOlAoRDLXQOCfz4Q0RMXD5x71Y5ZC1u1PcY8EqCRKvwiCYkQVG34 qxuAtLAwb20TSRju+xOKrVdMmnBJzx3IXIotrjN3wjsbEDO0PnlTAJD0LjItRYTm0byrFbGrF4y3 FNGyk5DqHJfhwaRJBUogVr3hO7z8vZoHFpxmVqmd9iYAAAAAAAA= --Apple-Mail-3-520301090-- From pritikin@cisco.com Tue Jul 26 10:43:23 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608A611E811E for ; Tue, 26 Jul 2011 10:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 420pYXCHY12B for ; Tue, 26 Jul 2011 10:43:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE1011E8073 for ; Tue, 26 Jul 2011 10:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=776; q=dns/txt; s=iport; t=1311702202; x=1312911802; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=u8sjknImd8tzD+A3rroBfgv/BQOQ2ExVgd+NFDatHD0=; b=YmHFTfNdU7natATLH2Z1x50V3/od+q8sjODsCgFsoxN6M79Re+p28/sY 2/T32XhSZFQhn78l5gtcyLGKpyWt5XqoUlVvZAWlQvpwn+WT7Iwf436x6 dETwgrXJSZn95Wb1/tR8wzz3n9eU2AoLWH91g9tcbjKG7mvZwr56ia3pi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKD7Lk6tJXG9/2dsb2JhbAA2AQEBAQECFAErRREMUhRRBzcHpyd3iQCidJ5ohWFfBJJykHw X-IronPort-AV: E=Sophos;i="4.67,270,1309737600"; d="scan'208";a="6578154" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 26 Jul 2011 17:43:21 +0000 Received: from rtp-vpn6-1214.cisco.com (rtp-vpn6-1214.cisco.com [10.82.252.194]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6QHhLtg013743; Tue, 26 Jul 2011 17:43:21 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: <4E2B2960.8090109@telia.com> Date: Tue, 26 Jul 2011 13:43:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3A77A000-6872-4C69-BFE0-77E2235DD42B@cisco.com> References: <4E2B2960.8090109@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1084) Cc: IETF Subject: Re: [pkix] Which is the new KPI research that is telling us how PKI is going on? 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, 26 Jul 2011 17:43:23 -0000 On Jul 23, 2011, at 4:04 PM, Anders Rundgren wrote: [snip] > So it is all darkness and gloom? >=20 > Absolutely not! > Fortunately there are new vendors that sell amazingly popular = computing > devices that can be easily deployed with PKI without adding any = additional > client software or hardware: >=20 > = http://images.apple.com/iphone/business/docs/iPhone_OTA_Enrollment_Configu= ration.pdf Anders, Thanks for the continued notes of encouragement concerning the = iPhone enrollment mechanisms. We designed that based on our Cisco VPN = router deployment solution and the lessons we learned in the process = have directly informed the EST draft. I too agree it is not all "darkness and gloom". I appreciate the continued feedback, - max= From pala@isis.poly.edu Tue Jul 26 13:57:11 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00F022800D for ; Tue, 26 Jul 2011 13:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 S8Qz-h0vCv3R for ; Tue, 26 Jul 2011 13:57:11 -0700 (PDT) Received: from isis.poly.edu (isis.poly.edu [128.238.66.15]) by ietfa.amsl.com (Postfix) with ESMTP id CC45E228006 for ; Tue, 26 Jul 2011 13:57:10 -0700 (PDT) Received: (qmail 2889 invoked from network); 26 Jul 2011 20:57:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (madwolf@24.0.161.170) by isis.poly.edu with CAMELLIA256-SHA encrypted SMTP; 26 Jul 2011 20:57:07 -0000 Message-ID: <4E2F2A2D.2000407@isis.poly.edu> Date: Tue, 26 Jul 2011 14:57:17 -0600 From: Massimiliano Pala Organization: NYU Poly User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: pkix@ietf.org References: <111BE2BC-8215-4B1F-A673-581A9E9690E3@mitre.org> <1E851B43-084F-4ABC-BADB-71CF9D4C281D@checkpoint.com> In-Reply-To: <1E851B43-084F-4ABC-BADB-71CF9D4C281D@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Tangent: browsers (Re: Which is the new KPI research that is telling us how PKI is going on?) 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, 26 Jul 2011 20:57:11 -0000 Hi all, Well.. Sort of... There are plenty of tools allow for MITM also for (anony DH) SSL/TLS sessions when you can not authenticate the identity of the remote end.. you might have a confidential session with the intended party or.. an attacker.. :D In that sense: HTTP ~= not authenticated HTTPS. At least from a trust point of view.. both of them should not be accredited with any trust... :) And applications should reflect this in how they treat connections in their UIs. The same would apply for SCP vs FTP.. My last my two cents on this topic (sorry for the off topic) .. Cheers, Max P.S.: If interested reply off-list, please.. P.P.S.: Thanks to the chairs for not yelling at us for this OT... :D On 07/26/2011 07:37 AM, Yoav Nir wrote: > If nothing else, it makes the attacker work harder. > > It's very easy to listen in on HTTP in the LAN or the WLAN. It's feasible even out of the LAN > Go to HTTPS and you need to be an active attacker. That's a whole different level of effort. > > > > On Jul 26, 2011, at 9:03 AM, Miller, Timothy J. wrote: > >> Concur. Confidentiality without authentication has plenty of uses. >> >> -- T >> >> On Jul 25, 2011, at 10:14 PM, Peter Gutmann wrote: >> >>> Max Pala writes: >>> >>>> After all, encrypting contents to an "unknown" or "unveriifed" party is no >>>> different than not encrypting it at all. That's the point. It is still an >>>> "untrusted" connection.. Exactly as an http:// one. >>> >>> That's a misconception created (or caused) by crypto purists. In one of the >>> few real cases where encryption of HTTP traffic would actually be useful, >>> 802.11 sniffing/Firesheep-style attacks, encryption with anon-DH (which SSL >>> PKI is in effect anyway, as you point out the only real indicator is >>> padlock/no padlock which anon-DH gives you just as well) would be enough to >>> stop the attack dead in its tracks. >>> >>> Peter. -- tel.718-260-4009 | web: http://member.acm.org/~openca/ Massimiliano Pala, Ph.D. Director, OpenCA Labs Professor, NYU Poly From mrex@sap.com Tue Jul 26 14:06:18 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B357511E80A7 for ; Tue, 26 Jul 2011 14:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.864 X-Spam-Level: X-Spam-Status: No, score=-9.864 tagged_above=-999 required=5 tests=[AWL=0.385, 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 kofpw0nZQyPw for ; Tue, 26 Jul 2011 14:06:18 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9C59F11E809D for ; Tue, 26 Jul 2011 14:06:13 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6QL64tV004430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jul 2011 23:06:04 +0200 (MEST) From: Martin Rex Message-Id: <201107262106.p6QL63I8018374@fs4113.wdf.sap.corp> To: tmiller@mitre.org (Miller, Timothy J.) Date: Tue, 26 Jul 2011 23:06:03 +0200 (MEST) In-Reply-To: <111BE2BC-8215-4B1F-A673-581A9E9690E3@mitre.org> from "Miller, Timothy J." at Jul 26, 11 09:03:18 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Tangent: browsers (Re: Which is the new KPI 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, 26 Jul 2011 21:06:18 -0000 Miller, Timothy J. wrote: > > --Apple-Mail-1-518233080 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=us-ascii > > Concur. Confidentiality without authentication has plenty of uses. > > -- T Definitely. And it is how TLS worked on the iPhone all the time. :-D -Martin From tmiller@mitre.org Wed Jul 27 04:58:41 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8D121F8867 for ; Wed, 27 Jul 2011 04:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKURpXYVh2OR for ; Wed, 27 Jul 2011 04:58:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 281F021F8793 for ; Wed, 27 Jul 2011 04:58:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8593821B165C; Wed, 27 Jul 2011 07:58:39 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7E9AE21B1612; Wed, 27 Jul 2011 07:58:39 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 27 Jul 2011 07:58:39 -0400 From: "Miller, Timothy J." To: Massimiliano Pala Date: Wed, 27 Jul 2011 07:58:47 -0400 Thread-Topic: [pkix] Tangent: browsers (Re: Which is the new KPI research that is telling us how PKI is going on?) Thread-Index: AcxMVIU7D5R0SvBtRpqkWhg0j8V5ZQ== Message-ID: <2157E25B-6522-48AB-87EF-59D3F5C4CE3C@mitre.org> References: <111BE2BC-8215-4B1F-A673-581A9E9690E3@mitre.org> <1E851B43-084F-4ABC-BADB-71CF9D4C281D@checkpoint.com> <4E2F2A2D.2000407@isis.poly.edu> In-Reply-To: <4E2F2A2D.2000407@isis.poly.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-1-600762420"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Tangent: browsers (Re: Which is the new KPI research that is telling us how PKI is going on?) 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, 27 Jul 2011 11:58:41 -0000 --Apple-Mail-1-600762420 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 26, 2011, at 3:57 PM, Massimiliano Pala wrote: > Well.. Sort of... There are plenty of tools allow for MITM also for = (anony DH) SSL/TLS=20 > sessions when you can not authenticate the identity of the remote = end.. you might have > a confidential session with the intended party or.. an attacker.. :D = In that sense: OTOH, don't let the perfect be the enemy of the good enough. -- T --Apple-Mail-1-600762420 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA3MjcxMTU4NDhaMCMGCSqGSIb3DQEJBDEWBBTg050H8VjW5kE6nVWI prC1PzMENzByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgGA0uvQzjVvgTL2Fy5joM9U4V+z7XEYd7sDt 7GrlLVD3UypXWQj2IPZYToSsK6XWxf3ocxNUkOwU5mDgFhL0ji/O9DQcvtEI1hggJCIUL+hf6o7b 2ZjbtGpAPj14+BlvBhxyhkPSLt3dQEsbKqhNW6FfgCezCwRO5jBbU4O6lKdEAAAAAAAA --Apple-Mail-1-600762420-- From pala@isis.poly.edu Wed Jul 27 07:02:34 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303CA21F86C4 for ; Wed, 27 Jul 2011 07:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHMje6mEkr2Q for ; Wed, 27 Jul 2011 07:02:33 -0700 (PDT) Received: from isis.poly.edu (isis.poly.edu [128.238.66.15]) by ietfa.amsl.com (Postfix) with ESMTP id 50B5721F869C for ; Wed, 27 Jul 2011 07:02:33 -0700 (PDT) Received: (qmail 27507 invoked from network); 27 Jul 2011 14:02:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (madwolf@24.0.161.170) by isis.poly.edu with CAMELLIA256-SHA encrypted SMTP; 27 Jul 2011 14:02:32 -0000 Message-ID: <4E301A5D.6000902@isis.poly.edu> Date: Wed, 27 Jul 2011 08:02:05 -0600 From: Massimiliano Pala Organization: NYU Poly User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Miller, Timothy J." References: <111BE2BC-8215-4B1F-A673-581A9E9690E3@mitre.org> <1E851B43-084F-4ABC-BADB-71CF9D4C281D@checkpoint.com> <4E2F2A2D.2000407@isis.poly.edu> <2157E25B-6522-48AB-87EF-59D3F5C4CE3C@mitre.org> In-Reply-To: <2157E25B-6522-48AB-87EF-59D3F5C4CE3C@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Tangent: browsers (Re: Which is the new KPI research that is telling us how PKI is going on?) 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, 27 Jul 2011 14:02:34 -0000 On 07/27/2011 05:58 AM, Miller, Timothy J. wrote: [..] > OTOH, don't let the perfect be the enemy of the good enough. Heheheh... I am always in favor of good enough.. but when it *is* good enough! :D If the security level we are achieving is the same as the one "implemented" by the TSA guys at the airport (annoying and practically useless).. I think we can and should do better than that.. :D For example, keeping track if a certificate/key (also if untrusted) has changed over time when connecting to a server could help in mitigating the MITM threat if the first time you connect you were not already MITM-ed.. but who's really implementing that (if non-auth connections are permitted) besides.. SSH ? :D Cheers, -- tel.718-260-4009 | web: http://member.acm.org/~openca/ Massimiliano Pala, Ph.D. Director, OpenCA Labs Professor, NYU Poly From matt@mattmccutchen.net Wed Jul 27 10:30:53 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2203A21F8906 for ; Wed, 27 Jul 2011 10:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPve0qa+Prxx for ; Wed, 27 Jul 2011 10:30:52 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3994A21F88B7 for ; Wed, 27 Jul 2011 10:30:48 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id E8EF559807B; Wed, 27 Jul 2011 10:30:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=DSScmQbJVRncRPGCW5LOVFRlcGE/935WbbCCBglce/y 5jh6/O16CDAa7QRZ5YzECfzCrNTeTwnm75GYEcsgCS34rX8/83fvkL30RXe7v11n 0dvCUsjFOLVK69qfKW2OxayXQJF+DQMBAS+s/HZ+LHln0DZ4PbCSP7FAoTpJ2vSs = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=2YKtOXYV0/jTZgxTCxEoQmXiZ74=; b=fzWiYhewgo T+3FHXSyojbibcwXMR6K+Pt1Y2xa1h7vGCWhOZTOSveLfAcNhaDvoAmRauUOSj8B M5pRD7ONMQ/EAK9y4w5uSHVs0shuXeHxdiEVZlI3VPToR7TTldPR9mU3xKW2+Yrs OUDsgP/+4PBxQytySvEK8f85aLbj1QnL8= Received: from [10.5.0.146] (unknown [192.80.55.242]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id 7FA4C59806C; Wed, 27 Jul 2011 10:30:45 -0700 (PDT) From: Matt McCutchen To: Max Pala In-Reply-To: <6984433C-7959-448E-AD83-9E8938536AF1@isis.poly.edu> References: <4E2C8B17.3080803@isis.poly.edu> <1311569025.10022.17.camel@localhost> <6984433C-7959-448E-AD83-9E8938536AF1@isis.poly.edu> Content-Type: text/plain; charset="UTF-8" Date: Wed, 27 Jul 2011 13:30:43 -0400 Message-ID: <1311787843.2084.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Tangent: browsers (Re: Which is the new KPI research that is telling us how PKI is going on?) 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, 27 Jul 2011 17:30:53 -0000 On Mon, 2011-07-25 at 16:18 -0600, Max Pala wrote: > I understand what the browser vendors point of view is. The problem is > the assumption that to users can give any value to https:// vs > http:// . Plenty of research demonstrated that that is not true. One > of the few elements that users can recognize is the lock.. Not the > protocol identifier. For users, recognition of the indication is not as good as one would like. But web developers and sysadmins will type in https URLs and expect the system to honor their stipulation. > After all, encrypting contents to an "unknown" or "unveriifed" party > is no different (Let's say "worse" to avoid getting tangled in separate issues.) > than not encrypting it at all. That's the point. It is still an > "untrusted" connection.. Exactly as an http:// one. That is correct, but that does not mean you can take a https request where the server authentication failed and just turn off the indicators or otherwise redirect to a less secure mode, for the reasons I explained. > If browser vendors implemented the concept of trusted/not-trusted not > based on just an "s" What you literally said has historically been a common misconception, but Mozilla has fully recovered from it with the removal of the lock in Firefox 4 (see https://groups.google.com/group/mozilla.dev.usability/msg/b88a91ee318e0d05 ). I think what you really intend to complain about here is the regime of all-or-nothing server authentication. When it fails, it fails, and that can be a pain. But it lends a single (more-or-less) well-defined meaning to https URLs, which is a powerful abstraction. The alternative is to make web developers think about security policy every time they write a link to a secure site; maybe they should, but in practice that is a huge burden that we are currently getting by without. -- Matt From tmiller@mitre.org Wed Jul 27 11:19:33 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1750E21F8BE2 for ; Wed, 27 Jul 2011 11:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjFVH-Rxorjt for ; Wed, 27 Jul 2011 11:19:32 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA3F21F8BB9 for ; Wed, 27 Jul 2011 11:19:32 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7C35621B1271; Wed, 27 Jul 2011 14:19:31 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 745DF21B0B8F; Wed, 27 Jul 2011 14:19:31 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 27 Jul 2011 14:19:31 -0400 From: "Miller, Timothy J." To: Massimiliano Pala Date: Wed, 27 Jul 2011 14:19:30 -0400 Thread-Topic: [pkix] Tangent: browsers (Re: Which is the new KPI research that is telling us how PKI is going on?) Thread-Index: AcxMibo7Cj3FpgchSheZvg2jyf/NSQ== Message-ID: <524A135C-A56B-4FF6-8C37-7DBC29A2FC2D@mitre.org> References: <111BE2BC-8215-4B1F-A673-581A9E9690E3@mitre.org> <1E851B43-084F-4ABC-BADB-71CF9D4C281D@checkpoint.com> <4E2F2A2D.2000407@isis.poly.edu> <2157E25B-6522-48AB-87EF-59D3F5C4CE3C@mitre.org> <4E301A5D.6000902@isis.poly.edu> In-Reply-To: <4E301A5D.6000902@isis.poly.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-2-623605173"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Tangent: browsers (Re: Which is the new KPI research that is telling us how PKI is going on?) 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, 27 Jul 2011 18:19:33 -0000 --Apple-Mail-2-623605173 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 27, 2011, at 9:02 AM, Massimiliano Pala wrote: > For example, keeping track if a certificate/key (also if untrusted) = has changed > over time when connecting to a server could help in mitigating the = MITM threat > if the first time you connect you were not already MITM-ed.. but who's = really > implementing that (if non-auth connections are permitted) besides.. = SSH ? :D Certificate Patrol (Firefox extension). The Google Certificate Catalog has the data available in DNS TXT = records, but I'm not certain who's using it yet. -- T --Apple-Mail-2-623605173 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA3MjcxODE5MzBaMCMGCSqGSIb3DQEJBDEWBBQGi0AePGSusicrwvkJ oeI6CAjrXjByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgEBha7RhNPplj5MgzMplQ2L+DjH0SjrtxjcQ vvcliJ2kr1L5Gzu0ObxcE1DR6hvJ8Q/sXVKFZQpkA2qkt26g7VICu2GDpUAOcGeKKGaLcgS8UXdo hqYDvpx3WljqdRAt37L4eFZXiBYdECLl+ObKc/KOcAB94er1HNpjdwfRo6ZWAAAAAAAA --Apple-Mail-2-623605173-- From kent@bbn.com Thu Jul 28 07:01:26 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596AF21F8C09 for ; Thu, 28 Jul 2011 07:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJi78ZDiWnAn for ; Thu, 28 Jul 2011 07:01:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8353521F8C17 for ; Thu, 28 Jul 2011 07:01:25 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58199 helo=[130.129.71.153]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QmR9M-000ISj-0c; Thu, 28 Jul 2011 10:01:20 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <000c01cc49e6$88d15e30$9a741a90$@eu> References: <000c01cc49e6$88d15e30$9a741a90$@eu> Date: Thu, 28 Jul 2011 10:01:05 -0400 To: "Erik Andersen" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Directory list , SG17-Q11 , PKIX Subject: Re: [pkix] Intermediate CA vs. subject CA 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, 28 Jul 2011 14:01:26 -0000 At 11:46 AM +0200 7/24/11, Erik Andersen wrote: >Content-Type: multipart/alternative; > boundary="----=_NextPart_000_000D_01CC49F7.4C5A2E30" >Content-Language: da > >The terms intermediate CA and subject CA are used in the PKIX >publications and in X.509. I have not found any exact definitions of >those term in any PKIX document, but found some in 8.1.2 of X.509, >but I am not sure that these definition are generally accepted in >the PKI community. > >According to an intermediate CA is an CA issuing cross-certificate, >while the subject CA is the one for which the cross-certificate is >issued. However, the two CAs could have both roles. > >Erik Andersen Erik, In PKIX, I think we use these terms relative to a given cert in the context of a specific cert path. Thus the "subject CA" is the CA that issued the cert to the indicated subject, which might be an EE or a CA. An "intermediate CA" is a CA that lies between a TA and a subject CA, in the context of a cert path and a specified CA. Steve