From internet-drafts@ietf.org Tue Jan 3 12:00:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216B311E80F3; Tue, 3 Jan 2012 12:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y0OAuXdP3Uj; Tue, 3 Jan 2012 12:00:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10F711E80FC; Tue, 3 Jan 2012 12:00:25 -0800 (PST) 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.64p1 Message-ID: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 12:00:25 -0800 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-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: Tue, 03 Jan 2012 20:00:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : CMC Extensions: Server Key Generation Author(s) : Jim Schaad Sean Turner Paul Timmel Filename : draft-ietf-pkix-cmc-serverkeygeneration-00.txt Pages : 22 Date : 2012-01-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-ietf-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-ietf-pkix-cmc-serverkeygeneration-= 00.txt From internet-drafts@ietf.org Sun Jan 8 07:06:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F394321F85AE; Sun, 8 Jan 2012 07:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzKuQS+oIv0S; Sun, 8 Jan 2012 07:06:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB3A21F858F; Sun, 8 Jan 2012 07:06:22 -0800 (PST) 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.64p1 Message-ID: <20120108150622.31042.3072.idtracker@ietfa.amsl.com> Date: Sun, 08 Jan 2012 07:06:22 -0800 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-est-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: Sun, 08 Jan 2012 15:06:31 -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 : Enrollment over Secure Transport Author(s) : Max Pritikin Peter E. Yee Filename : draft-ietf-pkix-est-00.txt Pages : 25 Date : 2012-01-06 This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple yet functional certificate management protocol targeting simple Public Key Infrastructure clients that need to acquire client certificate(s) and associated Certification Authority (CA) certificate(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-est-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-est-00.txt From wwwrun@rfc-editor.org Fri Jan 6 20:04:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA2921F85AC for ; Fri, 6 Jan 2012 20:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rr-5R2GYg8F for ; Fri, 6 Jan 2012 20:04:26 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0B50021F8582 for ; Fri, 6 Jan 2012 20:04:26 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C753672E004; Fri, 6 Jan 2012 20:02:02 -0800 (PST) To: david.cooper@nist.gov, stefans@microsoft.com, stephen.farrell@cs.tcd.ie, sharon.boeyen@entrust.com, housley@vigilsec.com, wpolk@nist.gov, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20120107040202.C753672E004@rfc-editor.org> Date: Fri, 6 Jan 2012 20:02:02 -0800 (PST) X-Mailman-Approved-At: Sun, 08 Jan 2012 07:09:15 -0800 Cc: pkix@ietf.org, rfc-editor@rfc-editor.org, terrafrost@gmail.com Subject: [pkix] [Editorial Errata Reported] RFC5280 (3085) X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 07 Jan 2012 04:04:26 -0000 The following errata report has been submitted for RFC5280, "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=5280&eid=3085 -------------------------------------- Type: Editorial Reported by: Jim Wigginton Section: A.1 Original Text ------------- BuiltInStandardAttributes ::= SEQUENCE { country-name CountryName OPTIONAL, administration-domain-name AdministrationDomainName OPTIONAL, network-address [0] IMPLICIT NetworkAddress OPTIONAL, -- see also extended-network-address terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL, private-domain-name [2] PrivateDomainName OPTIONAL, organization-name [3] IMPLICIT OrganizationName OPTIONAL, -- see also teletex-organization-name numeric-user-identifier [4] IMPLICIT NumericUserIdentifier OPTIONAL, personal-name [5] IMPLICIT PersonalName OPTIONAL, -- see also teletex-personal-name organizational-unit-names [6] IMPLICIT OrganizationalUnitNames OPTIONAL } -- see also teletex-organizational-unit-names Corrected Text -------------- BuiltInStandardAttributes ::= SEQUENCE { country-name CountryName OPTIONAL, administration-domain-name AdministrationDomainName OPTIONAL, network-address [0] IMPLICIT NetworkAddress OPTIONAL, -- see also extended-network-address terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL, private-domain-name [2] IMPLICIT PrivateDomainName OPTIONAL, organization-name [3] IMPLICIT OrganizationName OPTIONAL, -- see also teletex-organization-name numeric-user-identifier [4] IMPLICIT NumericUserIdentifier OPTIONAL, personal-name [5] IMPLICIT PersonalName OPTIONAL, -- see also teletex-personal-name organizational-unit-names [6] IMPLICIT OrganizationalUnitNames OPTIONAL } -- see also teletex-organizational-unit-names Notes ----- Seems to me that private-domain-name ought to be tagged IMPLICIT just like everything else? 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. -------------------------------------- RFC5280 (draft-ietf-pkix-rfc3280bis-11) -------------------------------------- Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Publication Date : May 2008 Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From stephen.farrell@cs.tcd.ie Sun Jan 8 07:04:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC3E21F8570 for ; Sun, 8 Jan 2012 07:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OI7zWjU-P9gs for ; Sun, 8 Jan 2012 07:04:26 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 65A3B21F856E for ; Sun, 8 Jan 2012 07:04:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 15B6B157C09; Sun, 8 Jan 2012 15:04:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1326035063; bh=j6NJxzZ++HjqZm +SPsunX7NqyAS16GWcbFubLtfUbRw=; b=2fQ6Q3uM7hXLJy9rDygy29pUcgjDP4 Hxn+F36XUwF1XjHu5E3/FB1a7l9/KnSXR6gvCPXx9UJOlobe/MUZWPvguGAiRu4D +f8AHJSS2a4S0kWmuyiqobRnvkGHqWH/eNN/vuk7B4dQVlON7/tDH1L/nHOjxv4d gMuXxxAXW24KLr1i8tB+AatAtjYF/OB6feh+0wS/iLoDOt4amvECMASlbG3RHOKS t3fgF5z5AcVC6wFlg6E4JaC23q9a4WskMFFmsycOeHK/Iqafm4FtD1dCswiri5bM jI8VK/TQKFkh6n80nmxBv4kJ6JuxeKGp81+a1h5go0ojE7Og5UcpyXdA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id DRJZmeuULlju; Sun, 8 Jan 2012 15:04:23 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.44.64.156]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D1E47157550; Sun, 8 Jan 2012 15:04:17 +0000 (GMT) Message-ID: <4F09B066.9030004@cs.tcd.ie> Date: Sun, 08 Jan 2012 15:04:06 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: RFC Errata System References: <20120107040202.C753672E004@rfc-editor.org> In-Reply-To: <20120107040202.C753672E004@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 08 Jan 2012 07:09:15 -0800 Cc: stefans@microsoft.com, terrafrost@gmail.com, stefan@aaa-sec.com, pkix@ietf.org Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (3085) X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 08 Jan 2012 15:04:28 -0000 Regardless of whether or not this change would be correct, its not editorial if you change the asn.1 module IMO. And changing the x.400 syntax is also not a thing for pkix so I'd also argue that this ought be rejected regardless of editorial/technical unless we made a mistake copying the x.400 stuff or something like that. S On 01/07/2012 04:02 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC5280, > "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=5280&eid=3085 > > -------------------------------------- > Type: Editorial > Reported by: Jim Wigginton > > Section: A.1 > > Original Text > ------------- > BuiltInStandardAttributes ::= SEQUENCE { > country-name CountryName OPTIONAL, > administration-domain-name AdministrationDomainName OPTIONAL, > network-address [0] IMPLICIT NetworkAddress OPTIONAL, > -- see also extended-network-address > terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL, > private-domain-name [2] PrivateDomainName OPTIONAL, > organization-name [3] IMPLICIT OrganizationName OPTIONAL, > -- see also teletex-organization-name > numeric-user-identifier [4] IMPLICIT NumericUserIdentifier > OPTIONAL, > personal-name [5] IMPLICIT PersonalName OPTIONAL, > -- see also teletex-personal-name > organizational-unit-names [6] IMPLICIT OrganizationalUnitNames > OPTIONAL } > -- see also teletex-organizational-unit-names > > > Corrected Text > -------------- > BuiltInStandardAttributes ::= SEQUENCE { > country-name CountryName OPTIONAL, > administration-domain-name AdministrationDomainName OPTIONAL, > network-address [0] IMPLICIT NetworkAddress OPTIONAL, > -- see also extended-network-address > terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL, > private-domain-name [2] IMPLICIT PrivateDomainName OPTIONAL, > organization-name [3] IMPLICIT OrganizationName OPTIONAL, > -- see also teletex-organization-name > numeric-user-identifier [4] IMPLICIT NumericUserIdentifier > OPTIONAL, > personal-name [5] IMPLICIT PersonalName OPTIONAL, > -- see also teletex-personal-name > organizational-unit-names [6] IMPLICIT OrganizationalUnitNames > OPTIONAL } > -- see also teletex-organizational-unit-names > > > Notes > ----- > Seems to me that private-domain-name ought to be tagged IMPLICIT just like everything else? > > 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. > > -------------------------------------- > RFC5280 (draft-ietf-pkix-rfc3280bis-11) > -------------------------------------- > Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile > Publication Date : May 2008 > Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk > Category : PROPOSED STANDARD > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG > From stefan@aaa-sec.com Sun Jan 8 19:41:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE87A21F85EE for ; Sun, 8 Jan 2012 19:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBd6DGo01IDg for ; Sun, 8 Jan 2012 19:41:58 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.111]) by ietfa.amsl.com (Postfix) with ESMTP id CEFE821F85D7 for ; Sun, 8 Jan 2012 19:41:56 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 1E43C1CF5586 for ; Mon, 9 Jan 2012 04:41:54 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id f5Ph3rGWFIwV for ; Mon, 9 Jan 2012 04:41:53 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D26F01CF558A for ; Mon, 9 Jan 2012 04:41:52 +0100 (CET) Received: (qmail 26125 invoked from network); 9 Jan 2012 03:41:52 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.218]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Jan 2012 03:41:52 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 09 Jan 2012 04:41:45 +0100 From: Stefan Santesson To: Stephen Farrell , RFC Errata System Message-ID: Thread-Topic: [Editorial Errata Reported] RFC5280 (3085) In-Reply-To: <4F09B066.9030004@cs.tcd.ie> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3408928912_14165351" X-Mailman-Approved-At: Sun, 08 Jan 2012 19:46:48 -0800 Cc: stefans@microsoft.com, terrafrost@gmail.com, pkix@ietf.org Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (3085) X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 09 Jan 2012 03:41:59 -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_3408928912_14165351 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I believe this Errata is wrong and should be rejected. PrivateDomainName (unlike the other tagged components) is an untagged CHOICE type. Quote from X.680: '30.8 The IMPLICIT alternative shall not be used if the type defined by "Type" is an untagged choice type or an untagged open type or an untagged "DummyReference" (see ITU-T Rec. X.683 | ISO/IEC 8824-4, 8.3).' /Stefan On 12-01-08 4:04 PM, "Stephen Farrell" wrote: > >Regardless of whether or not this change would be >correct, its not editorial if you change the asn.1 >module IMO. > >And changing the x.400 syntax is also not a thing >for pkix so I'd also argue that this ought be >rejected regardless of editorial/technical unless >we made a mistake copying the x.400 stuff or >something like that. > >S > >On 01/07/2012 04:02 AM, RFC Errata System wrote: >> The following errata report has been submitted for RFC5280, >> "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=5280&eid=3085 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Jim Wigginton >> >> Section: A.1 >> >> Original Text >> ------------- >> BuiltInStandardAttributes ::= SEQUENCE { >> country-name CountryName OPTIONAL, >> administration-domain-name AdministrationDomainName OPTIONAL, >> network-address [0] IMPLICIT NetworkAddress OPTIONAL, >> -- see also extended-network-address >> terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL, >> private-domain-name [2] PrivateDomainName OPTIONAL, >> organization-name [3] IMPLICIT OrganizationName OPTIONAL, >> -- see also teletex-organization-name >> numeric-user-identifier [4] IMPLICIT NumericUserIdentifier >> OPTIONAL, >> personal-name [5] IMPLICIT PersonalName OPTIONAL, >> -- see also teletex-personal-name >> organizational-unit-names [6] IMPLICIT OrganizationalUnitNames >> OPTIONAL } >> -- see also teletex-organizational-unit-names >> >> >> Corrected Text >> -------------- >> BuiltInStandardAttributes ::= SEQUENCE { >> country-name CountryName OPTIONAL, >> administration-domain-name AdministrationDomainName OPTIONAL, >> network-address [0] IMPLICIT NetworkAddress OPTIONAL, >> -- see also extended-network-address >> terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL, >> private-domain-name [2] IMPLICIT PrivateDomainName OPTIONAL, >> organization-name [3] IMPLICIT OrganizationName OPTIONAL, >> -- see also teletex-organization-name >> numeric-user-identifier [4] IMPLICIT NumericUserIdentifier >> OPTIONAL, >> personal-name [5] IMPLICIT PersonalName OPTIONAL, >> -- see also teletex-personal-name >> organizational-unit-names [6] IMPLICIT OrganizationalUnitNames >> OPTIONAL } >> -- see also teletex-organizational-unit-names >> >> >> Notes >> ----- >> Seems to me that private-domain-name ought to be tagged IMPLICIT just >>like everything else? >> >> 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. >> >> -------------------------------------- >> RFC5280 (draft-ietf-pkix-rfc3280bis-11) >> -------------------------------------- >> Title : Internet X.509 Public Key Infrastructure >>Certificate and Certificate Revocation List (CRL) Profile >> Publication Date : May 2008 >> Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, >>R. Housley, W. Polk >> Category : PROPOSED STANDARD >> Source : Public-Key Infrastructure (X.509) >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> --B_3408928912_14165351 Content-type: application/xml; name="default.xml" Content-disposition: attachment; filename="default.xml" Content-transfer-encoding: base64 UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rD MBBF94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHt MSbnqdKrvNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwH JKm0Po7Aco2dCWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBm qpqzuohDuiDcU/OLLlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5t ncXG290o68hn48XsTwCr/4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2 AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb 69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8 UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6P qMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQA BgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzM TQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0u iLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtH V+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKEIQcAANsdAAAWAAAAdGhl bWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezYDbRpo9gt6nG8O/ZO M7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH1jv7e2/e+70/ 82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvOFbyuYpIQ BPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpbwyEN CeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWl qrPRXa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+ 0dpst1ccvAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8 VfNyLcH3uOgCQAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX3 8tl3L589Qcf3nx7f//H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/ feYHQvlMzXn+xeNfnz5+/uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb 6UjiFOtZPPo7KnbQNyeYYQ+uRVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5 KjT3x+nIP7kYV3F7GB/45m7j1IlvZ5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4N BZd8qNBdilqYeinp04GTTVOhbZpAXCY+AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY4 8ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05EpPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCc V5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9DHHA6dxw36HECffp3eA2HTkmTRNEvxkL TyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFVPv/qkcfuN7VlbwIJvprZPtGo5+FO tuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkXhgatt0x2o2223cncXfeQMtZT E0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJejDPYtNcDrWQkc9UjiTIu 4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSCs062dDlXCr69zmR1 bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzbGBVhMVH4e0KU e20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YTS6u1xVJ0 2AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZkGoL y9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE 9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST 0gbzVDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ9 0zsgW+B6Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshk VMVcmVmzB+SAsL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxO ndhL6Pwt+C9NLFf36epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgH UZz1GAbL/UwGV0BI/wPrHxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlV ltp856NZKxbrC96olvOeIFtbdpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDm K1f1QxQf3INAb8GV/5jZT1MygydTB9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQt Ift5pNgiG7QW04lWCi75Dg2uYI7Xona1LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6 rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td +BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVtZS90aGVtZS9fcmVs cy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQrdQDhOQ1DTY/ JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCCjm837RVn kUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvVABmW UJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAI AAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s UEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRoZW1l L3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN 0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1h bmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA --B_3408928912_14165351-- From stefan@aaa-sec.com Sun Jan 8 21:44:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1187221F8642 for ; Sun, 8 Jan 2012 21:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.908 X-Spam-Level: X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_21=0.6, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gooWacjrxjxu for ; Sun, 8 Jan 2012 21:44:18 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.111]) by ietfa.amsl.com (Postfix) with ESMTP id 239ED21F85D7 for ; Sun, 8 Jan 2012 21:44:17 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 69E6C1D226F1 for ; Mon, 9 Jan 2012 06:44:16 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 43-ROU76iatG for ; Mon, 9 Jan 2012 06:44:15 +0100 (CET) Received: from s329.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 7FC4B1CD5AC2 for ; Mon, 9 Jan 2012 06:44:15 +0100 (CET) Received: (qmail 18791 invoked from network); 9 Jan 2012 05:44:15 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.218]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s329.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Jan 2012 05:44:15 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 09 Jan 2012 06:44:11 +0100 From: Stefan Santesson To: Erik Andersen , 'Tom Gindin' Message-ID: Thread-Topic: [pkix] Unclear public-key certificate definition in X.509 In-Reply-To: <003c01cb9aae$5f233140$1d6993c0$@eu> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3408936255_14631499" Cc: 'PKIX' , 'Jean-Paul Lemaire' Subject: Re: [pkix] Unclear public-key certificate definition in X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 09 Jan 2012 05:44:20 -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_3408936255_14631499 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Eric, I think you can solve the confusion with something more close to the original and stay compliant with table 1 by choosing the term "NCA" for the name of the CA. It would be more compatible to the chosen term "UCA" for the unique identifier of the CA. Using CA1 and CA(A) is just adding confusion and is not necessary to provide the point of the text. I would suggest: Original text: Specifically, the certificate of a user with distinguished name A and unique identifier UA, produced by the certification authority with name CA and unique identifier UCA, has the following form: CA<> = CA{V,SN,AI,CA,UCA,A,UA,Ap,TA} New text: Specifically, the public-key certificate of a user with distinguished name A and unique identifier UA, produced by the CA with name NCA and and unique identifier UCA, has the following form: CA<> = CA{V,SN,AI,NCA,A,Ap,UCA,UA,TA,Ex} /Stefan On 10-12-13 11:13 AM, "Erik Andersen" wrote: >Hi Tom, > >Any suggestion? If you have some ideas, how will affect Table 1 of X.509. >The term CA(X) was introduced already in the first edition (1988). It is >nothing of my doing. > >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: Tom Gindin [mailto:tgindin@us.ibm.com] >Sendt: 11. december 2010 00:16 >Til: Erik Andersen >Cc: Jean-Paul Lemaire; 'PKIX' >Emne: Re: SV: SV: [pkix] Unclear public-key certificate definition in >X.509 > > Please use a different parameter name than A here. The bracket >style is not the reason for the confusion. > > Tom Gindin > > > > > >From: >"Erik Andersen" >To: >Tom Gindin/Watson/IBM@IBMUS >Cc: >"'PKIX'" , "Jean-Paul Lemaire" > >Date: >12/08/2010 10:12 AM >Subject: >SV: SV: [pkix] Unclear public-key certificate definition in X.509 > > > >Hi Tom and others, > >I am finally back on this one. I agree with your last statement. What do >you >think about writing CA[A] instead of CA(A)? > >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: Tom Gindin [mailto:tgindin@us.ibm.com] >Sendt: 13. november 2010 01:38 >Til: Erik Andersen >Cc: 'PKIX' >Emne: Re: SV: [pkix] Unclear public-key certificate definition in X.509 > > It no longer has the problem which it had before. Of course, >it's > >a little odd to describe a certificate as a function of specifically the >DN of the issuer, since the critical functional dependency is on the >issuer's key pair. My own wording would go: produced by a >certification > >authority with the distinguished name CA1, unique identifier UCA1, and >key > >pair KCA1, has the following form: Cert<> = KCA1 { your args }. >The CA(A) expression just confuses me, because it suggests that the CA is >a function of the subject name. > >Tom Gindin > > > > > >From: >"Erik Andersen" >To: >Tom Gindin/Watson/IBM@IBMUS >Cc: >"'PKIX'" >Date: >11/12/2010 03:58 AM >Subject: >SV: [pkix] Unclear public-key certificate definition in X.509 > > > >Hi Tom, > >Thanks for comments. I share your concern. I have updated the suggested >text. Please check. > >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: Tom Gindin [mailto:tgindin@us.ibm.com] >Sendt: 9. november 2010 14:25 >Til: Erik Andersen >Cc: PKIX >Emne: Re: [pkix] Unclear public-key certificate definition in X.509 > > Since A denotes the user's distinguished name, it confuses me >(and > > >probably others as well) to describe the CA as having name CA(A) and UID >UCA(A). Would this not be easier to understand if the CA had name CA(B) >and ID UCA(B), or if subscripts were used? After all, the CA is a >different entity than the user, and your expression has A being used in >both contexts. > >Tom Gindin > > > > > >From: >"Erik Andersen" >To: >"PKIX" >Date: >11/03/2010 12:28 PM >Subject: >[pkix] Unclear public-key certificate definition in X.509 >Sent by: >pkix-bounces@ietf.org > > > >I have proposed some modification to a paragraph in X.509 as documented >by > > >the attached file. > >I wonder whether you PKIX guys have comments on this proposal. Any >comment > > >will be appreciated. > >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 > [attachment "DR-xx.pdf" deleted by Tom Gindin/Watson/IBM] >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix > > >[attachment "X509-pot-01.pdf" deleted by Tom Gindin/Watson/IBM] > > > > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix --B_3408936255_14631499 Content-type: application/xml; name="default[3].xml" Content-disposition: attachment; filename="default[3].xml" Content-transfer-encoding: base64 UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rD MBBF94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHt MSbnqdKrvNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwH JKm0Po7Aco2dCWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBm qpqzuohDuiDcU/OLLlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5t ncXG290o68hn48XsTwCr/4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2 AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb 69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8 UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6P qMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQA BgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzM TQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0u iLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtH V+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKEIQcAANsdAAAWAAAAdGhl bWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezYDbRpo9gt6nG8O/ZO M7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH1jv7e2/e+70/ 82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvOFbyuYpIQ BPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpbwyEN CeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWl qrPRXa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+ 0dpst1ccvAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8 VfNyLcH3uOgCQAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX3 8tl3L589Qcf3nx7f//H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/ feYHQvlMzXn+xeNfnz5+/uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb 6UjiFOtZPPo7KnbQNyeYYQ+uRVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5 KjT3x+nIP7kYV3F7GB/45m7j1IlvZ5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4N BZd8qNBdilqYeinp04GTTVOhbZpAXCY+AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY4 8ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05EpPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCc V5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9DHHA6dxw36HECffp3eA2HTkmTRNEvxkL TyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFVPv/qkcfuN7VlbwIJvprZPtGo5+FO tuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkXhgatt0x2o2223cncXfeQMtZT E0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJejDPYtNcDrWQkc9UjiTIu 4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSCs062dDlXCr69zmR1 bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzbGBVhMVH4e0KU e20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YTS6u1xVJ0 2AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZkGoL y9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE 9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST 0gbzVDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ9 0zsgW+B6Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshk VMVcmVmzB+SAsL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxO ndhL6Pwt+C9NLFf36epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgH UZz1GAbL/UwGV0BI/wPrHxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlV ltp856NZKxbrC96olvOeIFtbdpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDm K1f1QxQf3INAb8GV/5jZT1MygydTB9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQt Ift5pNgiG7QW04lWCi75Dg2uYI7Xona1LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6 rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td +BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVtZS90aGVtZS9fcmVs cy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQrdQDhOQ1DTY/ JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCCjm837RVn kUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvVABmW UJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAI AAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s UEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRoZW1l L3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN 0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1h bmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA --B_3408936255_14631499-- From turners@ieca.com Mon Jan 9 06:17:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFC221F8758 for ; Mon, 9 Jan 2012 06:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xu89gMCQGh9Z for ; Mon, 9 Jan 2012 06:17:01 -0800 (PST) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [70.85.130.22]) by ietfa.amsl.com (Postfix) with ESMTP id 59D4C21F875D for ; Mon, 9 Jan 2012 06:17:01 -0800 (PST) Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id 8774596763F24; Mon, 9 Jan 2012 08:16:59 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id 7835496763EEF for ; Mon, 9 Jan 2012 08:16:59 -0600 (CST) Received: from [74.202.225.34] (port=1670 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RkG1y-0008Rf-CI; Mon, 09 Jan 2012 08:16:58 -0600 Message-ID: <4F0AF6DB.3010308@ieca.com> Date: Mon, 09 Jan 2012 09:16:59 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [74.202.225.34]:1670 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 9 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: terrafrost@gmail.com, pkix@ietf.org Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (3085) X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 09 Jan 2012 14:17:07 -0000 I'm going to reject this errata based on Stefan's response. spt On 1/8/12 10:41 PM, Stefan Santesson wrote: > I believe this Errata is wrong and should be rejected. > > PrivateDomainName (unlike the other tagged components) is an untagged > CHOICE type. > > > Quote from X.680: > > '30.8 The IMPLICIT alternative shall not be used if the type defined > by "Type" is an > untagged choice type or an untagged open type or an untagged > "DummyReference" (see ITU-T Rec. X.683 | ISO/IEC 8824-4, 8.3).' > > > > /Stefan > > > > On 12-01-08 4:04 PM, "Stephen Farrell" wrote: > >> >> Regardless of whether or not this change would be >> correct, its not editorial if you change the asn.1 >> module IMO. >> >> And changing the x.400 syntax is also not a thing >> for pkix so I'd also argue that this ought be >> rejected regardless of editorial/technical unless >> we made a mistake copying the x.400 stuff or >> something like that. >> >> S >> >> On 01/07/2012 04:02 AM, RFC Errata System wrote: >>> The following errata report has been submitted for RFC5280, >>> "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=5280&eid=3085 >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Jim Wigginton >>> >>> Section: A.1 >>> >>> Original Text >>> ------------- >>> BuiltInStandardAttributes ::= SEQUENCE { >>> country-name CountryName OPTIONAL, >>> administration-domain-name AdministrationDomainName OPTIONAL, >>> network-address [0] IMPLICIT NetworkAddress OPTIONAL, >>> -- see also extended-network-address >>> terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL, >>> private-domain-name [2] PrivateDomainName OPTIONAL, >>> organization-name [3] IMPLICIT OrganizationName OPTIONAL, >>> -- see also teletex-organization-name >>> numeric-user-identifier [4] IMPLICIT NumericUserIdentifier >>> OPTIONAL, >>> personal-name [5] IMPLICIT PersonalName OPTIONAL, >>> -- see also teletex-personal-name >>> organizational-unit-names [6] IMPLICIT OrganizationalUnitNames >>> OPTIONAL } >>> -- see also teletex-organizational-unit-names >>> >>> >>> Corrected Text >>> -------------- >>> BuiltInStandardAttributes ::= SEQUENCE { >>> country-name CountryName OPTIONAL, >>> administration-domain-name AdministrationDomainName OPTIONAL, >>> network-address [0] IMPLICIT NetworkAddress OPTIONAL, >>> -- see also extended-network-address >>> terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL, >>> private-domain-name [2] IMPLICIT PrivateDomainName OPTIONAL, >>> organization-name [3] IMPLICIT OrganizationName OPTIONAL, >>> -- see also teletex-organization-name >>> numeric-user-identifier [4] IMPLICIT NumericUserIdentifier >>> OPTIONAL, >>> personal-name [5] IMPLICIT PersonalName OPTIONAL, >>> -- see also teletex-personal-name >>> organizational-unit-names [6] IMPLICIT OrganizationalUnitNames >>> OPTIONAL } >>> -- see also teletex-organizational-unit-names >>> >>> >>> Notes >>> ----- >>> Seems to me that private-domain-name ought to be tagged IMPLICIT just >>> like everything else? >>> >>> 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. >>> >>> -------------------------------------- >>> RFC5280 (draft-ietf-pkix-rfc3280bis-11) >>> -------------------------------------- >>> Title : Internet X.509 Public Key Infrastructure >>> Certificate and Certificate Revocation List (CRL) Profile >>> Publication Date : May 2008 >>> Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, >>> R. Housley, W. Polk >>> Category : PROPOSED STANDARD >>> Source : Public-Key Infrastructure (X.509) >>> Area : Security >>> Stream : IETF >>> Verifying Party : IESG >>> > From internet-drafts@ietf.org Tue Jan 10 05:52:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3C221F8631; Tue, 10 Jan 2012 05:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24FFX1vS578n; Tue, 10 Jan 2012 05:52:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CCC21F849D; Tue, 10 Jan 2012 05:52:40 -0800 (PST) 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.64p1 Message-ID: <20120110135240.7399.46181.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2012 05:52:40 -0800 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-cmp-transport-protocols-15.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: Tue, 10 Jan 2012 13:52:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : Internet X.509 Public Key Infrastructure -- HTTP Transpo= rt for CMP Author(s) : Tomi Kause Martin Peylo Filename : draft-ietf-pkix-cmp-transport-protocols-15.txt Pages : 15 Date : 2012-01-10 This document describes how to layer the Certificate Management Protocol over HTTP. It is the "CMPtrans" document referenced in RFC 4210 and therefore updates the reference given therein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols= -15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-= 15.txt From kent@bbn.com Tue Jan 10 07:52:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16B221F85FD for ; Tue, 10 Jan 2012 07:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.233 X-Spam-Level: X-Spam-Status: No, score=-105.233 tagged_above=-999 required=5 tests=[AWL=-0.493, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhEg-iRYx8dy for ; Tue, 10 Jan 2012 07:52:40 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 54F4321F848B for ; Tue, 10 Jan 2012 07:52:40 -0800 (PST) Received: from [192.1.255.205] (port=49182) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Rke07-0000JW-Cc for pkix@ietf.org; Tue, 10 Jan 2012 10:52:39 -0500 Mime-Version: 1.0 Message-Id: Date: Tue, 10 Jan 2012 10:43:45 -0500 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] WGLC for draft-ietf-pkix-cmp-transport-protocols-15.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: Tue, 10 Jan 2012 15:52:40 -0000 Folks, An updated version of this doc has been posted. The authors have requested WGLC. The WGLC will end in two weeks (1/25/2012). Steve From mrex@sap.com Tue Jan 10 08:34:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EC121F84EF for ; Tue, 10 Jan 2012 08:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.907 X-Spam-Level: X-Spam-Status: No, score=-9.907 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE7lWXBR5kY0 for ; Tue, 10 Jan 2012 08:34:48 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 429EA21F84D9 for ; Tue, 10 Jan 2012 08:34:47 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0AGYcNN003367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jan 2012 17:34:38 +0100 (MET) From: Martin Rex Message-Id: <201201101634.q0AGYbNP020934@fs4113.wdf.sap.corp> To: stephen.farrell@cs.tcd.ie (Stephen Farrell) Date: Tue, 10 Jan 2012 17:34:37 +0100 (MET) In-Reply-To: <4F09B066.9030004@cs.tcd.ie> from "Stephen Farrell" at Jan 8, 12 03:04:06 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: stefan@aaa-sec.com, terrafrost@gmail.com, stefans@microsoft.com, pkix@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (3085) 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, 10 Jan 2012 16:34:49 -0000 Stephen Farrell wrote: > > Regardless of whether or not this change would be > correct, its not editorial if you change the asn.1 > module IMO. > > And changing the x.400 syntax is also not a thing > for pkix so I'd also argue that this ought be > rejected regardless of editorial/technical unless > we made a mistake copying the x.400 stuff or > something like that. I'm _no_ ASN.1 expert, but the reported issue looks like one of several inconsistencies of rfc5280 with ITU-T/X.509. rfc5280 claims to be a profile of X.509 08/2005, but I see the definition of "BuiltInStandardAttributes" only in X.509 11/2008, Annex J, page 163. In X.509 11/2008, the relevant ASN.1 module says: DEFINITIONS IMPLICIT TAGS ::= BEGIN [...] BuiltInStandardAttributes ::= SEQUENCE { country-name CountryName OPTIONAL, administration-domain-name AdministrationDomainName OPTIONAL, network-address [0] NetworkAddress OPTIONAL, -- see also extended-network-address terminal-identifier [1] TerminalIdentifier OPTIONAL, private-domain-name [2] PrivateDomainName OPTIONAL, organization-name [3] OrganizationName OPTIONAL, -- see also teletex-organization-name numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, personal-name [5] PersonalName OPTIONAL, -- see also teletex-personal-name organizational-unit-names [6] OrganizationalUnitNames OPTIONAL -- see also teletex-organizational-unit-names } whereas rfc5280 Appendix A.1 says: A.1. Explicitly Tagged Module, 1988 Syntax DEFINITIONS EXPLICIT TAGS ::= BEGIN [...] BuiltInStandardAttributes ::= SEQUENCE { country-name CountryName OPTIONAL, administration-domain-name AdministrationDomainName OPTIONAL, network-address [0] IMPLICIT NetworkAddress OPTIONAL, -- see also extended-network-address terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL, private-domain-name [2] PrivateDomainName OPTIONAL, organization-name [3] IMPLICIT OrganizationName OPTIONAL, -- see also teletex-organization-name numeric-user-identifier [4] IMPLICIT NumericUserIdentifier OPTIONAL, personal-name [5] IMPLICIT PersonalName OPTIONAL, -- see also teletex-personal-name organizational-unit-names [6] IMPLICIT OrganizationalUnitNames OPTIONAL } -- see also teletex-organizational-unit-names So the divergence from X.509 appears to exists not only for "PrivateDomainName", but also CountryName and AdministrativeDomainName. -Martin From denis.pinkas@bull.net Tue Jan 10 08:43:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852D521F871E; Tue, 10 Jan 2012 08:43:59 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urfWV9FHf+a7; Tue, 10 Jan 2012 08:43:58 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id EC1A121F86C8; Tue, 10 Jan 2012 08:43:57 -0800 (PST) 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 1CEB218030; Tue, 10 Jan 2012 17:43:57 +0100 (CET) In-Reply-To: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> To: internet-drafts@ietf.org MIME-Version: 1.0 X-KeepSent: 9E321C48:D936AE67-C1257981:005B3E7B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Tue, 10 Jan 2012 17:43:56 +0100 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 10/01/2012 17:43:57, Serialize complete at 10/01/2012 17:43:57 Content-Type: multipart/alternative; boundary="=_alternative 005BBAE4C1257981_=" Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-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: Tue, 10 Jan 2012 16:43:59 -0000 Message en plusieurs parties au format MIME --=_alternative 005BBAE4C1257981_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 MTIgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1wa2l4LWNtYy1zZXJ2ZXJrZXlnZW5lcmF0aW9uLTAw LnR4dCANCkNNQyBFeHRlbnNpb25zOiBTZXJ2ZXIgS2V5IEdlbmVyYXRpb24gDQoNCg0KMSkgQSB2 dWxuZXJhYmlsaXR5IGFuYWx5c2lzIGlzIG1pc3NpbmcgYW5kIHRodXMgc2VjdXJpdHkgcmVxdWly ZW1lbnRzIGFyZSANCm1pc3NpbmcuDQoNCg0KMikgVGhlIGFkdmFudGFnZXMgYW5kIGRpc2FkdmFu dGFnZXMgb2YgZWFjaCBtZXRob2QgaXMgbm90IGRpc2N1c3NlZCBvciANCmV4cGxhaW5lZCBiZWZv cmUgdGhlIG1ldGhvZHMgYXJlIGludHJvZHVjZWQuDQoNCg0KMykgVGhlIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIHNlY3Rpb24gc3RhdGVzOiDigJxQT1AgaXMgZXh0cmVtZWx5IA0KaW1wb3J0YW50 4oCdLiANCiAgIEhvd2V2ZXIsIHRoZSB0ZXh0IHBsYWNlZCBhZnRlciBkb2VzIG5vdCBwcm92aWRl IGEgcmF0aW9uYWw6IA0KDQogICDigJxIb3dldmVyLCBQT1AgaGVyZSBpcyBkaWZmZXJlbnQgdGhh biBpbg0KICAgY2xpZW50LWdlbmVyYXRlZCBrZXkgY2VydGlmaWNhdGlvbiByZXF1ZXN0cyBpbiB0 aGF0IHRoZSBQT1AgaXMNCiAgIG5lY2Vzc2FyeSB0byBwcm92ZSB0byB0aGUgc2VydmVyIHRoYXQg dGhlIGNsaWVudCBoYXMgcG9zc2Vzc2lvbiBvZg0KICAgdGhlIHByaXZhdGUga2V5IG5lY2Vzc2Fy eSB0byBkZWNyeXB0IHRoZSBzZXJ2ZXItZ2VuZXJhdGVkIHByaXZhdGUga2V5DQogICByYXRoZXIg dGhhbiBwb3NzZXNzIHRoZSBwcml2YXRlIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIHB1YmxpYyBr ZXkgaW4NCiAgIHRoZSByZXF1ZXN0Lg0KDQpJZiB0aGUgY2xpZW50IGRvZXMgbm90IHBvc3Nlc3Mg dGhlIHByaXZhdGUga2V5LCBoZSB3aWxsIG5vdCBiZSBhYmxlIHRvIA0KZGVjcnlwdCB0aGUgcHJp dmF0ZSBrZXkgDQphbmQgdGh1cyB0aGVyZSBpcyBubyBoYXJtLiBJTU8sIFBPUCBpcyB1bm5lY2Vz c2FyeS4gVGhpcyB3aWxsIGxlYWQgdG8gbWFueSANCnNpbXBsaWZpY2F0aW9ucyBvbiB0aGUgZG9j dW1lbnQuDQoNCg0KNCkgSG93IHJlcGxheSBwcm90ZWN0aW9uIG9mIHRoZSBtZXNzYWdlcyBpcyBh Y2hpZXZlZCBpcyBub3QgZXhwbGFpbmVkLCANCmV2ZW4gaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHNlY3Rpb24uDQoNCg0KNSkgVGhlIHRleHQgc3RhdGVzIGluIHNlY3Rpb24gMS4xLjE6 DQoNCuKAnFRoZSBzaGFyZWQgc2VjcmV0IGFsbG93cyB0aGUgc2VydmVyIHRvIGF1dGhlbnRpY2F0 ZSB0aGUgY2xpZW50IGFuZCBhbGxvd3MgDQp0aGUgc2VydmVyIHRvIGVuY3J5cHQgDQp0aGUgc2Vy dmVyLXNpZGUgZ2VuZXJhdGVkIGtleSBmb3IgdGhlIGNsaWVudOKAnS4NCg0KVGhpcyBpcyBub3Qg dmVyeSBzZWN1cmUuIElmIHRoZSBzaGFyZWQga2V5IGlzIGRpc2NvdmVyZWQsIHRoZW4gYWxsIA0K cHJldmlvdXMgcHJpdmF0ZSBrZXlzIG1heSBiZSBkZWNyeXB0ZWQuIA0KVGhlcmUgc2hvdWxkIGJl IGEgc3RhdGljIGtleSBkZXJpdmVkIGZyb20gdGhlIHNoYXJlZCBrZXkgdG8gYmUgdXNlZCBmb3Ig DQphdXRoZW50aWNhdGlvbiBhbmQgDQphbiBlcGhlbWVyYWwga2V5IGRlcml2ZWQgZnJvbSB0aGUg c2hhcmVkIGtleSBhbmQgZnJvbSBhIHJhbmRvbSAodGh1cyB0aGUgDQplbmNyeXB0aW9uIGtleSBp cyBkaWZmZXJlbnQgDQpmb3IgZXZlcnkgcHJpdmF0ZSBrZXkpLiBUaGUgZGVyaXZhdGlvbiBmdW5j dGlvbiBzaG91bGQgYmUgb25lIHdheS4gVGhlIA0KZGVyaXZhdGlvbiBtZXRob2RzIHNob3VsZCBi ZSBwYXJ0IA0Kb2YgdGhlIHNwZWNpZmljYXRpb24uDQoNCg0KNikgVGhlIHRleHQgc3RhdGVzIGlu IHNlY3Rpb24gMS4xLjE6DQoNCuKAnFRoZSBzaGFyZWQgc2VjcmV0IGFsbG93cyB0aGUgc2VydmVy IHRvIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGFuZCBhbGxvd3MgDQp0aGUgc2VydmVyIHRvIGVu Y3J5cHQgDQp0aGUgc2VydmVyLXNpZGUgZ2VuZXJhdGVkIGtleSBmb3IgdGhlIGNsaWVudC4gVGhl IHNoYXJlZCBzZWNyZXQgaXMgDQpkaXN0cmlidXRlZCB2aWEgYW4gb3V0LW9mLWJhbmQgDQptZWNo YW5pc20gdGhhdCBpcyBvdXQtb2Ytc2NvcGUgb2YgdGhpcyBkb2N1bWVudOKAnS4NCg0KVGhpcyBp cyBpbnN1ZmZpY2llbnQuIFRoZXJlIGlzIGEgbmVlZCB0byBkaXN0cmlidXRlIElEcyBhbmQgc2hh cmVkIHNlY3JldHMgDQpzbyB0aGF0IHRoZSBzZXJ2ZXIgDQptYXkgc2VsZWN0IHRoZSByaWdodCBr ZXkgd2hlbiBpdCByZWNlaXZlcyBhIHJlcXVlc3QuICBUaGUgSUQgbXVzdCBiZSBwYXJ0IA0Kb2Yg dGhlIHJlcXVlc3QuDQoNCjcpIFRoZSB0ZXh0IHN0YXRlcyBpbiBzZWN0aW9uIDEuMS4xOg0KDQog ICDigJxUaGUgY2xpZW50IGNhbiB2YWxpZGF0ZSB0aGF0IHRoZSByZXNwb25zZSBjYW1lIGZyb20g dGhlIENBIGJ5DQogICB2YWxpZGF0aW5nIHRoZSBkaWdpdGFsIHNpZ25hdHVyZSBvbiB0aGUgU2ln bmVkRGF0YSB0byBhIFRydXN0IEFuY2hvcg0KICAgKFRBKeKAnS4gDQoNCk5vLiBUaGUgY2xpZW50 IG11c3QgdmFsaWRhdGUgdGhhdCB0aGUgcmVzcG9uc2UgY2FtZSBmcm9tIHRoZSBDQSB1c2luZyB0 aGUgDQphdXRoZW50aWNhdGlvbiBrZXkuDQoNCg0KOCkgVGhlIHRleHQgc3RhdGVzIGluIHNlY3Rp b24gMS4xLjI6DQoNCiAgIOKAnFBPUCBpcyBuZWNlc3NhcnkgYmVjYXVzZSB0aGUgY2xpZW50IHdv dWxkIGxpa2UgdGhlDQogICByZXNwb25zZSBlbmNyeXB0ZWQgd2l0aCBhIHB1YmxpYyBrZXkgYW5k IHRoZSBzZXJ2ZXIgbXVzdCBkZXRlcm1pbmUNCiAgIHRoYXQgdGhlIGNsaWVudCBhY3R1YWxseSBo YXMgdGhlIHByaXZhdGUga2V5IGFzc29jaWF0ZWQgd2l0aCB0aGUNCiAgIHB1YmxpYyBrZXku4oCd IA0KDQpQT1AgaXMgbm90IG5lY2Vzc2FyeS4gU2VlIGFib3ZlLg0KDQoNCjkpIFR5cG8gb24gcGFn ZSA3LCBsYXN0IGxpbmUgYmVmb3JlIHRoZSBlbmQgb2YgdGhlIHBhZ2UuIA0KUmVwbGFjZSDigJxk YXRl4oCdIGJ5IOKAnGRhdGHigJ0uDQoNCg0KMTApIFRoZSB0ZXh0IHN0YXRlcyBpbiBzZWN0aW9u IDIuMSBvbiBwYWdlIDE0Og0KDQogICDigJxXaGVuIHRoaXMgbWV0aG9kIGlzIHVzZWQgd2l0aCB0 aGUgY2VydGlmaWNhdGUgb3B0aW9uLCB0aGUgc2VydmVyIE1VU1QNCiAgIHZhbGlkYXRlIHRoZSBj ZXJ0aWZpY2F0ZSBiYWNrIHRvIGEgdHJ1c3QgYW5jaG9yLiAgRnVydGhlciwgdGhlIHNlcnZlcg0K ICAgTVVTVCBjaGVjayB0aGF0IHRoZSBjbGllbnQgcHJvdmlkZWQgY2VydGlmaWNhdGUgYmVsb25n cyB0byB0aGUgc2FtZQ0KICAgY2xpZW50IHRoYXQgYXV0aGVudGljYXRlZCB0aGUgY2VydGlmaWNh dGUgcmVxdWVzdCAoZS5nLiB0aGUNCiAgIGNlcnRpZmljYXRlIHN1YmplY3RzIG1hdGNoLCBvciB0 aGUgY2xpZW50IHByb3ZpZGVkIGNlcnRpZmljYXRlDQogICBiZWxvbmdzIHRvIHRoZSBzYW1lIGVu dGl0eSBhcyB0aGUgYXV0aGVudGljYXRpb24gc2hhcmVkIHNlY3JldCkuICBJZg0KICAgZWl0aGVy IG9mIHRoZXNlIGNoZWNrcyBmYWlscywgdGhlbiB0aGUgc2VydmVyIE1VU1QgcmV0dXJuIGENCiAg IENNQ0ZhaWxJbmZvIHdpdGggdGhlIHZhbHVlIG9mIGJhZENlcnRpZmljYXRlLCB3aGljaCBpcyBk ZWZpbmVkIGluDQogICBTZWN0aW9uIDXigJ0uDQoNClRoaXMgaXMgbm90IG5lY2Vzc2FyeS4gVGhp cyBwYXJhZ3JhcGggc2hvdWxkIGJlIGRlbGV0ZWQuDQoNCg0KMTEpIFRoZSB0ZXh0IHN0YXRlcyBp biBzZWN0aW9uIDIuMiBvbiBwYWdlIDE1Og0KDQogICDigJxJbiBnZW5lcmFsLCB3aGlsZSBpdA0K ICAgaXMgZXhwZWN0ZWQgdGhhdCB0aGUgc2FtZSBpZGVudGl0eSB0b2tlbiBhbmQgc2hhcmVkIHNl Y3JldCB1c2VkIHRvIGRvDQogICB0aGUgaWRlbnRpdHkgYXV0aGVudGljYXRpb24gYXJlIHVzZWQg dG8gZGVyaXZlIHRoZSBrZXkgZW5jcnlwdGlvbiBrZXkNCiAgIHRoaXMgaXMgbm90IHJlcXVpcmVk 4oCdLg0KDQpBcyBzdGF0ZWQgZWFybGllciwgdGhlIHVzZSBvZiB0aGUgc2FtZSBrZXkgc2hhbGwg bm90IGJlIHBvc3NpYmxlLg0KDQoNCjEyKSBUaGUgdGV4dCBzdGF0ZXMgaW4gc2VjdGlvbiA2IG9u IHBhZ2UgMjA6DQoNCiAgIOKAnENyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyBhbmQga2V5cyB1c2Vk IHRvIHByb3RlY3QgdGhlIHByaXZhdGUga2V5DQogICBzaG91bGQgYmUgYXQgbGVhc3QgYXMgc3Ry b25nIGFzIHRoZSBwcml2YXRlIGtleSdzIGludGVuZGVkIHN0cmVuZ3Ro4oCdLg0KDQpBIHNlcGFy YXRlIGRpc2N1c3Npb24gb24gdGhlIHN0cmVuZ3RoIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBrZXkg YW5kIG9mIHRoZSANCmVuY3J5cHRpb24ga2V5IGlzIG5lZWRlZC4NCg0KRGVuaXMNCg0KDQoNCkRl IDogICAgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQpBIDogICAgIGktZC1hbm5vdW5jZUBpZXRm Lm9yZw0KQ2MgOiAgICBwa2l4QGlldGYub3JnDQpEYXRlIDogIDAzLzAxLzIwMTIgMjE6MDENCk9i amV0IDogW3BraXhdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcGtpeC1jbWMtc2VydmVya2V5Z2Vu ZXJhdGlvbi0wMC50eHQNCkVudm95w6kgcGFyIDogICAgcGtpeC1ib3VuY2VzQGlldGYub3JnDQoN Cg0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l IEludGVybmV0LURyYWZ0cyANCmRpcmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVt IG9mIHRoZSBQdWJsaWMtS2V5IEluZnJhc3RydWN0dXJlIA0KKFguNTA5KSBXb3JraW5nIEdyb3Vw IG9mIHRoZSBJRVRGLg0KDQogICAgICAgICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IENNQyBF eHRlbnNpb25zOiBTZXJ2ZXIgS2V5IEdlbmVyYXRpb24NCiAgICAgICAgICAgICAgICAgQXV0aG9y KHMpICAgICAgIDogSmltIFNjaGFhZA0KICAgICAgICAgICAgICAgICAgICAgICAgICBTZWFuIFR1 cm5lcg0KICAgICAgICAgICAgICAgICAgICAgICAgICBQYXVsIFRpbW1lbA0KICAgICAgICAgICAg ICAgICBGaWxlbmFtZSAgICAgICAgOiANCmRyYWZ0LWlldGYtcGtpeC1jbWMtc2VydmVya2V5Z2Vu ZXJhdGlvbi0wMC50eHQNCiAgICAgICAgICAgICAgICAgUGFnZXMgICAgICAgICAgIDogMjINCiAg ICAgICAgICAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxMi0wMS0wMg0KDQogICBUaGlzIGRv Y3VtZW50IGRlZmluZXMgYSBzZXQgb2YgZXh0ZW5zaW9ucyB0byB0aGUgQ2VydGlmaWNhdGUNCiAg IE1hbmFnZW1lbnQgb3ZlciBDTVMgKENNQykgcHJvdG9jb2wgdGhhdCBhZGRyZXNzZXMgdGhlIGRl c2lyZSB0bw0KICAgc3VwcG9ydCBzZXJ2ZXItc2lkZSBnZW5lcmF0aW9uIG9mIGtleXMuICBUaGlz IHNlcnZpY2UgaXMgcHJvdmlkZWQgYnkNCiAgIHRoZSBkZWZpbml0aW9uIG9mIGFkZGl0aW9uYWwg Y29udHJvbCBzdGF0ZW1lbnRzIHdpdGhpbiB0aGUgQ01DDQogICBhcmNoaXRlY3R1cmUuICBBZGRp dGlvbmFsIENNQyBlcnJvcnMgYXJlIGFsc28gZGVmaW5lZC4NCg0KDQpBIFVSTCBmb3IgdGhpcyBJ bnRlcm5ldC1EcmFmdCBpczoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtcGtpeC1jbWMtc2VydmVya2V5Z2VuZXJhdGlvbi0wMC50eHQNCg0KDQpJbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpUaGlzIEludGVybmV0LURyYWZ0IGNhbiBi ZSByZXRyaWV2ZWQgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtcGtpeC1jbWMtc2VydmVya2V5Z2VuZXJhdGlvbi0wMC50eHQNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGtpeCBtYWlsaW5nIGxpc3QN CnBraXhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGtp eA0KDQoNCg== --=_alternative 005BBAE4C1257981_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4xMiBjb21tZW50cyBvbiBkcmFmdC1pZXRm LXBraXgtY21jLXNlcnZlcmtleWdlbmVyYXRpb24tMDAudHh0DQo8YnI+DQpDTUMgRXh0ZW5zaW9u czogU2VydmVyIEtleSBHZW5lcmF0aW9uIDwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjEpIEEgdnVsbmVyYWJpbGl0eSBhbmFseXNpcyBpcyBt aXNzaW5nDQphbmQgdGh1cyBzZWN1cml0eSByZXF1aXJlbWVudHMgYXJlIG1pc3NpbmcuPC9mb250 Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+MikgVGhl IGFkdmFudGFnZXMgYW5kIGRpc2FkdmFudGFnZXMNCm9mIGVhY2ggbWV0aG9kIGlzIG5vdCBkaXNj dXNzZWQgb3IgZXhwbGFpbmVkIGJlZm9yZSB0aGUgbWV0aG9kcyBhcmUgaW50cm9kdWNlZC48L2Zv bnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4zKSBU aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbg0Kc3RhdGVzOiDigJxQT1AgaXMgZXh0 cmVtZWx5IGltcG9ydGFudOKAnS4gPGJyPg0KICZuYnNwOyBIb3dldmVyLCB0aGUgdGV4dCBwbGFj ZWQgYWZ0ZXIgZG9lcyBub3QgcHJvdmlkZSBhIHJhdGlvbmFsOiA8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A74oCcSG93ZXZlciwg UE9QIGhlcmUgaXMNCmRpZmZlcmVudCB0aGFuIGluPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO2NsaWVudC1nZW5lcmF0ZWQga2V5IGNlcnRp ZmljYXRpb24NCnJlcXVlc3RzIGluIHRoYXQgdGhlIFBPUCBpczwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDtuZWNlc3NhcnkgdG8gcHJvdmUg dG8NCnRoZSBzZXJ2ZXIgdGhhdCB0aGUgY2xpZW50IGhhcyBwb3NzZXNzaW9uIG9mPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO3RoZSBwcml2 YXRlIGtleSBuZWNlc3NhcnkNCnRvIGRlY3J5cHQgdGhlIHNlcnZlci1nZW5lcmF0ZWQgcHJpdmF0 ZSBrZXk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsg Jm5ic3A7cmF0aGVyIHRoYW4gcG9zc2VzcyB0aGUNCnByaXZhdGUga2V5IGFzc29jaWF0ZWQgd2l0 aCB0aGUgcHVibGljIGtleSBpbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPiZuYnNwOyAmbmJzcDt0aGUgcmVxdWVzdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5JZiB0aGUgY2xpZW50IGRvZXMgbm90IHBvc3Nlc3Mg dGhlDQpwcml2YXRlIGtleSwgaGUgd2lsbCBub3QgYmUgYWJsZSB0byBkZWNyeXB0IHRoZSBwcml2 YXRlIGtleSA8YnI+DQphbmQgdGh1cyB0aGVyZSBpcyBubyBoYXJtLiBJTU8sIFBPUCBpcyB1bm5l Y2Vzc2FyeS4gVGhpcyB3aWxsIGxlYWQgdG8gbWFueQ0Kc2ltcGxpZmljYXRpb25zIG9uIHRoZSBk b2N1bWVudC48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij40KSBIb3cgcmVwbGF5IHByb3RlY3Rpb24gb2YgdGhlIG1lc3NhZ2VzDQppcyBhY2hp ZXZlZCBpcyBub3QgZXhwbGFpbmVkLCBldmVuIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBzZWN0aW9uLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjUpIFRoZSB0ZXh0IHN0YXRlcyBpbiBzZWN0aW9uIDEuMS4xOjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPuKAnFRoZSBzaGFyZWQgc2Vj cmV0IGFsbG93cyB0aGUgc2VydmVyDQp0byBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBhbmQgYWxs b3dzIHRoZSBzZXJ2ZXIgdG8gZW5jcnlwdCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij50aGUgc2VydmVyLXNpZGUgZ2VuZXJhdGVkIGtleSBmb3IgdGhlDQpjbGll bnTigJ0uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ VGhpcyBpcyBub3QgdmVyeSBzZWN1cmUuIElmIHRoZSBzaGFyZWQNCmtleSBpcyBkaXNjb3ZlcmVk LCB0aGVuIGFsbCBwcmV2aW91cyBwcml2YXRlIGtleXMgbWF5IGJlIGRlY3J5cHRlZC4gPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhlcmUgc2hvdWxkIGJlIGEg c3RhdGljIGtleSBkZXJpdmVkDQpmcm9tIHRoZSBzaGFyZWQga2V5IHRvIGJlIHVzZWQgZm9yIGF1 dGhlbnRpY2F0aW9uIGFuZCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij5hbiBlcGhlbWVyYWwga2V5IGRlcml2ZWQgZnJvbSB0aGUgc2hhcmVkDQprZXkgYW5kIGZy b20gYSByYW5kb20gKHRodXMgdGhlIGVuY3J5cHRpb24ga2V5IGlzIGRpZmZlcmVudCA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5mb3IgZXZlcnkgcHJpdmF0ZSBr ZXkpLiBUaGUgZGVyaXZhdGlvbg0KZnVuY3Rpb24gc2hvdWxkIGJlIG9uZSB3YXkuIFRoZSBkZXJp dmF0aW9uIG1ldGhvZHMgc2hvdWxkIGJlIHBhcnQgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+b2YgdGhlIHNwZWNpZmljYXRpb24uPC9mb250Pg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+NikgVGhlIHRleHQgc3RhdGVz IGluIHNlY3Rpb24gMS4xLjE6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+4oCcVGhlIHNoYXJlZCBzZWNyZXQgYWxsb3dzIHRoZSBzZXJ2ZXINCnRvIGF1 dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGFuZCBhbGxvd3MgdGhlIHNlcnZlciB0byBlbmNyeXB0IDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPnRoZSBzZXJ2ZXItc2lk ZSBnZW5lcmF0ZWQga2V5IGZvciB0aGUNCmNsaWVudC4gVGhlIHNoYXJlZCBzZWNyZXQgaXMgZGlz dHJpYnV0ZWQgdmlhIGFuIG91dC1vZi1iYW5kIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPm1lY2hhbmlzbSB0aGF0IGlzIG91dC1vZi1zY29wZSBvZiB0aGlzDQpk b2N1bWVudOKAnS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij5UaGlzIGlzIGluc3VmZmljaWVudC4gVGhlcmUgaXMgYSBuZWVkDQp0byBkaXN0cmlidXRl IElEcyBhbmQgc2hhcmVkIHNlY3JldHMgc28gdGhhdCB0aGUgc2VydmVyIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPm1heSBzZWxlY3QgdGhlIHJpZ2h0IGtleSB3 aGVuIGl0IHJlY2VpdmVzDQphIHJlcXVlc3QuICZuYnNwO1RoZSBJRCBtdXN0IGJlIHBhcnQgb2Yg dGhlIHJlcXVlc3QuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+NykgVGhlIHRleHQgc3RhdGVzIGluIHNlY3Rpb24gMS4xLjE6PC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO+KAnFRoZSBj bGllbnQgY2FuIHZhbGlkYXRlDQp0aGF0IHRoZSByZXNwb25zZSBjYW1lIGZyb20gdGhlIENBIGJ5 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNw O3ZhbGlkYXRpbmcgdGhlIGRpZ2l0YWwNCnNpZ25hdHVyZSBvbiB0aGUgU2lnbmVkRGF0YSB0byBh IFRydXN0IEFuY2hvcjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PiZuYnNwOyAmbmJzcDsoVEEp4oCdLiAmbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5Oby4gVGhlIGNsaWVudCBtdXN0IHZhbGlkYXRlIHRoYXQg dGhlDQpyZXNwb25zZSBjYW1lIGZyb20gdGhlIENBIHVzaW5nIHRoZSBhdXRoZW50aWNhdGlvbiBr ZXkuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+OCkgVGhlIHRleHQgc3RhdGVzIGluIHNlY3Rpb24gMS4xLjI6PC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO+KAnFBPUCBpcyBu ZWNlc3NhcnkgYmVjYXVzZQ0KdGhlIGNsaWVudCB3b3VsZCBsaWtlIHRoZTwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDtyZXNwb25zZSBlbmNy eXB0ZWQgd2l0aA0KYSBwdWJsaWMga2V5IGFuZCB0aGUgc2VydmVyIG11c3QgZGV0ZXJtaW5lPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO3Ro YXQgdGhlIGNsaWVudCBhY3R1YWxseQ0KaGFzIHRoZSBwcml2YXRlIGtleSBhc3NvY2lhdGVkIHdp dGggdGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7 ICZuYnNwO3B1YmxpYyBrZXku4oCdIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPlBPUCBpcyBub3QgbmVjZXNzYXJ5LiBTZWUgYWJvdmUuPC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+OSkgVHlwbyBv biBwYWdlIDcsIGxhc3QgbGluZSBiZWZvcmUNCnRoZSBlbmQgb2YgdGhlIHBhZ2UuIDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlJlcGxhY2Ug4oCcZGF0ZeKAnSBi eSDigJxkYXRh4oCdLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjEwKSBUaGUgdGV4dCBzdGF0ZXMgaW4gc2VjdGlvbiAyLjENCm9uIHBhZ2Ug MTQ6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5i c3A7ICZuYnNwO+KAnFdoZW4gdGhpcyBtZXRob2QgaXMNCnVzZWQgd2l0aCB0aGUgY2VydGlmaWNh dGUgb3B0aW9uLCB0aGUgc2VydmVyIE1VU1Q8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7dmFsaWRhdGUgdGhlIGNlcnRpZmljYXRlDQpiYWNr IHRvIGEgdHJ1c3QgYW5jaG9yLiAmbmJzcDtGdXJ0aGVyLCB0aGUgc2VydmVyPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO01VU1QgY2hlY2sg dGhhdCB0aGUgY2xpZW50DQpwcm92aWRlZCBjZXJ0aWZpY2F0ZSBiZWxvbmdzIHRvIHRoZSBzYW1l PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNw O2NsaWVudCB0aGF0IGF1dGhlbnRpY2F0ZWQNCnRoZSBjZXJ0aWZpY2F0ZSByZXF1ZXN0IChlLmcu IHRoZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAm bmJzcDtjZXJ0aWZpY2F0ZSBzdWJqZWN0cyBtYXRjaCwNCm9yIHRoZSBjbGllbnQgcHJvdmlkZWQg Y2VydGlmaWNhdGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4m bmJzcDsgJm5ic3A7YmVsb25ncyB0byB0aGUgc2FtZSBlbnRpdHkNCmFzIHRoZSBhdXRoZW50aWNh dGlvbiBzaGFyZWQgc2VjcmV0KS4gJm5ic3A7SWY8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7ZWl0aGVyIG9mIHRoZXNlIGNoZWNrcw0KZmFp bHMsIHRoZW4gdGhlIHNlcnZlciBNVVNUIHJldHVybiBhPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO0NNQ0ZhaWxJbmZvIHdpdGggdGhlIHZh bHVlDQpvZiBiYWRDZXJ0aWZpY2F0ZSwgd2hpY2ggaXMgZGVmaW5lZCBpbjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDtTZWN0aW9uIDXigJ0u PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhpcyBp cyBub3QgbmVjZXNzYXJ5LiBUaGlzIHBhcmFncmFwaA0Kc2hvdWxkIGJlIGRlbGV0ZWQuPC9mb250 Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+MTEpIFRo ZSB0ZXh0IHN0YXRlcyBpbiBzZWN0aW9uIDIuMg0Kb24gcGFnZSAxNTo8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A74oCcSW4gZ2Vu ZXJhbCwgd2hpbGUgaXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mbmJzcDsgJm5ic3A7aXMgZXhwZWN0ZWQgdGhhdCB0aGUgc2FtZQ0KaWRlbnRpdHkgdG9rZW4g YW5kIHNoYXJlZCBzZWNyZXQgdXNlZCB0byBkbzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDt0aGUgaWRlbnRpdHkgYXV0aGVudGljYXRpb24N CmFyZSB1c2VkIHRvIGRlcml2ZSB0aGUga2V5IGVuY3J5cHRpb24ga2V5PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO3RoaXMgaXMgbm90IHJl cXVpcmVk4oCdLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPkFzIHN0YXRlZCBlYXJsaWVyLCB0aGUgdXNlIG9mIHRoZSBzYW1lDQprZXkgc2hhbGwgbm90 IGJlIHBvc3NpYmxlLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjEyKSBUaGUgdGV4dCBzdGF0ZXMgaW4gc2VjdGlvbiA2IG9uDQpwYWdlIDIw OjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNw OyAmbmJzcDvigJxDcnlwdG9ncmFwaGljIGFsZ29yaXRobXMNCmFuZCBrZXlzIHVzZWQgdG8gcHJv dGVjdCB0aGUgcHJpdmF0ZSBrZXk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mbmJzcDsgJm5ic3A7c2hvdWxkIGJlIGF0IGxlYXN0IGFzDQpzdHJvbmcgYXMgdGhl IHByaXZhdGUga2V5J3MgaW50ZW5kZWQgc3RyZW5ndGjigJ0uPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+QSBzZXBhcmF0ZSBkaXNjdXNzaW9uIG9uIHRo ZSBzdHJlbmd0aA0Kb2YgdGhlIGF1dGhlbnRpY2F0aW9uIGtleSBhbmQgb2YgdGhlIGVuY3J5cHRp b24ga2V5IGlzIG5lZWRlZC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkRlbmlzPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkRlIDogJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZh Y2U9InNhbnMtc2VyaWYiPkEgOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+Q2MmbmJz cDs6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPnBraXhAaWV0Zi5vcmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9y PSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RGF0ZSA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjAzLzAxLzIwMTIgMjE6 MDE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJp ZiI+T2JqZXQgOiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5bcGtpeF0gSS1EIEFjdGlvbjoNCmRyYWZ0LWlldGYtcGtpeC1j bWMtc2VydmVya2V5Z2VuZXJhdGlvbi0wMC50eHQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNv bG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RW52b3nDqSBwYXIgOiAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5wa2l4 LWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8YnI+DQo8aHIgbm9zaGFkZT4NCjxicj4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFB1YmxpYy1LZXkgSW5mcmFzdHJ1Y3R1cmUgKFgu NTA5KSBXb3JraW5nDQpHcm91cCBvZiB0aGUgSUVURi48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KVGl0bGUgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IENNQyBFeHRlbnNpb25zOiBTZXJ2ZXIgS2V5 IEdlbmVyYXRpb248YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KQXV0aG9yKHMpICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogSmltIFNj aGFhZDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7U2VhbiBUdXJuZXI8 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO1BhdWwgVGltbWVsPGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CkZpbGVuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogZHJhZnQtaWV0Zi1wa2l4LWNt Yy1zZXJ2ZXJrZXlnZW5lcmF0aW9uLTAwLnR4dDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpQYWdlcyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDogMjI8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KRGF0ZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzogMjAxMi0wMS0wMjxicj4NCjxicj4NCiAmbmJzcDsgVGhpcyBk b2N1bWVudCBkZWZpbmVzIGEgc2V0IG9mIGV4dGVuc2lvbnMgdG8gdGhlIENlcnRpZmljYXRlPGJy Pg0KICZuYnNwOyBNYW5hZ2VtZW50IG92ZXIgQ01TIChDTUMpIHByb3RvY29sIHRoYXQgYWRkcmVz c2VzIHRoZSBkZXNpcmUgdG88YnI+DQogJm5ic3A7IHN1cHBvcnQgc2VydmVyLXNpZGUgZ2VuZXJh dGlvbiBvZiBrZXlzLiAmbmJzcDtUaGlzIHNlcnZpY2UgaXMgcHJvdmlkZWQNCmJ5PGJyPg0KICZu YnNwOyB0aGUgZGVmaW5pdGlvbiBvZiBhZGRpdGlvbmFsIGNvbnRyb2wgc3RhdGVtZW50cyB3aXRo aW4gdGhlIENNQzxicj4NCiAmbmJzcDsgYXJjaGl0ZWN0dXJlLiAmbmJzcDtBZGRpdGlvbmFsIENN QyBlcnJvcnMgYXJlIGFsc28gZGVmaW5lZC48YnI+DQo8YnI+DQo8YnI+DQpBIFVSTCBmb3IgdGhp cyBJbnRlcm5ldC1EcmFmdCBpczo8YnI+DQo8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXBraXgtY21jLXNlcnZlcmtleWdl bmVyYXRpb24tMDAudHh0Ij48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcGtpeC1jbWMtc2VydmVya2V5Z2VuZXJhdGlvbi0wMC50 eHQ8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8YnI+DQpJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KPC9mb250 PjwvdHQ+PGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iPjx0dD48 Zm9udCBzaXplPTI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2ZvbnQ+PC90 dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8YnI+DQpUaGlzIEludGVybmV0LURyYWZ0IGNh biBiZSByZXRyaWV2ZWQgYXQ6PGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj0iZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXBraXgtY21jLXNlcnZlcmtleWdlbmVy YXRpb24tMDAudHh0Ij48dHQ+PGZvbnQgc2l6ZT0yPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1wa2l4LWNtYy1zZXJ2ZXJrZXlnZW5lcmF0aW9uLTAwLnR4dDwv Zm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcGtpeCBtYWlsaW5nIGxpc3Q8 YnI+DQpwa2l4QGlldGYub3JnPGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXg+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXg8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250 IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 005BBAE4C1257981_=-- From housley@vigilsec.com Tue Jan 10 08:52:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5870421F85F4 for ; Tue, 10 Jan 2012 08:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtrDJrV2Hnu2 for ; Tue, 10 Jan 2012 08:52:05 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id B7F8621F85EA for ; Tue, 10 Jan 2012 08:52:05 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id E59929A478E; Tue, 10 Jan 2012 11:52:24 -0500 (EST) 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 xjSeJC1DWHs9; Tue, 10 Jan 2012 11:52:02 -0500 (EST) Received: from [192.168.43.193] (unknown [198.232.60.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2250C9A478D; Tue, 10 Jan 2012 11:52:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-46-14763438 From: Russ Housley In-Reply-To: Date: Tue, 10 Jan 2012 11:51:54 -0500 Message-Id: <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> To: denis.pinkas@bull.net X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] I-D Action: draft-ietf-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: Tue, 10 Jan 2012 16:52:06 -0000 --Apple-Mail-46-14763438 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Denis: > 3) The security considerations section states: =93POP is extremely = important=94.=20 > However, the text placed after does not provide a rational:=20 >=20 > =93However, POP here is different than in=20 > client-generated key certification requests in that the POP is=20 > necessary to prove to the server that the client has possession of=20= > the private key necessary to decrypt the server-generated private = key=20 > rather than possess the private key associated with the public key = in=20 > the request.=20 >=20 > If the client does not possess the private key, he will not be able to = decrypt the private key=20 > and thus there is no harm. IMO, POP is unnecessary. This will lead to = many simplifications on the document.=20 I do agree that there is no exposure if the private key cannot be = unwrapped (assuming the use of good algorithms and such). However, the = way I read it, the authors want proof that the private key could be = unwrapped and used. This seems like a good feature. Russ --Apple-Mail-46-14763438 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 3) The security considerations section = states: =93POP is extremely important=94. 
  However, the = text placed after does not provide a rational: 

   =93However, POP here is = different than in 
   client-generated key certification = requests in that the POP is 
   necessary to prove to the server that = the client has possession of 
   the private key necessary to decrypt = the server-generated private key 
   rather than possess the private key = associated with the public key in 
   the request. 

If the client does not possess the private key, he = will not be able to decrypt the private key 
and thus there is no = harm. IMO, POP is unnecessary. This will lead to many simplifications on = the document. 

I do agree that there is no exposure if the = private key cannot be unwrapped (assuming the use of good algorithms and = such).  However, the way I read it, the authors want proof = that the private key could be unwrapped and used.  This seems like = a good = feature.

Russ

= --Apple-Mail-46-14763438-- From stefan@aaa-sec.com Tue Jan 10 10:37:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AEE21F86A2 for ; Tue, 10 Jan 2012 10:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.058 X-Spam-Level: X-Spam-Status: No, score=-103.058 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZAoQrwu7pwC for ; Tue, 10 Jan 2012 10:37:46 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.111]) by ietfa.amsl.com (Postfix) with ESMTP id 29B3621F87DE for ; Tue, 10 Jan 2012 10:37:45 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id C00F31CF95DB for ; Tue, 10 Jan 2012 19:37:24 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id B2InKj2cc_6h for ; Tue, 10 Jan 2012 19:37:21 +0100 (CET) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 1DBD51D235BB for ; Tue, 10 Jan 2012 19:37:17 +0100 (CET) Received: (qmail 56416 invoked from network); 10 Jan 2012 18:37:15 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.202]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Jan 2012 18:37:15 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 10 Jan 2012 19:36:46 +0100 From: Stefan Santesson To: , Stephen Farrell Message-ID: Thread-Topic: [pkix] [Editorial Errata Reported] RFC5280 (3085) In-Reply-To: <201201101634.q0AGYbNP020934@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3409069035_636238" Cc: pkix@ietf.org, terrafrost@gmail.com, rfc-editor@rfc-editor.org Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (3085) X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 10 Jan 2012 18:37:48 -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_3409069035_636238 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Martin, Even though it might look to be different, I see no inconsistency between X.509 and RFC 5280. I'm not ASN.1 expert either, but I will try to sort this out, allowing others to shoot me down if I say something wrong here. The difference between IMPLICIT and EXPLICIT tags is that IMPLICIT tagging replaces the original tag of the underlying type. While EXPLICIT tag creates an outer "wrapping" TLV element with the specified tag value for the wrapping element, preserving the original tag on the underlying type in the inner element. IMPLICIT tagging is illegal if the underlying type has not tag, which is the case for the CHOICE type. This is easy to understand if the choice is between an integer or string element. It would be impossible to decode this if the universal tags for integer/stringType was replaced by an implicit tag. The decoder would not know if the chosen underlying value was an integer or a string. So even if you would specify IMPLICIT tagging for a CHOICE type, it will in fact result in EXPLICIT tagging, since there is not tag to replace. X.680 explains this: 30.6 The tagging construction specifies explicit tagging if any of the following holds: a) the "Tag EXPLICIT Type" alternative is used; b) the "Tag Type" alternative is used and the value of "TagDefault" for the module is either EXPLICIT TAGS or is empty; c) the "Tag Type" alternative is used and the value of "TagDefault" for the module is IMPLICIT TAGS or AUTOMATIC TAGS, but the type defined by "Type" is an untagged choice type, an untagged open type, or an untagged "DummyReference" (see ITU-T Rec. X.683 | ISO/IEC 8824-4, Error! Reference source not found.). So as you see c) is the case for the X.509 spec. X.509 has specified IMPLICIT as the default tagging for the module (set by "DEFINITIONS IMPLICIT TAGS") PrivateDomainName is in face of type CHOICE, which means that according to c), it will be provided with EXPLICIT tagging. The quoted RFC 5280 ASN.1 module has EXPLICIT tagging set as default (set by "DEFINITIONS EXPLICIT TAGS") This means that unlike the X.509 module, the RFC 5280 must specify where tags are IMPLICIT. The RFC 5280 module does this by defining IMPLICIT for all attributes except for PrivateDomainName, which is an untagged CHOICE type and thus have an EXPLICIT tag. CountryName and AdministrativeDomainName has no tags at all, so not differences here between X.509 and RFC 5280. So to sum this up, as I see it, X.509 and RFC 5280 uses identical tagging, expressed through different syntax. And, the errata is wrong. /Stefan On 12-01-10 5:34 PM, "Martin Rex" wrote: >Stephen Farrell wrote: >> >> Regardless of whether or not this change would be >> correct, its not editorial if you change the asn.1 >> module IMO. >> >> And changing the x.400 syntax is also not a thing >> for pkix so I'd also argue that this ought be >> rejected regardless of editorial/technical unless >> we made a mistake copying the x.400 stuff or >> something like that. > > >I'm _no_ ASN.1 expert, but the reported issue looks like >one of several inconsistencies of rfc5280 with ITU-T/X.509. > >rfc5280 claims to be a profile of X.509 08/2005, but I see the definition >of "BuiltInStandardAttributes" only in X.509 11/2008, Annex J, page 163. > >In X.509 11/2008, the relevant ASN.1 module says: > > DEFINITIONS IMPLICIT TAGS ::= > BEGIN > > [...] > > BuiltInStandardAttributes ::= SEQUENCE { > country-name CountryName OPTIONAL, > administration-domain-name AdministrationDomainName OPTIONAL, > network-address [0] NetworkAddress OPTIONAL, > -- see also extended-network-address > terminal-identifier [1] TerminalIdentifier OPTIONAL, > private-domain-name [2] PrivateDomainName OPTIONAL, > organization-name [3] OrganizationName OPTIONAL, > -- see also teletex-organization-name > numeric-user-identifier [4] NumericUserIdentifier OPTIONAL, > personal-name [5] PersonalName OPTIONAL, > -- see also teletex-personal-name > organizational-unit-names [6] OrganizationalUnitNames OPTIONAL > -- see also teletex-organizational-unit-names > } > > >whereas rfc5280 Appendix A.1 says: > > A.1. Explicitly Tagged Module, 1988 Syntax > > DEFINITIONS EXPLICIT TAGS ::= > > BEGIN > > [...] > > BuiltInStandardAttributes ::= SEQUENCE { > country-name CountryName OPTIONAL, > administration-domain-name AdministrationDomainName >OPTIONAL, > network-address [0] IMPLICIT NetworkAddress >OPTIONAL, > -- see also extended-network-address > terminal-identifier [1] IMPLICIT TerminalIdentifier >OPTIONAL, > private-domain-name [2] PrivateDomainName >OPTIONAL, > organization-name [3] IMPLICIT OrganizationName >OPTIONAL, > -- see also teletex-organization-name > numeric-user-identifier [4] IMPLICIT NumericUserIdentifier >OPTIONAL, > personal-name [5] IMPLICIT PersonalName >OPTIONAL, > -- see also teletex-personal-name > organizational-unit-names [6] IMPLICIT OrganizationalUnitNames >OPTIONAL } > -- see also teletex-organizational-unit-names > > >So the divergence from X.509 appears to exists not only for >"PrivateDomainName", but also CountryName and AdministrativeDomainName. > > >-Martin --B_3409069035_636238 Content-type: application/xml; name="default.xml" Content-disposition: attachment; filename="default.xml" Content-transfer-encoding: base64 UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rD MBBF94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHt MSbnqdKrvNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwH JKm0Po7Aco2dCWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBm qpqzuohDuiDcU/OLLlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5t ncXG290o68hn48XsTwCr/4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2 AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb 69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8 UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6P qMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQA BgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzM TQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0u iLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtH V+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKEIQcAANsdAAAWAAAAdGhl bWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezYDbRpo9gt6nG8O/ZO M7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH1jv7e2/e+70/ 82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvOFbyuYpIQ BPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpbwyEN CeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWl qrPRXa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+ 0dpst1ccvAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8 VfNyLcH3uOgCQAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX3 8tl3L589Qcf3nx7f//H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/ feYHQvlMzXn+xeNfnz5+/uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb 6UjiFOtZPPo7KnbQNyeYYQ+uRVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5 KjT3x+nIP7kYV3F7GB/45m7j1IlvZ5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4N BZd8qNBdilqYeinp04GTTVOhbZpAXCY+AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY4 8ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05EpPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCc V5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9DHHA6dxw36HECffp3eA2HTkmTRNEvxkL TyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFVPv/qkcfuN7VlbwIJvprZPtGo5+FO tuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkXhgatt0x2o2223cncXfeQMtZT E0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJejDPYtNcDrWQkc9UjiTIu 4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSCs062dDlXCr69zmR1 bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzbGBVhMVH4e0KU e20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YTS6u1xVJ0 2AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZkGoL y9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE 9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST 0gbzVDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ9 0zsgW+B6Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshk VMVcmVmzB+SAsL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxO ndhL6Pwt+C9NLFf36epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgH UZz1GAbL/UwGV0BI/wPrHxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlV ltp856NZKxbrC96olvOeIFtbdpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDm K1f1QxQf3INAb8GV/5jZT1MygydTB9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQt Ift5pNgiG7QW04lWCi75Dg2uYI7Xona1LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6 rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td +BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVtZS90aGVtZS9fcmVs cy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQrdQDhOQ1DTY/ JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCCjm837RVn kUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvVABmW UJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAI AAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s UEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRoZW1l L3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN 0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1h bmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA --B_3409069035_636238-- From denis.pinkas@bull.net Wed Jan 11 00:46:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84E721F879B for ; Wed, 11 Jan 2012 00:46:18 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+2UFchHDgs7 for ; Wed, 11 Jan 2012 00:46:18 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id ED3DC21F8753 for ; Wed, 11 Jan 2012 00:46:17 -0800 (PST) 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 D90301804F; Wed, 11 Jan 2012 09:46:16 +0100 (CET) In-Reply-To: <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> To: Russ Housley MIME-Version: 1.0 X-KeepSent: 67600FBB:5D09813A-C1257982:002F998C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 11 Jan 2012 09:46:16 +0100 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 11/01/2012 09:46:16, Serialize complete at 11/01/2012 09:46:16 Content-Type: multipart/alternative; boundary="=_alternative 002FFFE1C1257982_=" Cc: IETF PKIX Subject: Re: [pkix] I-D Action: draft-ietf-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: Wed, 11 Jan 2012 08:46:19 -0000 Message en plusieurs parties au format MIME --=_alternative 002FFFE1C1257982_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 UnVzcywNCg0KVGhlIGNvc3Qgb2YgUE9QIGhhcyB0byBiZSBiYWxhbmNlZCB3aXRoIHRoZSB2ZXJ5 IGxpdHRsZSBhZHZhbnRhZ2UgeW91IA0KbWVudGlvbi4NCg0KUE9QIGlzIGNvc3RseSBhbmQgY2Fu bm90IGJlIGVhc2lseSBkb25lIHdpdGggYW55IGFsZ29yaXRobS4gRm9yIHRoZSBzYWtlIA0Kb2Yg c2ltcGxpZmljYXRpb24sDQoobGVzcyBvcHRpb25zIG1lYW5zIGdyZWF0ZXIgaW50ZXJvcGVyYWJp bGl0eSksIFBPUCBzaG91bGQgYmUgc3VwcHJlc3NlZCwgDQpldmVuIGFzIGFuIG9wdGlvbi4NCg0K RGVuaXMNCg0KDQoNCg0KRGUgOiAgICBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMuY29t Pg0KQSA6ICAgICBkZW5pcy5waW5rYXNAYnVsbC5uZXQNCkNjIDogICAgSUVURiBQS0lYIDxwa2l4 QGlldGYub3JnPg0KRGF0ZSA6ICAxMC8wMS8yMDEyIDE4OjE5DQpPYmpldCA6IFJlOiBbcGtpeF0g SS1EIEFjdGlvbjogDQpkcmFmdC1pZXRmLXBraXgtY21jLXNlcnZlcmtleWdlbmVyYXRpb24tMDAu dHh0DQoNCg0KDQpEZW5pczoNCg0KMykgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rp b24gc3RhdGVzOiDigJxQT1AgaXMgZXh0cmVtZWx5IA0KaW1wb3J0YW504oCdLiANCiAgSG93ZXZl ciwgdGhlIHRleHQgcGxhY2VkIGFmdGVyIGRvZXMgbm90IHByb3ZpZGUgYSByYXRpb25hbDogDQoN CiAgIOKAnEhvd2V2ZXIsIFBPUCBoZXJlIGlzIGRpZmZlcmVudCB0aGFuIGluIA0KICAgY2xpZW50 LWdlbmVyYXRlZCBrZXkgY2VydGlmaWNhdGlvbiByZXF1ZXN0cyBpbiB0aGF0IHRoZSBQT1AgaXMg DQogICBuZWNlc3NhcnkgdG8gcHJvdmUgdG8gdGhlIHNlcnZlciB0aGF0IHRoZSBjbGllbnQgaGFz IHBvc3Nlc3Npb24gb2YgDQogICB0aGUgcHJpdmF0ZSBrZXkgbmVjZXNzYXJ5IHRvIGRlY3J5cHQg dGhlIHNlcnZlci1nZW5lcmF0ZWQgcHJpdmF0ZSBrZXkgDQogICByYXRoZXIgdGhhbiBwb3NzZXNz IHRoZSBwcml2YXRlIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIHB1YmxpYyBrZXkgaW4gDQogICB0 aGUgcmVxdWVzdC4gDQoNCklmIHRoZSBjbGllbnQgZG9lcyBub3QgcG9zc2VzcyB0aGUgcHJpdmF0 ZSBrZXksIGhlIHdpbGwgbm90IGJlIGFibGUgdG8gDQpkZWNyeXB0IHRoZSBwcml2YXRlIGtleSAN CmFuZCB0aHVzIHRoZXJlIGlzIG5vIGhhcm0uIElNTywgUE9QIGlzIHVubmVjZXNzYXJ5LiBUaGlz IHdpbGwgbGVhZCB0byBtYW55IA0Kc2ltcGxpZmljYXRpb25zIG9uIHRoZSBkb2N1bWVudC4gDQoN CkkgZG8gYWdyZWUgdGhhdCB0aGVyZSBpcyBubyBleHBvc3VyZSBpZiB0aGUgcHJpdmF0ZSBrZXkg Y2Fubm90IGJlIA0KdW53cmFwcGVkIChhc3N1bWluZyB0aGUgdXNlIG9mIGdvb2QgYWxnb3JpdGht cyBhbmQgc3VjaCkuICBIb3dldmVyLCB0aGUgDQp3YXkgSSByZWFkIGl0LCB0aGUgYXV0aG9ycyB3 YW50IHByb29mIHRoYXQgdGhlIHByaXZhdGUga2V5IGNvdWxkIGJlIA0KdW53cmFwcGVkIGFuZCB1 c2VkLiAgVGhpcyBzZWVtcyBsaWtlIGEgZ29vZCBmZWF0dXJlLg0KDQpSdXNzDQoNCg0K --=_alternative 002FFFE1C1257982_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJ1c3MsPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgY29zdCBvZiBQT1AgaGFzIHRvIGJlIGJh bGFuY2VkIHdpdGgNCnRoZSB2ZXJ5IGxpdHRsZSBhZHZhbnRhZ2UgeW91IG1lbnRpb24uPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5QT1AgaXMgY29zdGx5 IGFuZCBjYW5ub3QgYmUgZWFzaWx5IGRvbmUNCndpdGggYW55IGFsZ29yaXRobS4gRm9yIHRoZSBz YWtlIG9mIHNpbXBsaWZpY2F0aW9uLDxicj4NCihsZXNzIG9wdGlvbnMgbWVhbnMgZ3JlYXRlciBp bnRlcm9wZXJhYmlsaXR5KSwgUE9QIHNob3VsZCBiZSBzdXBwcmVzc2VkLA0KZXZlbiBhcyBhbiBv cHRpb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5E ZW5pczwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29s b3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5EZSA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJ1c3MgSG91c2xleSAm bHQ7aG91c2xleUB2aWdpbHNlYy5jb20mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xv cj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkEgOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5kZW5pcy5waW5rYXNAYnVs bC5uZXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1z ZXJpZiI+Q2MmbmJzcDs6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPklFVEYgUEtJWCAmbHQ7cGtpeEBpZXRmLm9yZyZndDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+ RGF0ZSA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjEwLzAxLzIwMTIgMTg6MTk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0x IGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+T2JqZXQgOiAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW3Br aXhdIEktRA0KQWN0aW9uOiBkcmFmdC1pZXRmLXBraXgtY21jLXNlcnZlcmtleWdlbmVyYXRpb24t MDAudHh0PC9mb250Pg0KPGJyPg0KPGhyIG5vc2hhZGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0zPkRlbmlzOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjMpIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uDQpzdGF0ZXM6IOKA nFBPUCBpcyBleHRyZW1lbHkgaW1wb3J0YW504oCdLiA8YnI+DQogJm5ic3A7SG93ZXZlciwgdGhl IHRleHQgcGxhY2VkIGFmdGVyIGRvZXMgbm90IHByb3ZpZGUgYSByYXRpb25hbDogPC9mb250Pjxm b250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 YnI+DQogJm5ic3A7IOKAnEhvd2V2ZXIsIFBPUCBoZXJlIGlzIGRpZmZlcmVudCB0aGFuIGluPC9m b250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ PGJyPg0KICZuYnNwOyBjbGllbnQtZ2VuZXJhdGVkIGtleSBjZXJ0aWZpY2F0aW9uIHJlcXVlc3Rz IGluIHRoYXQgdGhlIFBPUCBpczwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogJm5ic3A7IG5lY2Vzc2FyeSB0byBwcm92ZSB0 byB0aGUgc2VydmVyIHRoYXQgdGhlIGNsaWVudCBoYXMgcG9zc2Vzc2lvbg0Kb2Y8L2ZvbnQ+PGZv bnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQog Jm5ic3A7IHRoZSBwcml2YXRlIGtleSBuZWNlc3NhcnkgdG8gZGVjcnlwdCB0aGUgc2VydmVyLWdl bmVyYXRlZCBwcml2YXRlDQprZXk8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogJm5ic3A7IHJhdGhlciB0aGFuIHBvc3Nlc3Mg dGhlIHByaXZhdGUga2V5IGFzc29jaWF0ZWQgd2l0aCB0aGUgcHVibGljDQprZXkgaW48L2ZvbnQ+ PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+ DQogJm5ic3A7IHRoZSByZXF1ZXN0LjwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCklmIHRoZSBjbGllbnQgZG9lcyBu b3QgcG9zc2VzcyB0aGUgcHJpdmF0ZSBrZXksIGhlIHdpbGwgbm90IGJlIGFibGUgdG8NCmRlY3J5 cHQgdGhlIHByaXZhdGUga2V5IDxicj4NCmFuZCB0aHVzIHRoZXJlIGlzIG5vIGhhcm0uIElNTywg UE9QIGlzIHVubmVjZXNzYXJ5LiBUaGlzIHdpbGwgbGVhZCB0byBtYW55DQpzaW1wbGlmaWNhdGlv bnMgb24gdGhlIGRvY3VtZW50LjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTM+SSBkbyBhZ3JlZSB0aGF0IHRoZXJlIGlzIG5vIGV4cG9zdXJlIGlmIHRo ZSBwcml2YXRlIGtleQ0KY2Fubm90IGJlIHVud3JhcHBlZCAoYXNzdW1pbmcgdGhlIHVzZSBvZiBn b29kIGFsZ29yaXRobXMgYW5kIHN1Y2gpLiAmbmJzcDtIb3dldmVyLA0KdGhlIHdheSBJIHJlYWQg aXQsIHRoZSBhdXRob3JzIHdhbnQgcHJvb2YgdGhhdCB0aGUgcHJpdmF0ZSBrZXkgY291bGQgYmUN CnVud3JhcHBlZCBhbmQgdXNlZC4gJm5ic3A7VGhpcyBzZWVtcyBsaWtlIGEgZ29vZCBmZWF0dXJl LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+UnVzczwvZm9udD4NCjxicj4NCjxicj4N Cg== --=_alternative 002FFFE1C1257982_=-- From pritikin@cisco.com Wed Jan 11 10:09:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF9821F86D6 for ; Wed, 11 Jan 2012 10:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0mkbYwhU4tJ for ; Wed, 11 Jan 2012 10:09:26 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D6F2F21F865D for ; Wed, 11 Jan 2012 10:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=2253; q=dns/txt; s=iport; t=1326305367; x=1327514967; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=JH+D5JW90r1Ew2Skv5eRpUn/0zWdZ81WG4XIS98r6ho=; b=SCxGVl5/rddypvIKcP7MckypgVXWDWkey3gMQhV58JwhnesiEWwBKmJC KEMwUAZbuJ+yMlFuF89FTbYrWgA4Cz/rh8fbeMURd300T1Cs9RVtdElWB DB9cI8WNS/u3TiV1eUgGnur06GPA3Ot2gE9F8Hhu9XioyOw8HEpWcLc8q o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANbPDU+rRDoJ/2dsb2JhbAA5Ca0EgQWBcgEBAQMBAQEBDwEnNAUWC0YnMAYTCRmHWAiZCwGeQYhhglljBIg6jFKSXA X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; d="scan'208";a="24877788" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 11 Jan 2012 18:09:26 +0000 Received: from sjc-vpn2-175.cisco.com (sjc-vpn2-175.cisco.com [10.21.112.175]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0BI9QLt023270 for ; Wed, 11 Jan 2012 18:09:26 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Max Pritikin In-Reply-To: <20120108150622.31042.3072.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2012 11:09:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com> To: "pkix@ietf.org PKIX" X-Mailer: Apple Mail (2.1251.1) Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:09:27 -0000 Folks, Many thanks to Peter Yee who is now a co-author! The -00 release of the WG version has various clarifications from = previously drafts but is substantially the same. For example we now = re-use existing mime types in all cases, etc. Interested folks might = want to examine the newly organized and clarified discussion concerning = 'proof-of-possession' and 'linking identity and POP information' = (sections 3.6 and 3.7). We have already received feedback on this version and are actively = responding and updating for the -01 release. Any additional questions or = comments are of course appreciated and would be timely. (And my sincere = apologies if we have yet to address an outstanding concern you have).=20 I look forward to seeing you all at the next meeting. Thanks, - max On Jan 8, 2012, at 8:06 AM, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Public-Key Infrastructure = (X.509) Working Group of the IETF. >=20 > Title : Enrollment over Secure Transport > Author(s) : Max Pritikin > Peter E. Yee > Filename : draft-ietf-pkix-est-00.txt > Pages : 25 > Date : 2012-01-06 >=20 > This document profiles certificate enrollment for clients using > Certificate Management over CMS (CMC) messages over a secure > transport. This profile, called Enrollment over Secure Transport > (EST), describes a simple yet functional certificate management > protocol targeting simple Public Key Infrastructure clients that = need > to acquire client certificate(s) and associated Certification > Authority (CA) certificate(s). >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-est-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-est-00.txt >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From stephen.farrell@cs.tcd.ie Fri Jan 13 10:26:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF87121F84E1; Fri, 13 Jan 2012 10:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hw88tmRiJ4y; Fri, 13 Jan 2012 10:26:34 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 48C5821F849D; Fri, 13 Jan 2012 10:26:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 66CB1171CC3; Fri, 13 Jan 2012 18:26:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1326479178; bh=3R2RTxtYEZE96C 1vaPyq8mMqTa5543cjo2S9hxXqPb8=; b=2iWKMAG/oVVEKOMcLDwf0qsQ59fyCo UnnPfLOn3Vc2D9jN0f8R60XiRTS0VgYS4fSp/mAoTW3pqiQhZP3f6qiB3vtJLlDO efY5gyGovQ10Py9L4DLbWyTCfpQmOr4f/7ik9V6ZYRwGg2UKqNm/FBjB+4t8SGwv BEaiAlERvAW/mvxP9MK3q0l6QUC6ZbySmcUBDW0qnQXul/NxnnnpYw8StIX985t1 2/8tmSu3tRPyBbwPpCxPokZ7MlhYhZJBsidBpigmyJXE8WB9DAMfKnFQevczDcny o3KFA2jvsl/E1f+7GMFGDj+6UkhgnNtkDOvw5fM9d7mzDjaem7wUzlEg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id vhvCUBUgTFFA; Fri, 13 Jan 2012 18:26:18 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D8F19171CC2; Fri, 13 Jan 2012 18:26:18 +0000 (GMT) Message-ID: <4F10774A.4030003@cs.tcd.ie> Date: Fri, 13 Jan 2012 18:26:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "saag@ietf.org" , pkix , "tls@ietf.org" , dane References: <20120113182358.143B621F8579@ietfa.amsl.com> In-Reply-To: <20120113182358.143B621F8579@ietfa.amsl.com> X-Forwarded-Message-Id: <20120113182358.143B621F8579@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pkix] Fwd: New Non-WG Mailing List: therightkey X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 13 Jan 2012 18:26:34 -0000 FYI please sign up if interested but wait a few days to give folks a chance to sign up before starting in on discussion. Stephen & Sean. -------- Original Message -------- Subject: New Non-WG Mailing List: therightkey Date: Fri, 13 Jan 2012 10:23:58 -0800 (PST) From: IETF Secretariat To: IETF Announcement list CC: therightkey@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie A new IETF non-working group email list has been created. List address: therightkey@ietf.org Archive: http://www.ietf.org/mail-archive/web/therightkey/ To subscribe: https://www.ietf.org/mailman/listinfo/therightkey Purpose: A number of people are interested in discussing proposals that have been developed in response to recent attacks on the Internet security infrastructure, in particular those that affected sites using TLS and other protocols relying on PKI. This list is intended for discussion of those proposals and how they might result in potential work items for the IETF. One short-term outcome may be the holding of a non-wg-forming BoF at IETF-83. For additional information, please contact the list administrators. From Jeff.Hodges@KingsMountain.com Fri Jan 13 14:10:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3DA21F85A5 for ; Fri, 13 Jan 2012 14:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.02 X-Spam-Level: X-Spam-Status: No, score=-100.02 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQkCYTPdAYca for ; Fri, 13 Jan 2012 14:10:51 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 2AF0121F8495 for ; Fri, 13 Jan 2012 14:10:51 -0800 (PST) Received: (qmail 16918 invoked by uid 0); 13 Jan 2012 22:04:11 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 13 Jan 2012 22:04:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=K5fLWk9NdcjZ1wMxoZ7a/vmj2xkxoDzn7PpB5ok02iA=; b=Mqm3PJic+5lIyaHAzT1cYeBbxaZcyMPGnFl7i59gmkvQ8FuL/Bx6eKiLG5iMYte7kl5i3+kkeL7M14pyQcH9sibLLKQBIOBFftjyEV8LUdDTQK1tR4Qw7peR0pX24FA3; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.162]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RlpEJ-00033q-32; Fri, 13 Jan 2012 15:04:11 -0700 Message-ID: <4F10AA5B.8050503@KingsMountain.com> Date: Fri, 13 Jan 2012 14:04:11 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: pkix , dane , "saag@ietf.org" , "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [pkix] Fwd: New Non-WG Mailing List: therightkey X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 13 Jan 2012 22:10:51 -0000 > On Fri, Jan 13, 2012 at 1:26 PM, Stephen Farrell > wrote: >> Archive: http://www.ietf.org/mail-archive/web/therightkey/ > > This link is dead. Typo, or not yet available? works for me! see also: https://www.ietf.org/mailman/listinfo/therightkey HtH, =JeffH From ynir@checkpoint.com Sat Jan 14 01:03:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A26121F85BB; Sat, 14 Jan 2012 01:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1689OwFduWb; Sat, 14 Jan 2012 01:03:53 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76221F85AF; Sat, 14 Jan 2012 01:03:52 -0800 (PST) X-CheckPoint: {4F11425B-0-1B221DC2-1FFFF} 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 q0E93o71011172; Sat, 14 Jan 2012 11:03:51 +0200 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.3.213.0; Sat, 14 Jan 2012 11:03:50 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 14 Jan 2012 11:03:49 +0200 From: Yoav Nir To: =JeffH Date: Sat, 14 Jan 2012 11:03:50 +0200 Thread-Topic: [dane] Fwd: New Non-WG Mailing List: therightkey Thread-Index: AczSm25ntan/4oQoRnu1dXwzszgw8A== Message-ID: <4218085B-5136-4ADF-AD00-50DB3C7EB72F@checkpoint.com> References: <4F10AA5B.8050503@KingsMountain.com> In-Reply-To: <4F10AA5B.8050503@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: pkix , "saag@ietf.org" , "tls@ietf.org" , dane Subject: Re: [pkix] [dane] Fwd: New Non-WG Mailing List: therightkey X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 14 Jan 2012 09:03:54 -0000 On Jan 14, 2012, at 12:04 AM, =3DJeffH wrote: >> On Fri, Jan 13, 2012 at 1:26 PM, Stephen Farrell >> wrote: >>> Archive: http://www.ietf.org/mail-archive/web/therightkey/ >>=20 >> This link is dead. Typo, or not yet available? >=20 > works for me! +1 From era@x500.eu Sat Jan 14 02:30:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5764621F854E for ; Sat, 14 Jan 2012 02:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.083 X-Spam-Level: X-Spam-Status: No, score=-0.083 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_40=-0.185, HELO_EQ_DK=1.009, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjpd8fSNHrNo for ; Sat, 14 Jan 2012 02:30:32 -0800 (PST) Received: from mail01.dandomain.dk (mail01.dandomain.dk [194.150.112.201]) by ietfa.amsl.com (Postfix) with ESMTP id 04BC621F8474 for ; Sat, 14 Jan 2012 02:30:31 -0800 (PST) Received: from Morten ([95.209.233.223]) by mail01.dandomain.dk (DanDomain Mailserver) with ASMTP id YLS28329; Sat, 14 Jan 2012 11:30:29 +0100 From: "Erik Andersen" To: "'Stefan Santesson'" , "'Tom Gindin'" References: <003c01cb9aae$5f233140$1d6993c0$@eu> In-Reply-To: Date: Sat, 14 Jan 2012 11:30:26 +0100 Message-ID: <002501ccd2a7$8aab1120$a0013360$@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: AczOkbpqRInbtT9ATsW4c/1HWomtFwEE5P1g Content-Language: da Cc: 'PKIX' , Directory list , 'Jean-Paul Lemaire' Subject: Re: [pkix] Unclear public-key certificate definition in X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 14 Jan 2012 10:30:33 -0000 Hi Stefan, As a Swede, you should know how to spell my name. Just think of Eriks Plan in Stockholm (people may not know, I have a plan) and your ancient kings named Erik. Personally, I have a problem with the notation technique in general. It is used in 7.2 you are referring to and in 18.2, which is a somewhat misplaced and confusing subclause. In 7.2 it says the same as the ASN.1 to follow, so there is an unnecessary duplication, where a reader needs to grasp two different notation techniques to get the same thing twice. My preference would be to delete table one, delete the first part of 7.2 and to rewrite some of the stuff in clause 18 and more it to a more logical place. Erik Andersen Andersen's L-Service 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: Stefan Santesson [mailto:stefan@aaa-sec.com] Sendt: 9. januar 2012 06:44 Til: Erik Andersen; 'Tom Gindin' Cc: 'PKIX'; 'Jean-Paul Lemaire' Emne: Re: [pkix] Unclear public-key certificate definition in X.509 Eric, I think you can solve the confusion with something more close to the original and stay compliant with table 1 by choosing the term "NCA" for the name of the CA. It would be more compatible to the chosen term "UCA" for the unique identifier of the CA. Using CA1 and CA(A) is just adding confusion and is not necessary to provide the point of the text. I would suggest: Original text: Specifically, the certificate of a user with distinguished name A and unique identifier UA, produced by the certification authority with name CA and unique identifier UCA, has the following form: CA<> = CA{V,SN,AI,CA,UCA,A,UA,Ap,TA} New text: Specifically, the public-key certificate of a user with distinguished name A and unique identifier UA, produced by the CA with name NCA and and unique identifier UCA, has the following form: CA<> = CA{V,SN,AI,NCA,A,Ap,UCA,UA,TA,Ex} /Stefan On 10-12-13 11:13 AM, "Erik Andersen" wrote: >Hi Tom, > >Any suggestion? If you have some ideas, how will affect Table 1 of X.509. >The term CA(X) was introduced already in the first edition (1988). It >is nothing of my doing. > >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: Tom Gindin [mailto:tgindin@us.ibm.com] >Sendt: 11. december 2010 00:16 >Til: Erik Andersen >Cc: Jean-Paul Lemaire; 'PKIX' >Emne: Re: SV: SV: [pkix] Unclear public-key certificate definition in >X.509 > > Please use a different parameter name than A here. The bracket >style is not the reason for the confusion. > > Tom Gindin > > > > > >From: >"Erik Andersen" >To: >Tom Gindin/Watson/IBM@IBMUS >Cc: >"'PKIX'" , "Jean-Paul Lemaire" > >Date: >12/08/2010 10:12 AM >Subject: >SV: SV: [pkix] Unclear public-key certificate definition in X.509 > > > >Hi Tom and others, > >I am finally back on this one. I agree with your last statement. What >do you think about writing CA[A] instead of CA(A)? > >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: Tom Gindin [mailto:tgindin@us.ibm.com] >Sendt: 13. november 2010 01:38 >Til: Erik Andersen >Cc: 'PKIX' >Emne: Re: SV: [pkix] Unclear public-key certificate definition in X.509 > > It no longer has the problem which it had before. Of course, >it's > >a little odd to describe a certificate as a function of specifically >the DN of the issuer, since the critical functional dependency is on the >issuer's key pair. My own wording would go: produced by a >certification > >authority with the distinguished name CA1, unique identifier UCA1, and >key > >pair KCA1, has the following form: Cert<> = KCA1 { your args }. >The CA(A) expression just confuses me, because it suggests that the CA >is a function of the subject name. > >Tom Gindin > > > > > >From: >"Erik Andersen" >To: >Tom Gindin/Watson/IBM@IBMUS >Cc: >"'PKIX'" >Date: >11/12/2010 03:58 AM >Subject: >SV: [pkix] Unclear public-key certificate definition in X.509 > > > >Hi Tom, > >Thanks for comments. I share your concern. I have updated the suggested >text. Please check. > >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: Tom Gindin [mailto:tgindin@us.ibm.com] >Sendt: 9. november 2010 14:25 >Til: Erik Andersen >Cc: PKIX >Emne: Re: [pkix] Unclear public-key certificate definition in X.509 > > Since A denotes the user's distinguished name, it confuses me >(and > > >probably others as well) to describe the CA as having name CA(A) and >UID UCA(A). Would this not be easier to understand if the CA had name >CA(B) and ID UCA(B), or if subscripts were used? After all, the CA is >a different entity than the user, and your expression has A being used >in both contexts. > >Tom Gindin > > > > > >From: >"Erik Andersen" >To: >"PKIX" >Date: >11/03/2010 12:28 PM >Subject: >[pkix] Unclear public-key certificate definition in X.509 Sent by: >pkix-bounces@ietf.org > > > >I have proposed some modification to a paragraph in X.509 as documented >by > > >the attached file. > >I wonder whether you PKIX guys have comments on this proposal. Any >comment > > >will be appreciated. > >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 > [attachment "DR-xx.pdf" deleted by Tom Gindin/Watson/IBM] >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix > > >[attachment "X509-pot-01.pdf" deleted by Tom Gindin/Watson/IBM] > > > > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Mon Jan 16 12:13:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C84F21F85AA for ; Mon, 16 Jan 2012 12:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPpF20pRDJac for ; Mon, 16 Jan 2012 12:13:45 -0800 (PST) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1F96821F859E for ; Mon, 16 Jan 2012 12:13:44 -0800 (PST) Received: from [192.168.0.203] (81.232.141.73) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4EC0B93A01751342 for pkix@ietf.org; Mon, 16 Jan 2012 21:13:42 +0100 Message-ID: <4F1484F4.6020202@telia.com> Date: Mon, 16 Jan 2012 21:13:40 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "pkix@ietf.org" References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-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: Mon, 16 Jan 2012 20:13:45 -0000 > targeting simple Public Key Infrastructure clients that need > to acquire client certificate(s) and associated Certification > Authority (CA) certificate(s) I just returned from a PKI install in a large bank where they (among many things), intend to issue certificates to Androids and iPhones using SCEP. When they told me that they required PIN-protected keys, I had to bring them the bad news that no existing or emerging PKIX enrollment protocol actually support two-factor authentication tokens. It takes shelving out tons of legacy junk to move things forward. This is particularly easy if you have no legacy :-) http://www.google.com/wallet The details are somewhat sketchy (big understatement), but off-list I have gotten the information that it is based on GlobalPlatform which can be fully configured using end-to-end-security protocol mechanisms. -- Anders From kent@bbn.com Tue Jan 17 12:42:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FA621F8735 for ; Tue, 17 Jan 2012 12:42:16 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCmxn20uaftj for ; Tue, 17 Jan 2012 12:42:15 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8719621F85C0 for ; Tue, 17 Jan 2012 12:42:15 -0800 (PST) Received: from dhcp89-089-066.bbn.com ([128.89.89.66]:49282) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RnFr7-000FA3-GX; Tue, 17 Jan 2012 15:42:09 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> Date: Tue, 17 Jan 2012 15:14:40 -0500 To: denis.pinkas@bull.net From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: IETF PKIX Subject: Re: [pkix] I-D Action: draft-ietf-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: Tue, 17 Jan 2012 20:42:16 -0000 At 9:46 AM +0100 1/11/12, denis.pinkas@bull.net wrote: >Russ, > >The cost of POP has to be balanced with the very little advantage you mention. > >POP is costly and cannot be easily done with any algorithm. For the >sake of simplification, >(less options means greater interoperability), POP should be >suppressed, even as an option. > >Denis > Denis, POP is easy for any alg that is capable of sigs. I would expect that most certs are issued for keys that can be used for sigs, not just for key agreement. In the cases where signature functionality is not intrinsic for the key being put in a cert, we have described (in prior docs) ways to deal with the problem. So, I don't think it is reasonable to say that POP is hard, in general, nor should we consider advocating against it. Steve From denis.pinkas@bull.net Wed Jan 18 00:22:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2F25E8004 for ; Wed, 18 Jan 2012 00:22:11 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScGQvUpRb74d for ; Wed, 18 Jan 2012 00:22:11 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id DB57C5E8005 for ; Wed, 18 Jan 2012 00:22:10 -0800 (PST) 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 C8B7818051; Wed, 18 Jan 2012 09:22:09 +0100 (CET) In-Reply-To: References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> To: Stephen Kent MIME-Version: 1.0 X-KeepSent: 8177D869:496B2187-C1257989:002D7271; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 18 Jan 2012 09:22:09 +0100 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 18/01/2012 09:22:09, Serialize complete at 18/01/2012 09:22:09 Content-Type: multipart/alternative; boundary="=_alternative 002DEBA7C1257989_=" Cc: IETF PKIX Subject: Re: [pkix] I-D Action: draft-ietf-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: Wed, 18 Jan 2012 08:22:11 -0000 Message en plusieurs parties au format MIME --=_alternative 002DEBA7C1257989_= Content-Type: text/plain; charset="US-ASCII" Steve, In this case, POP does not counter a threat. Saying in the security considerations section it is important and necessary does not make sense. It is certainly possible add controls which are not necessary. If you really want to maintain for whatever reason (already existing implementation ?), then it, it should clearly be an option that any compliant implementation is NOT mandated to implement. Denis De : Stephen Kent A : denis.pinkas@bull.net Cc : Russ Housley , IETF PKIX Date : 17/01/2012 22:20 Objet : Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt At 9:46 AM +0100 1/11/12, denis.pinkas@bull.net wrote: >Russ, > >The cost of POP has to be balanced with the very little advantage you mention. > >POP is costly and cannot be easily done with any algorithm. For the >sake of simplification, >(less options means greater interoperability), POP should be >suppressed, even as an option. > >Denis > Denis, POP is easy for any alg that is capable of sigs. I would expect that most certs are issued for keys that can be used for sigs, not just for key agreement. In the cases where signature functionality is not intrinsic for the key being put in a cert, we have described (in prior docs) ways to deal with the problem. So, I don't think it is reasonable to say that POP is hard, in general, nor should we consider advocating against it. Steve --=_alternative 002DEBA7C1257989_= Content-Type: text/html; charset="US-ASCII" Steve,

In this case, POP does not counter a threat. Saying in the security considerations section it is important and necessary
does not make sense. It is certainly possible add controls which are not necessary.

If you really want to maintain for whatever reason (already existing implementation ?), then it, it should clearly be an option
that any compliant implementation is NOT mandated to implement.

Denis  



De :        Stephen Kent <kent@bbn.com>
A :        denis.pinkas@bull.net
Cc :        Russ Housley <housley@vigilsec.com>, IETF PKIX <pkix@ietf.org>
Date :        17/01/2012 22:20
Objet :        Re: [pkix] I-D Action:  draft-ietf-pkix-cmc-serverkeygeneration-00.txt



At 9:46 AM +0100 1/11/12, denis.pinkas@bull.net wrote:
>Russ,
>
>The cost of POP has to be balanced with the very little advantage you mention.
>
>POP is costly and cannot be easily done with any algorithm. For the
>sake of simplification,
>(less options means greater interoperability), POP should be
>suppressed, even as an option.
>
>Denis
>

Denis,

POP is easy for any alg that is capable of sigs. I would expect that most
certs are issued for keys that can be used for sigs, not just for key
agreement. In the cases where signature functionality is not
intrinsic for the key
being put in a cert, we have described (in prior docs) ways to deal
with the problem. So, I don't think it is reasonable to say that POP
is hard, in general, nor
should we consider advocating against it.

Steve
--=_alternative 002DEBA7C1257989_=-- From housley@vigilsec.com Wed Jan 18 06:57:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517FC21F8642 for ; Wed, 18 Jan 2012 06:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch8iWFuBZr51 for ; Wed, 18 Jan 2012 06:57:42 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3E64421F863F for ; Wed, 18 Jan 2012 06:57:42 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id E4AEEF2406C; Wed, 18 Jan 2012 09:57:57 -0500 (EST) 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 ao0j1fVwem+b; Wed, 18 Jan 2012 09:57:20 -0500 (EST) Received: from [192.168.2.104] (pool-96-241-165-215.washdc.fios.verizon.net [96.241.165.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 63C79F2403D; Wed, 18 Jan 2012 09:57:57 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-12-699109652 From: Russ Housley In-Reply-To: Date: Wed, 18 Jan 2012 09:57:40 -0500 Message-Id: References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> To: Denis.Pinkas@bull.net X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] I-D Action: draft-ietf-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: Wed, 18 Jan 2012 14:57:43 -0000 --Apple-Mail-12-699109652 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Denis: > If you really want to maintain for whatever reason (already existing = implementation ?), then it, it should clearly be an option=20 > that any compliant implementation is NOT mandated to implement.=20 I can imagine environments where there are sufficient physical and = procedural controls that POP is not needed. However, from my = experience, these are not the norm. And, as Steve Kent has already = commented, POP processing is not hard. As I said before, positive = confirmation that the intended recipient was able to unwrap the private = key is very valuable. I do not understand the environment you describe where the CA does not = care whether the intended recipient is able to unwrap the private key. = You say that there is no harm if the key cannot be unwrapped by the = intended recipient. I disagree. The harm is that the CA thinks there = is an active subscriber when there is not. Russ= --Apple-Mail-12-699109652 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii If you really want to maintain for = whatever reason (already existing implementation ?), then it, it should = clearly be an option 
that any compliant = implementation is NOT mandated to implement. 
I can imagine environments where there are sufficient = physical and procedural controls that POP is not needed.  However, = from my experience, these are not the norm.  And, as Steve Kent has = already commented, POP processing is not hard.  As I said before, = positive confirmation that the intended recipient was able to unwrap the = private key is very valuable.

I do not = understand the environment you describe where the CA does not care = whether the intended recipient is able to unwrap the private key. =  You say that there is no harm if the key cannot be unwrapped by = the intended recipient.  I disagree.  The harm is that the CA = thinks there is an active subscriber when there is = not.

Russ
= --Apple-Mail-12-699109652-- From pritikin@cisco.com Thu Jan 19 09:24:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D3721F86B4 for ; Thu, 19 Jan 2012 09:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj3uHPxdJCF3 for ; Thu, 19 Jan 2012 09:24:51 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7759321F86A9 for ; Thu, 19 Jan 2012 09:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=3303; q=dns/txt; s=iport; t=1326993891; x=1328203491; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=COTH+XcOnirHzHJy9SPHicn0Mz8KzDhAenG3mHkvxAw=; b=jF3nU90a8lmprcFtxo79R+wPdfAqj2kPCAW6ayQ7UkH52qvOiR44gXQ2 8hBfjQPdqGUo6jhdDtb9Ih20A4yDrW6EpNqCLFxcbHzt59Qjmk5iX6w25 72N8QUxpSNhrApuhQskJM1IjkQem+ifJbJUM2Vzev8lhaBPXBjiWP9a74 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKJQGE+tJXG+/2dsb2JhbAAuFqxfgQCBBYFyAQEBAwEBAQEPASc0AQoQCysFFicwBhMaCIdaCJpFAZ5YiF5ZBwQJBQEFCQkCAgEBDQUEEQUBBgEBBgEFFAUHAQsBAgEBCAEBAQMHEAUOJgxEEAULgToBDAYBAQZhAg+CN2MEiDuMXIsDh2c X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="52422255" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 19 Jan 2012 17:24:51 +0000 Received: from rtp-vpn4-929.cisco.com (rtp-vpn4-929.cisco.com [10.82.211.161]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0JHOnSv003247; Thu, 19 Jan 2012 17:24:49 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: <4F1484F4.6020202@telia.com> Date: Thu, 19 Jan 2012 10:24:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com> <4F1484F4.6020202@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1251.1) Cc: "pkix@ietf.org" Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-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, 19 Jan 2012 17:24:52 -0000 Anders, I'd like to address your concerns but their exact nature is not clearly = represented in your note. Two-factor authentication using a password/PIN = along with a certificate (which may be stored in a token) is of course = supported to meet EST Section 2, Requirement A5.=20 I suspect you're concerned with how the server might determine that the = certificate is physically contained within a specific cryptographic = token. As we've discussed previously this is an important concept that = is available, today, only by tokens that enforce implementation of the = enrollment protocol internally. In a previous thread I suggested = possible future extensions to the CSR that might serve to assert this = status in a way that can be transported over the existing protocols -- = but that I thought that work should likely proceed in a distinct draft.=20= I see a couple of ways you can help to move your concern forward, 1. If you feel this is something we can address immediately then please = provide a concrete textual suggestion for the EST draft. Using normative = language please feel free to suggest a section, extension, message, = paragraph etc for inclusion into the EST document that would address = your concern. It is significantly easier to evaluate an idea when it has = been laid out clearly and concisely in such a fashion. 2. Another option is to provide a personal submission draft. Similar to = the above this provides a single document folks can read to help grok = your idea. This is similar to my suggestion of a distinct draft above = but since you'd be writing the first version you'd have editorial = control and could better ensure it meets your concerns. Although I appreciate the link to Goole wallet marketing videos, and the = insight that they are using GlobalPlatform, there is a significant = "impedance mismatch" between this high level "somewhat sketchy" = description of a problem and the type of detail oriented discussion = necessary for an RFC. I look forward to reading your suggested text as either feedback for EST = or a new document, - max On Jan 16, 2012, at 1:13 PM, Anders Rundgren wrote: >> targeting simple Public Key Infrastructure clients that need >> to acquire client certificate(s) and associated Certification >> Authority (CA) certificate(s) >=20 > I just returned from a PKI install in a large bank where they (among > many things), intend to issue certificates to Androids and iPhones > using SCEP. When they told me that they required PIN-protected keys, > I had to bring them the bad news that no existing or emerging PKIX > enrollment protocol actually support two-factor authentication tokens. >=20 > It takes shelving out tons of legacy junk to move things forward. > This is particularly easy if you have no legacy :-) >=20 > http://www.google.com/wallet >=20 > The details are somewhat sketchy (big understatement), but off-list I > have gotten the information that it is based on GlobalPlatform which > can be fully configured using end-to-end-security protocol mechanisms. >=20 > -- Anders >=20 >=20 >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Thu Jan 19 15:18:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7556B21F859F for ; Thu, 19 Jan 2012 15:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_ONLINE=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cganpF29xY+A for ; Thu, 19 Jan 2012 15:18:20 -0800 (PST) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 8E95921F851C for ; Thu, 19 Jan 2012 15:18:20 -0800 (PST) Received: from [192.168.0.203] (81.232.141.73) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4EFC380E00556437; Fri, 20 Jan 2012 00:18:16 +0100 Message-ID: <4F18A4B6.3060701@telia.com> Date: Fri, 20 Jan 2012 00:18:14 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Max Pritikin References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com> <4F1484F4.6020202@telia.com> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-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, 19 Jan 2012 23:18:21 -0000 On 2012-01-19 18:24, Max Pritikin wrote: > > Anders, > > I'd like to address your concerns but their exact nature is not > clearly represented in your note. Two-factor authentication using > a password/PIN along with a certificate (which may be stored in a > token) is of course supported to meet EST Section 2, Requirement A5. This section does not mention anything about the actual usage of enrolled certificates or maybe it is just a bit vague on this point? The bank I mentioned where thinking about how bank cards are used (at least outside of the USA...), i.e. with a PIN. They felt that on- line-enrolled credentials should follow this time-proven pattern as well. Anyway, deploying a PIN to a key is quite different from authenticating to a CA with PIN. I may be dumb but I don't see how PIN deployment could be squeezed into EST without more or less starting over from scratch. BTW, the GlobalPlatform specification is public. -- Anders > > I suspect you're concerned with how the server might determine that the certificate is physically contained within a specific cryptographic token. As we've discussed previously this is an important concept that is available, today, only by tokens that enforce implementation of the enrollment protocol internally. In a previous thread I suggested possible future extensions to the CSR that might serve to assert this status in a way that can be transported over the existing protocols -- but that I thought that work should likely proceed in a distinct draft. > > I see a couple of ways you can help to move your concern forward, > > 1. If you feel this is something we can address immediately then please provide a concrete textual suggestion for the EST draft. Using normative language please feel free to suggest a section, extension, message, paragraph etc for inclusion into the EST document that would address your concern. It is significantly easier to evaluate an idea when it has been laid out clearly and concisely in such a fashion. > > 2. Another option is to provide a personal submission draft. Similar to the above this provides a single document folks can read to help grok your idea. This is similar to my suggestion of a distinct draft above but since you'd be writing the first version you'd have editorial control and could better ensure it meets your concerns. > > Although I appreciate the link to Goole wallet marketing videos, and the insight that they are using GlobalPlatform, there is a significant "impedance mismatch" between this high level "somewhat sketchy" description of a problem and the type of detail oriented discussion necessary for an RFC. > > I look forward to reading your suggested text as either feedback for EST or a new document, > > - max > > On Jan 16, 2012, at 1:13 PM, Anders Rundgren wrote: > >>> targeting simple Public Key Infrastructure clients that need >>> to acquire client certificate(s) and associated Certification >>> Authority (CA) certificate(s) >> >> I just returned from a PKI install in a large bank where they (among >> many things), intend to issue certificates to Androids and iPhones >> using SCEP. When they told me that they required PIN-protected keys, >> I had to bring them the bad news that no existing or emerging PKIX >> enrollment protocol actually support two-factor authentication tokens. >> >> It takes shelving out tons of legacy junk to move things forward. >> This is particularly easy if you have no legacy :-) >> >> http://www.google.com/wallet >> >> The details are somewhat sketchy (big understatement), but off-list I >> have gotten the information that it is based on GlobalPlatform which >> can be fully configured using end-to-end-security protocol mechanisms. >> >> -- Anders >> >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > From mrex@sap.com Fri Jan 20 19:04:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AC021F85F7 for ; Fri, 20 Jan 2012 19:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.17 X-Spam-Level: X-Spam-Status: No, score=-9.17 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-svb6LQ3l3w for ; Fri, 20 Jan 2012 19:04:25 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C954521F85DD for ; Fri, 20 Jan 2012 19:04:22 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0L34LJi015902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 21 Jan 2012 04:04:21 +0100 (MET) From: Martin Rex Message-Id: <201201210304.q0L34LZn006672@fs4113.wdf.sap.corp> To: pkix@ietf.org Date: Sat, 21 Jan 2012 04:04:21 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Subject: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer 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, 21 Jan 2012 03:04:26 -0000 If a PKI CA wanted to re-use CA DNames when rolling CA keys, and in combination with indirect CRLs, how/where would the AuthorityKeyIdentifier for the CRLEntryExtension.CertificateIssuer be conveyed, that would be necessary to disambiguate between CA certs with different keys and exact same SubjectName? I seem to have difficulties locating an answer in ITU-T X.509 and rfc5280. -Martin From security.developer22@gmail.com Sat Jan 21 08:29:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA9E21F8508 for ; Sat, 21 Jan 2012 08:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-wUHF6wOAO1 for ; Sat, 21 Jan 2012 08:29:22 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF6E621F84FB for ; Sat, 21 Jan 2012 08:29:21 -0800 (PST) Received: by yhnn12 with SMTP id n12so782087yhn.31 for ; Sat, 21 Jan 2012 08:29:21 -0800 (PST) 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=hM4tzV9MFJEIVOgiO14A8amAteIrTDzH7UP8M4qg1TI=; b=XwJOZ1U0x/tWFGt3EFd1u6r5wqJvhXFCQKsJJcar/NTd4DcEuIEBzSVA6uEEsg8THY QlHkZufglaV7XtTUR5bvN5gNZPHJGtdmndShxJ9xEf0HnBpE+NCihndv6HkBU+zlGvw4 pIh+smjJSPgNKwMb9qyRiT2FfrBRJlDZJ0xOM= MIME-Version: 1.0 Received: by 10.236.190.137 with SMTP id e9mr3525621yhn.36.1327163361488; Sat, 21 Jan 2012 08:29:21 -0800 (PST) Received: by 10.147.82.4 with HTTP; Sat, 21 Jan 2012 08:29:21 -0800 (PST) Date: Sat, 21 Jan 2012 21:29:21 +0500 Message-ID: From: Security Developer To: pkix@ietf.org Content-Type: multipart/alternative; boundary=20cf303f6d7ab86fce04b70c4c57 Subject: [pkix] Question about RFC5280 certificate validation algorithm X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 21 Jan 2012 16:29:22 -0000 --20cf303f6d7ab86fce04b70c4c57 Content-Type: text/plain; charset=ISO-8859-1 Hi, Could anybody please explain PKIX policy node contents? The policy node contents include: - valid_policy - qualifier_set - expected_policy_set Also what value does expected_policy_set add in RFC5280 certificate validation. Thanks for your time. --20cf303f6d7ab86fce04b70c4c57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Could anybody please explain PKIX policy node contents?

= The policy node contents include:

- valid_policy
- qualifier_set<= br>- expected_policy_set

Also what value does expected_policy_set a= dd in RFC5280 certificate validation.

Thanks for your time.=A0
--20cf303f6d7ab86fce04b70c4c57-- From housley@vigilsec.com Sat Jan 21 12:43:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A583A21F84E2 for ; Sat, 21 Jan 2012 12:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZoNwFY7F-aL for ; Sat, 21 Jan 2012 12:43:31 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0011021F84E1 for ; Sat, 21 Jan 2012 12:43:30 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 336A49A477C; Sat, 21 Jan 2012 15:43:41 -0500 (EST) 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 Ayu5jE2PP8WP; Sat, 21 Jan 2012 15:43:27 -0500 (EST) Received: from [192.168.2.104] (pool-96-241-165-215.washdc.fios.verizon.net [96.241.165.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 9E5BF9A4772; Sat, 21 Jan 2012 15:43:40 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Sat, 21 Jan 2012 15:43:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4D5952BB-DD92-412F-AAC1-A07176D8FB38@vigilsec.com> References: To: Security Developer X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] Question about RFC5280 certificate validation algorithm X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 21 Jan 2012 20:43:31 -0000 > Could anybody please explain PKIX policy node contents? >=20 > The policy node contents include: >=20 > - valid_policy > - qualifier_set > - expected_policy_set=20 The initial value of the valid_policy_tree is a single node with: - valid_policy is set to anyPolicy; - qualifier_set is set to the empty set; and - expected_policy_set is set to anyPolicy. The algorithm in section 6 shows how the nodes in the valid_policy_tree = are built as each certificate in the path is processed. > Also what value does expected_policy_set add in RFC5280 certificate = validation. The expected_policy_set contains one or more policy OIDs that would = satisfy this policy in the certificate x+1. The certificate x+1 ought = to contain a policy from this set. Russ= From housley@vigilsec.com Sat Jan 21 13:50:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F0321F84A6 for ; Sat, 21 Jan 2012 13:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKInOoGMKYDO for ; Sat, 21 Jan 2012 13:50:36 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 893F921F84A3 for ; Sat, 21 Jan 2012 13:50:36 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id CDF20F240FB; Sat, 21 Jan 2012 16:50:48 -0500 (EST) 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 mXtwFmitnXoH; Sat, 21 Jan 2012 16:50:31 -0500 (EST) Received: from [192.168.2.104] (pool-96-241-165-215.washdc.fios.verizon.net [96.241.165.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 4D68BF2403B; Sat, 21 Jan 2012 16:50:48 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <201201210304.q0L34LZn006672@fs4113.wdf.sap.corp> Date: Sat, 21 Jan 2012 16:50:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4A7372DF-6E58-4F6E-9D7E-D00A8A287D21@vigilsec.com> References: <201201210304.q0L34LZn006672@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 21 Jan 2012 21:50:37 -0000 Martin: > If a PKI CA wanted to re-use CA DNames when rolling CA keys, and in > combination with indirect CRLs, how/where would the = AuthorityKeyIdentifier > for the CRLEntryExtension.CertificateIssuer be conveyed, that would > be necessary to disambiguate between CA certs with different keys and > exact same SubjectName? >=20 > I seem to have difficulties locating an answer in ITU-T X.509 and = rfc5280. Does Section 4.4 of RFC 4210 provide an answer? It has been a while = since I looked at it, but I seem to remember it being very complete. Russ From SChokhani@cygnacom.com Sun Jan 22 05:44:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F42121F84FF for ; Sun, 22 Jan 2012 05:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQpsmx2ezUih for ; Sun, 22 Jan 2012 05:44:21 -0800 (PST) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 82F9F21F84F9 for ; Sun, 22 Jan 2012 05:44:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,551,1320642000"; d="scan'208";a="3825152" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 22 Jan 2012 08:44:03 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sun, 22 Jan 2012 08:44:03 -0500 From: Santosh Chokhani To: Russ Housley , "mrex@sap.com" Date: Sun, 22 Jan 2012 08:41:59 -0500 Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: AczZC5zBjdldcBATSii6Cs21snAI3Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 22 Jan 2012 13:44:22 -0000 Per RFC 5280, Certificate Issuer for the CRL Entry Extension is a GeneralN= ames, so no AKID is involved. Both X,500 and RFC 5280 assume that the DN (name) and serial number uniquel= y identify the certificate based on the assumption that the names are uniqu= e. It is not clear why you would need to access CA certificate via reference t= o CRL entry extension and thus I do not understand what you are trying to a= chieve -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rus= s Housley Sent: Saturday, January 21, 2012 4:51 PM To: mrex@sap.com Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Martin: > If a PKI CA wanted to re-use CA DNames when rolling CA keys, and in=20 > combination with indirect CRLs, how/where would the=20 > AuthorityKeyIdentifier for the CRLEntryExtension.CertificateIssuer be=20 > conveyed, that would be necessary to disambiguate between CA certs=20 > with different keys and exact same SubjectName? >=20 > I seem to have difficulties locating an answer in ITU-T X.509 and rfc5280= . Does Section 4.4 of RFC 4210 provide an answer? It has been a while since = I looked at it, but I seem to remember it being very complete. Russ _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Mon Jan 23 06:21:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA17721F8715 for ; Mon, 23 Jan 2012 06:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnL+foY3piBu for ; Mon, 23 Jan 2012 06:21:13 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D623821F86F1 for ; Mon, 23 Jan 2012 06:21:07 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 46E1821B138A; Mon, 23 Jan 2012 09:21:07 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 31D0321B1384; Mon, 23 Jan 2012 09:21:07 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.158]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Mon, 23 Jan 2012 09:21:07 -0500 From: "Miller, Timothy J." To: Santosh Chokhani , Russ Housley , "mrex@sap.com" Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: AczZC5zBkYunh8ou0k2O3ixXfjBtFgAxkqcA Date: Mon, 23 Jan 2012 14:21:06 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.19.94] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Jan 2012 14:21:15 -0000 On 1/22/12 7:41 AM, "Santosh Chokhani" wrote: >Per RFC 5280, Certificate Issuer for the CRL Entry Extension is a >GeneralNames, so no AKID is involved. > >Both X,500 and RFC 5280 assume that the DN (name) and serial number >uniquely identify the certificate based on the assumption that the names >are unique. This is probably something that needs to be written out of the RFC. -- T From SChokhani@cygnacom.com Mon Jan 23 06:29:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A380521F86CF for ; Mon, 23 Jan 2012 06:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olVg8bGVJxfw for ; Mon, 23 Jan 2012 06:29:55 -0800 (PST) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1669D21F86D3 for ; Mon, 23 Jan 2012 06:29:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="3832845" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 23 Jan 2012 09:29:54 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 23 Jan 2012 09:29:54 -0500 From: Santosh Chokhani To: "Miller, Timothy J." , Russ Housley , "mrex@sap.com" Date: Mon, 23 Jan 2012 09:29:53 -0500 Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: AczZC5zBkYunh8ou0k2O3ixXfjBtFgAxkqcAAAJcydA= 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Jan 2012 14:29:55 -0000 Are you saying that X.509 and RFC 5280 should NOT assume that the DN is uni= que? -----Original Message----- From: Miller, Timothy J. [mailto:tmiller@mitre.org]=20 Sent: Monday, January 23, 2012 9:21 AM To: Santosh Chokhani; Russ Housley; mrex@sap.com Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer On 1/22/12 7:41 AM, "Santosh Chokhani" wrote: >Per RFC 5280, Certificate Issuer for the CRL Entry Extension is a=20 >GeneralNames, so no AKID is involved. > >Both X,500 and RFC 5280 assume that the DN (name) and serial number=20 >uniquely identify the certificate based on the assumption that the=20 >names are unique. This is probably something that needs to be written out of the RFC. -- T From tmiller@mitre.org Mon Jan 23 07:00:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A775D21F871C for ; Mon, 23 Jan 2012 07:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DqLBjQAArpo for ; Mon, 23 Jan 2012 07:00:41 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5A621F8674 for ; Mon, 23 Jan 2012 07:00:41 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 39C7F21B17C3; Mon, 23 Jan 2012 10:00:34 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 125EF21B13A9; Mon, 23 Jan 2012 10:00:34 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.158]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Mon, 23 Jan 2012 10:00:33 -0500 From: "Miller, Timothy J." To: Santosh Chokhani , Russ Housley , "mrex@sap.com" Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: AczZC5zBkYunh8ou0k2O3ixXfjBtFgAxkqcAAAJcydD///f6AA== Date: Mon, 23 Jan 2012 15:00:33 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.0.16] Content-Type: text/plain; charset="us-ascii" Content-ID: <5302C84D27383B4DA910E0FB531190B0@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Jan 2012 15:00:45 -0000 Not across different PKIs, no. Current software treats Issuer+Serial as a unique identifier; this is a security risk. I can (and have, in the lab, for compatibility testing purposes, honest!) created my own CAs that collide names. Both X.509 and RFC 5280 are not clear on this point. They were written with the understanding that the trust anchor needs to be included when considering a DN, but this is a point that's lost on lots of implementations. For example of this error, see Figure 21 in "Windows Vista Smart Card Infrastructure" at: http://msdn.microsoft.com/en-us/library/bb905527.aspx Specifically, trace the thread for logon using the Subject+Issuer alternative mapping. -- T On 1/23/12 8:29 AM, "Santosh Chokhani" wrote: >Are you saying that X.509 and RFC 5280 should NOT assume that the DN is >unique? > >-----Original Message----- >From: Miller, Timothy J. [mailto:tmiller@mitre.org] >Sent: Monday, January 23, 2012 9:21 AM >To: Santosh Chokhani; Russ Housley; mrex@sap.com >Cc: pkix@ietf.org >Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer > >On 1/22/12 7:41 AM, "Santosh Chokhani" wrote: > >>Per RFC 5280, Certificate Issuer for the CRL Entry Extension is a >>GeneralNames, so no AKID is involved. >> >>Both X,500 and RFC 5280 assume that the DN (name) and serial number >>uniquely identify the certificate based on the assumption that the >>names are unique. > >This is probably something that needs to be written out of the RFC. > >-- T > From mrex@sap.com Mon Jan 23 07:19:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CBA21F8729 for ; Mon, 23 Jan 2012 07:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.069 X-Spam-Level: X-Spam-Status: No, score=-10.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XA83xu9-Imr8 for ; Mon, 23 Jan 2012 07:19:15 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBC721F871E for ; Mon, 23 Jan 2012 07:19:15 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0NFJBiN006877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jan 2012 16:19:11 +0100 (MET) From: Martin Rex Message-Id: <201201231519.q0NFJAAe007895@fs4113.wdf.sap.corp> To: SChokhani@cygnacom.com (Santosh Chokhani) Date: Mon, 23 Jan 2012 16:19:10 +0100 (MET) In-Reply-To: from "Santosh Chokhani" at Jan 22, 12 08:41: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] AuthKeyId and CrlEntryExtension.CertificateIssuer 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, 23 Jan 2012 15:19:16 -0000 Santosh Chokhani wrote: > > Per RFC 5280, Certificate Issuer for the CRL Entry Extension is a > GeneralNames, so no AKID is involved. Correct, the AKID is missing there, and it is also missing in the CRL Distribution point extension, both of which appear to be a defect in the specs. > > Both X,500 and RFC 5280 assume that the DN (name) and serial number > uniquely identify the certificate based on the assumption that the > names are unique. Yes, it looks like this was the original design, there was an assumption/requirement that issuer names (i.e. Subject names of CA certificates) would be unique. > > It is not clear why you would need to access CA certificate via > reference to CRL entry extension and thus I do not understand what > you are trying to achieve It appears that there was an exemption retrofitted into X.509/rfc5280 to allow two (or more) CA certificates with different public keys to bear the exact same Subject DName, and in order to disabiguate between those CA certificates, the AKID extension is required in all places where the CA certificate is referenced by IssuerName alone. AKID was added as an X.509v3 certificate extension and as a CRL extension, but it seesm to be missing in CRLEntryExtension and the CRLDistributionPoint extension. For simple (=direct) CRLs, the Cert IssuerName + Cert AKID match the CRLSigner + CRLExtension.AKID and disambiguates for which CA (cert) the CRL is authoritative. For indirect CRLs, the CRLSigner + CRLExtension.AKID refer to the indirect signer, and the Link between the Cert and the CRLEntryExtension.CertificateIssuer is dangling, because it lacks an AKID that refers back to the Cert's AKID. And the CrlDistributionPoint extension seems to lack a seperate AKID to uniquely identify an indirect CrlSigner matching the AKID on the indirect CRL.CRLExtensions. Russ Housley wrote: > > Martin Rex wrote: > > > > If a PKI CA wanted to re-use CA DNames when rolling CA keys, and in > > combination with indirect CRLs, how/where would the > > AuthorityKeyIdentifier for the CRLEntryExtension.CertificateIssuer be > > conveyed, that would be necessary to disambiguate between CA certs > > with different keys and exact same SubjectName? > > > > I seem to have difficulties locating an answer in ITU-T X.509 and rfc5280. > > Does Section 4.4 of RFC 4210 provide an answer? It has been a while > since I looked at it, but I seem to remember it being very complete. Section 4.4 is about rolling of RootCAs keys. While my question was in independent from the role of the CA, I was thinking of intermediate CAs. Usually, the CA key rollover is more of an issuer for intermediate CA than rootCA certs, where the lifetime is usually 5-10 years and you might worry about CRL size and appreciate a start-over by rolling your intermediate CA cert. When rolling your intermediate CA cert sensibly, you would at least add a SerialNumber RDName to your intermediate CAs DName that will preclude all ambiguities, but there seems to be software that not prefers to reuse the DName and distinguish only by AKID. But to me it looks like interect CRLs can not be made to work reliably/safely with CAs that re-use DNames and require AKID presence in order to distinguish CertificateIssuers. -Martin From mrex@sap.com Mon Jan 23 07:22:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0752521F86A3 for ; Mon, 23 Jan 2012 07:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.076 X-Spam-Level: X-Spam-Status: No, score=-10.076 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWIkk2j5NuIg for ; Mon, 23 Jan 2012 07:22:48 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2993821F8642 for ; Mon, 23 Jan 2012 07:22:48 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0NFMil0006993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jan 2012 16:22:44 +0100 (MET) From: Martin Rex Message-Id: <201201231522.q0NFMhU1008054@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Mon, 23 Jan 2012 16:22:43 +0100 (MET) In-Reply-To: <201201231519.q0NFJAAe007895@fs4113.wdf.sap.corp> from "Martin Rex" at Jan 23, 12 04:19:10 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] AuthKeyId and CrlEntryExtension.CertificateIssuer 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, 23 Jan 2012 15:22:49 -0000 (resend, with typos fixed below) Martin Rex wrote: > > Santosh Chokhani wrote: > > > > Per RFC 5280, Certificate Issuer for the CRL Entry Extension is a > > GeneralNames, so no AKID is involved. > > Correct, the AKID is missing there, and it is also missing in > the CRL Distribution point extension, both of which appear to > be a defect in the specs. > > > > > > Both X,500 and RFC 5280 assume that the DN (name) and serial number > > uniquely identify the certificate based on the assumption that the > > names are unique. > > Yes, it looks like this was the original design, there was an > assumption/requirement that issuer names (i.e. Subject names of > CA certificates) would be unique. > > > > > > It is not clear why you would need to access CA certificate via > > reference to CRL entry extension and thus I do not understand what > > you are trying to achieve > > > It appears that there was an exemption retrofitted into X.509/rfc5280 > to allow two (or more) CA certificates with different public keys > to bear the exact same Subject DName, and in order to disabiguate > between those CA certificates, the AKID extension is required in > all places where the CA certificate is referenced by IssuerName > alone. AKID was added as an X.509v3 certificate extension and > as a CRL extension, but it seesm to be missing in CRLEntryExtension > and the CRLDistributionPoint extension. > > > For simple (=direct) CRLs, the Cert IssuerName + Cert AKID match > the CRLSigner + CRLExtension.AKID and disambiguates for which CA (cert) > the CRL is authoritative. > > For indirect CRLs, the CRLSigner + CRLExtension.AKID refer to the > indirect signer, and the Link between the Cert and the > CRLEntryExtension.CertificateIssuer is dangling, because it > lacks an AKID that refers back to the Cert's AKID. > > And the CrlDistributionPoint extension seems to lack a seperate AKID > to uniquely identify an indirect CrlSigner matching the AKID on > the indirect CRL.CRLExtensions. > > > Russ Housley wrote: > > > > Martin Rex wrote: > > > > > > If a PKI CA wanted to re-use CA DNames when rolling CA keys, and in > > > combination with indirect CRLs, how/where would the > > > AuthorityKeyIdentifier for the CRLEntryExtension.CertificateIssuer be > > > conveyed, that would be necessary to disambiguate between CA certs > > > with different keys and exact same SubjectName? > > > > > > I seem to have difficulties locating an answer in ITU-T X.509 and rfc5280. > > > > Does Section 4.4 of RFC 4210 provide an answer? It has been a while > > since I looked at it, but I seem to remember it being very complete. > > Section 4.4 is about rolling of RootCAs keys. While my question > was in independent from the role of the CA, I was thinking of > intermediate CAs. > > > Usually, the CA key rollover is more of an issuer for intermediate CA > than rootCA certs, where the lifetime is usually 5-10 years and you > might worry about CRL size and appreciate a start-over by rolling > your intermediate CA cert. > > > When rolling your intermediate CA cert sensibly, you would at least > add a SerialNumber RDName to your intermediate CAs DName that will > preclude all ambiguities, but there seems to be software that > prefers to reuse the DName and distinguish only by AKID. > > But to me it looks like indirect CRLs can not be made to work > reliably/safely with CAs that re-use DNames and require AKID > presence in order to distinguish CertificateIssuers. > > > -Martin From SChokhani@cygnacom.com Mon Jan 23 07:51:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157DD21F87A1 for ; Mon, 23 Jan 2012 07:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkmqKYaKTAru for ; Mon, 23 Jan 2012 07:51:45 -0800 (PST) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id EAD0F21F87A0 for ; Mon, 23 Jan 2012 07:51:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="3834525" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 23 Jan 2012 10:51:40 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 23 Jan 2012 10:51:39 -0500 From: Santosh Chokhani To: "mrex@sap.com" Date: Mon, 23 Jan 2012 10:51:38 -0500 Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: AczZ4u5267FXE4e/Tgma8qUsZ7YkmgAAjnFg Message-ID: References: <201201231519.q0NFJAAe007895@fs4113.wdf.sap.corp> from "Martin Rex" at Jan 23, 12 04:19:10 pm <201201231522.q0NFMhU1008054@fs4113.wdf.sap.corp> In-Reply-To: <201201231522.q0NFMhU1008054@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: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Jan 2012 15:51:46 -0000 Martin, The historical understanding on your part is not accurate. The items you are identifying may protect against unintended name collision= s, but would not protect against intentional attacker. To see the general issue in this area, I encourage you to see my briefings = to the IETF Meeting held in DC area circa Nov. 2004, if I recall correctly.= Also, see related briefing and paper in NIST PKI Research Symposium circa= 2005 and 2006. The items you identify are changes to the standard. It may be possible to = assure backward compatibility using optional fields, but I have not worked = that out. For specific comments, see comments in-line. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Monday, January 23, 2012 10:23 AM To: mrex@sap.com Cc: Santosh Chokhani; housley@vigilsec.com; pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer (resend, with typos fixed below) Martin Rex wrote: >=20 > Santosh Chokhani wrote: > >=20 > > Per RFC 5280, Certificate Issuer for the CRL Entry Extension is a=20 > > GeneralNames, so no AKID is involved. >=20 > Correct, the AKID is missing there, and it is also missing in the CRL=20 > Distribution point extension, both of which appear to be a defect in=20 > the specs. >=20 >=20 > >=20 > > Both X,500 and RFC 5280 assume that the DN (name) and serial number=20 > > uniquely identify the certificate based on the assumption that the=20 > > names are unique. >=20 > Yes, it looks like this was the original design, there was an=20 > assumption/requirement that issuer names (i.e. Subject names of CA=20 > certificates) would be unique. >=20 >=20 > >=20 > > It is not clear why you would need to access CA certificate via=20 > > reference to CRL entry extension and thus I do not understand what=20 > > you are trying to achieve >=20 >=20 > It appears that there was an exemption retrofitted into X.509/rfc5280=20 > to allow two (or more) CA certificates with different public keys to=20 > bear the exact same Subject DName, and in order to disabiguate between=20 > those CA certificates, the AKID extension is required in all places=20 > where the CA certificate is referenced by IssuerName alone. [Santosh] That was not the purpose of AKID. AKID was intended to efficient= ly disambiguate between multiple signing keys held by the same CA, e.g., fo= r due to key roll-over. AKID was=20 > added as an X.509v3 certificate extension and as a CRL extension, but=20 > it seesm to be missing in CRLEntryExtension and the=20 > CRLDistributionPoint extension. [Santosh] I do not see any value for it in CRL Entry extension since once t= he relying party trusts the CRL in question and assumes that the same autho= rity would not service with two different CAs with the same name, it become= s a non-issue. As to appearing in CRL DP, the CRL DP itself ensures that the correct indir= ect issuer is pointed to. If you are concerned about mischief, AKID would = not be the way to handle it since anyone can assert an AKID. You would nee= d to include the Indirect CRL Signer Public Key or Secure Hash thereof. No= te that this would be a change to the standard as well as remove flexibilit= y from the indirect CRL issuer to rekey. >=20 >=20 > For simple (=3Ddirect) CRLs, the Cert IssuerName + Cert AKID match the=20 > CRLSigner + CRLExtension.AKID and disambiguates for which CA (cert)=20 > the CRL is authoritative. >=20 > For indirect CRLs, the CRLSigner + CRLExtension.AKID refer to the=20 > indirect signer, and the Link between the Cert and the=20 > CRLEntryExtension.CertificateIssuer is dangling, because it lacks an=20 > AKID that refers back to the Cert's AKID. [Santosh] As I said before, I do not think an Authority would service two d= ifferent CAs with the same name. >=20 > And the CrlDistributionPoint extension seems to lack a seperate AKID=20 > to uniquely identify an indirect CrlSigner matching the AKID on the=20 > indirect CRL.CRLExtensions. [Santosh] See response above. >=20 >=20 > Russ Housley wrote: > >=20 > > Martin Rex wrote: > > > > > > If a PKI CA wanted to re-use CA DNames when rolling CA keys, and=20 > > > in combination with indirect CRLs, how/where would the=20 > > > AuthorityKeyIdentifier for the CRLEntryExtension.CertificateIssuer=20 > > > be conveyed, that would be necessary to disambiguate between CA=20 > > > certs with different keys and exact same SubjectName? > > >=20 > > > I seem to have difficulties locating an answer in ITU-T X.509 and rfc= 5280. > >=20 > > Does Section 4.4 of RFC 4210 provide an answer? It has been a while=20 > > since I looked at it, but I seem to remember it being very complete. >=20 > Section 4.4 is about rolling of RootCAs keys. While my question was=20 > in independent from the role of the CA, I was thinking of intermediate=20 > CAs. >=20 >=20 > Usually, the CA key rollover is more of an issuer for intermediate CA=20 > than rootCA certs, where the lifetime is usually 5-10 years and you=20 > might worry about CRL size and appreciate a start-over by rolling your=20 > intermediate CA cert. >=20 >=20 > When rolling your intermediate CA cert sensibly, you would at least=20 > add a SerialNumber RDName to your intermediate CAs DName that will=20 > preclude all ambiguities, but there seems to be software that prefers=20 > to reuse the DName and distinguish only by AKID. >=20 > But to me it looks like indirect CRLs can not be made to work=20 > reliably/safely with CAs that re-use DNames and require AKID presence=20 > in order to distinguish CertificateIssuers. >=20 >=20 > -Martin From mrex@sap.com Mon Jan 23 08:50:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5B621F873A for ; Mon, 23 Jan 2012 08:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.782 X-Spam-Level: X-Spam-Status: No, score=-9.782 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M72UttqhNcTw for ; Mon, 23 Jan 2012 08:50:32 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 05B1721F8710 for ; Mon, 23 Jan 2012 08:50:31 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0NGoSKF025175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jan 2012 17:50:28 +0100 (MET) From: Martin Rex Message-Id: <201201231650.q0NGoRq3013042@fs4113.wdf.sap.corp> To: SChokhani@cygnacom.com (Santosh Chokhani) Date: Mon, 23 Jan 2012 17:50:27 +0100 (MET) In-Reply-To: from "Santosh Chokhani" at Jan 23, 12 10:51: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 Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer 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, 23 Jan 2012 16:50:33 -0000 Santosh Chokhani wrote: > > Martin Rex wrote: > > > > > > It is not clear why you would need to access CA certificate via > > > reference to CRL entry extension and thus I do not understand what > > > you are trying to achieve > > > > It appears that there was an exemption retrofitted into X.509/rfc5280 > > to allow two (or more) CA certificates with different public keys to > > bear the exact same Subject DName, and in order to disabiguate between > > those CA certificates, the AKID extension is required in all places > > where the CA certificate is referenced by IssuerName alone. > > [Santosh] That was not the purpose of AKID. AKID was intended to > efficiently disambiguate between multiple signing keys held by the > same CA, e.g., for due to key roll-over. I fail to see a different between what I wrote and what you wrote. > > > AKID was added as an X.509v3 certificate extension and as a > > CRL extension, but it seesm to be missing in CRLEntryExtension > > and the CRLDistributionPoint extension. > > [Santosh] I do not see any value for it in CRL Entry extension since > once the relying party trusts the CRL in question and assumes that > the same authority would not service with two different CAs with > the same name, it becomes a non-issue. This is about one single CA holding certs with the exact same DName and different keypairs. This may be for different algorithms in parallel (RSA and ECDSA), or same algorithm but different key&validity for key roll-over. If that single CA uses distinct CRLs for each of its CA certs, dinstinguishing them only by AKID, then indirect CRLs will no longer work, because it would become possible for an attacker to cheat RPs with CRLs that refer to the other CA cert than the one they wanted to check, and due to the lack of an AKID in the CRLEntryExtension, the RP will be unable to detect that it is being spoofed. > > As to appearing in CRL DP, the CRL DP itself ensures that the correct > indirect issuer is pointed to. When CAs reuse DNames for differen keypairs, that does not seem to work with indirect CRLs, because of the lack of an AKID in the CRL DP that could be matched to the AKID of indirect signer in the CRLExtension. > > If you are concerned about mischief, AKID would not be the way to handle > it since anyone can assert an AKID. You would need to include the > Indirect CRL Signer Public Key or Secure Hash thereof. Note that this > would be a change to the standard as well as remove flexibility from > the indirect CRL issuer to rekey. I'm concerned about what looks like an undefined/unspecified area ITU-T X.509 / rfc5280 when combining CA DName re-use with indirect CRLs. > > > > > For simple (=direct) CRLs, the Cert IssuerName + Cert AKID match the > > CRLSigner + CRLExtension.AKID and disambiguates for which CA (cert) > > the CRL is authoritative. > > > > For indirect CRLs, the CRLSigner + CRLExtension.AKID refer to the > > indirect signer, and the Link between the Cert and the > > CRLEntryExtension.CertificateIssuer is dangling, because it lacks an > > AKID that refers back to the Cert's AKID. > > [Santosh] As I said before, I do not think an Authority would service > two different CAs with the same name. The collision of CA Names from different PKIs or different sections of the same PKI is not what I'm currently worrying about. I'm talking about one single organization/administrative entity holding multiple CA certs with the same Subject DName but distinct public key pairs. Every "self-issued" CA certificate is a DName re-use. -Martin From SChokhani@cygnacom.com Mon Jan 23 09:07:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B6E21F84A0 for ; Mon, 23 Jan 2012 09:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rzUiXN8cguC for ; Mon, 23 Jan 2012 09:07:30 -0800 (PST) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id E9F3121F849C for ; Mon, 23 Jan 2012 09:07:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="319592" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 23 Jan 2012 12:07:27 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 23 Jan 2012 12:07:27 -0500 From: Santosh Chokhani To: "mrex@sap.com" Date: Mon, 23 Jan 2012 12:07:25 -0500 Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: AczZ7x3lEFDQD0AYThCiwxHUDDASEQAAJqzg Message-ID: References: from "Santosh Chokhani" at Jan 23, 12 10:51:38 am <201201231650.q0NGoRq3013042@fs4113.wdf.sap.corp> In-Reply-To: <201201231650.q0NGoRq3013042@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: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Jan 2012 17:07:30 -0000 Martin, See in-line with deletions.. > [Santosh] That was not the purpose of AKID. AKID was intended to=20 > efficiently disambiguate between multiple signing keys held by the=20 > same CA, e.g., for due to key roll-over. I fail to see a different between what I wrote and what you wrote. [Santosh] The difference is that we are not trying to ensure that two disti= nct CAs with the same name can be disambiguated, We are simply introducing= efficiency mechanism to select appropriate certificate for signature check= ing which can be computationally expensive. AKID is NOT a security mechani= sm. >=20 > > AKID was added as an X.509v3 certificate extension and as a CRL=20 > > extension, but it seesm to be missing in CRLEntryExtension and the=20 > > CRLDistributionPoint extension. >=20 > [Santosh] I do not see any value for it in CRL Entry extension since=20 > once the relying party trusts the CRL in question and assumes that the=20 > same authority would not service with two different CAs with the same=20 > name, it becomes a non-issue. This is about one single CA holding certs with the exact same DName and dif= ferent keypairs. This may be for different algorithms in parallel (RSA and= ECDSA), or same algorithm but different key&validity for key roll-over. [Santosh] Since that CA is not supposed to repeat serial numbers, DN and se= rial number tuple will unique identify a certificate for that CA. If that single CA uses distinct CRLs for each of its CA certs, dinstinguish= ing them only by AKID, then indirect CRLs will no longer work, because it w= ould become possible for an attacker to cheat RPs with CRLs that refer to t= he other CA cert than the one they wanted to check, and due to the lack of = an AKID in the CRLEntryExtension, the RP will be unable to detect that it i= s being spoofed. [Santosh] I assume in the first part you mean issue distinct CRL using diff= erent keys. The CA that signs partial CRLs, albeit using different keys is= supposed to issue partitioned CRL asserting IDP in CRL extension. The rel= ying parties are supposed to match DP in CRL DP and DP in IDP to counter th= e threat you mentioned. >=20 > As to appearing in CRL DP, the CRL DP itself ensures that the correct=20 > indirect issuer is pointed to. When CAs reuse DNames for differen keypairs, that does not seem to work wit= h indirect CRLs, because of the lack of an AKID in the CRL DP that could be= matched to the AKID of indirect signer in the CRLExtension. [Santosh] See a prior response. > > If you are concerned about mischief, AKID would not be the way to=20 > handle it since anyone can assert an AKID. You would need to include=20 > the Indirect CRL Signer Public Key or Secure Hash thereof. Note that=20 > this would be a change to the standard as well as remove flexibility=20 > from the indirect CRL issuer to rekey. I'm concerned about what looks like an undefined/unspecified area ITU-T X.5= 09 / rfc5280 when combining CA DName re-use with indirect CRLs. [Santosh] There is nothing undefined if you are thinking of the same CA DN = having multiple keys. The CRL needs to be partitioned or you can combine a= ll the revocation information and sign with each key. Thus, the list would= be the same and complete but some of the other information would be differ= ent. Also, based on the certificate entry, you can declare a different CRL= DP to ensure that the relying party gets the CRL signed with the same algo= rithm as the certificate. If you running the same CA, you also need to kee= p the serial number unique regardless of key. I would also suggest you using different DN for the CAs and running them as= separate CAs. But, that is an engg. and product limitation function. BTW, in none of your scenarios, would the CRL be called in indirect CRL. = When a CA rolls over its key, it does not issue indirect CRL from the X.509= and 5280 viewpoints. It is issuing a direct CRL. From pritikin@cisco.com Mon Jan 23 09:14:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB77521F8650 for ; Mon, 23 Jan 2012 09:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_ONLINE=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1bl4D-wpAiP for ; Mon, 23 Jan 2012 09:14:56 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6A75521F843C for ; Mon, 23 Jan 2012 09:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=6487; q=dns/txt; s=iport; t=1327338896; x=1328548496; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=p0h2QHMRqwTNor2Fe6+LHDAUMQNftRmCJq1Yxnp0EIM=; b=EydsEdlrXAJUaZ0E11mqCe67QYHXHIbqo/Qg0T2Z015ZHJDhhKXUkzc2 E/ouY63DUgKcmbTksIzcGqiRgrMCjcthiFWaUDkXMWHpd7XeI4aO8caUQ A/FNwalhHvsWvtnWLbqEFIro+MxtDxNnVMPCpMCQvgaPUQe/7ZvA1NhOq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAP6UHU+rRDoJ/2dsb2JhbAAtFq4ogQWBcgEBAQMBAQEBDwFbAQoFCwsYEwUWJzAGExoIh1oImisBngaIYCyDGgSIO4xeiwaHaA X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="26753647" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 23 Jan 2012 17:14:32 +0000 Received: from sjc-vpn6-694.cisco.com (sjc-vpn6-694.cisco.com [10.21.122.182]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0NHEUGN028359; Mon, 23 Jan 2012 17:14:31 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Max Pritikin In-Reply-To: <4F18A4B6.3060701@telia.com> Date: Mon, 23 Jan 2012 10:14:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <07123142-C9D7-493F-8681-548096731043@cisco.com> References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com> <4F1484F4.6020202@telia.com> <4F18A4B6.3060701@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1251.1) Cc: "pkix@ietf.org" Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-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: Mon, 23 Jan 2012 17:14:59 -0000 Inlines, On Jan 19, 2012, at 4:18 PM, Anders Rundgren wrote: > On 2012-01-19 18:24, Max Pritikin wrote: >>=20 >> Anders, >>=20 >> I'd like to address your concerns but their exact nature is not=20 >> clearly represented in your note. Two-factor authentication using >> a password/PIN along with a certificate (which may be stored in a >> token) is of course supported to meet EST Section 2, Requirement A5. >=20 > This section does not mention anything about the actual usage of > enrolled certificates or maybe it is just a bit vague on this point? Why would an enrollment protocol document "mention anything about the = actual usage of enrolled certificates"? I suppose there are some key = usage discussion that would be appropriate but those are generally = covered in the CSR and certificate extensions not the enrollment = protocol itself (since their assertions need to persist after the = enrollment protocol terminates).=20 > The bank I mentioned where thinking about how bank cards are used > (at least outside of the USA...), i.e. with a PIN. They felt that on- > line-enrolled credentials should follow this time-proven pattern as = well. >=20 > Anyway, deploying a PIN to a key is quite different from = authenticating > to a CA with PIN. "[D]eploying a PIN to a key" does sound vaguely like something that = might occur during enrollment. Would it be fair to characterize this as = a request/assertion from the CA that the client MUST encrypt/protect the = private key using a PIN to ensure authorized access? Or is this actual = deployment of the PIN where the CA has a hand in choosing an appropriate = PIN value (according to some CA policy)?=20 Or do you mean that during the "actual usage of the enrolled = certificate" the use of a PIN is proven by some subsequent protocol = enhancements (e.g. some extension to TLS or something). > I may be dumb but I don't see how PIN deployment could > be squeezed into EST without more or less starting over from scratch. One possible way to see if this idea could be squeezed into an existing = document would be for you to suggest exact document text. Or, = alternatively, to provide a new draft that specifically addresses your = concern. That way you can provide the exact normative text that meets = your concern and, in the process of writing it all down using normative = language sufficient for implementors to understand, will also generate = sufficiently detailed text that I might follow your thoughts as well. > BTW, the GlobalPlatform specification is public. There is still an "impedance mismatch" in that the GlobalPlatform = specification 2.2.1 is 283 pages long and covers a whole lot of material = which is not likely to be applicable to an enrollment protocol. If you = wish you present the GlobalPlatform use of PINs as an example I suspect = you can provide a more direct reference. If your concerns are addressed = in this document, and are so obviously stated that you expect a casual = reader to be able to find them quickly, then it should be easy for you = to quote the appropriate sections.=20 I look forward to reading your upcoming(?) draft/text on "deploying a = PIN to a key".=20 Thanks, - max > -- Anders >=20 >=20 >=20 >=20 >=20 >>=20 >> I suspect you're concerned with how the server might determine that = the certificate is physically contained within a specific cryptographic = token. As we've discussed previously this is an important concept that = is available, today, only by tokens that enforce implementation of the = enrollment protocol internally. In a previous thread I suggested = possible future extensions to the CSR that might serve to assert this = status in a way that can be transported over the existing protocols -- = but that I thought that work should likely proceed in a distinct draft.=20= >>=20 >> I see a couple of ways you can help to move your concern forward, >>=20 >> 1. If you feel this is something we can address immediately then = please provide a concrete textual suggestion for the EST draft. Using = normative language please feel free to suggest a section, extension, = message, paragraph etc for inclusion into the EST document that would = address your concern. It is significantly easier to evaluate an idea = when it has been laid out clearly and concisely in such a fashion. >>=20 >> 2. Another option is to provide a personal submission draft. Similar = to the above this provides a single document folks can read to help grok = your idea. This is similar to my suggestion of a distinct draft above = but since you'd be writing the first version you'd have editorial = control and could better ensure it meets your concerns. >>=20 >> Although I appreciate the link to Goole wallet marketing videos, and = the insight that they are using GlobalPlatform, there is a significant = "impedance mismatch" between this high level "somewhat sketchy" = description of a problem and the type of detail oriented discussion = necessary for an RFC. >>=20 >> I look forward to reading your suggested text as either feedback for = EST or a new document, >>=20 >> - max >>=20 >> On Jan 16, 2012, at 1:13 PM, Anders Rundgren wrote: >>=20 >>>> targeting simple Public Key Infrastructure clients that need >>>> to acquire client certificate(s) and associated Certification >>>> Authority (CA) certificate(s) >>>=20 >>> I just returned from a PKI install in a large bank where they (among >>> many things), intend to issue certificates to Androids and iPhones >>> using SCEP. When they told me that they required PIN-protected = keys, >>> I had to bring them the bad news that no existing or emerging PKIX >>> enrollment protocol actually support two-factor authentication = tokens. >>>=20 >>> It takes shelving out tons of legacy junk to move things forward. >>> This is particularly easy if you have no legacy :-) >>>=20 >>> http://www.google.com/wallet >>>=20 >>> The details are somewhat sketchy (big understatement), but off-list = I >>> have gotten the information that it is based on GlobalPlatform which >>> can be fully configured using end-to-end-security protocol = mechanisms. >>>=20 >>> -- Anders >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>=20 >>=20 >=20 From david.cooper@nist.gov Mon Jan 23 09:27:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAE921F84F9 for ; Mon, 23 Jan 2012 09:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2flSSlWP64qb for ; Mon, 23 Jan 2012 09:27:18 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 3870A21F84E2 for ; Mon, 23 Jan 2012 09:27:17 -0800 (PST) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q0NHR7Jk014965; Mon, 23 Jan 2012 12:27:08 -0500 Message-ID: <4F1D986A.9060700@nist.gov> Date: Mon, 23 Jan 2012 12:27:06 -0500 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111227 Thunderbird/9.0.1 MIME-Version: 1.0 To: "mrex@sap.com" References: <201201231522.q0NFMhU1008054@fs4113.wdf.sap.corp> In-Reply-To: <201201231522.q0NFMhU1008054@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Jan 2012 17:27:19 -0000 Martin, As Santosh noted, your comments seem to be based on a misunderstanding of X.509. There was no exemption/retrofit to allow to allow two or more CA certificates with different public keys to bear the same subject DN. In X.509, entities are identified by name, but by the key(s) they use to sign things, so there was no need for an exemption/retrofit to allow a CA to use more than one key to create signatures. The key identifier extensions are merely non-critical extensions that aid in determining which key was used to sign something/which certificate can be used to verify a signature. You have made a common mistake in misinterpreting the meaning of an indirect CRL. An indirect CRL is a "revocation list that at least contains revocation information about certificates issued by authorities other than that which issued this CRL", where an authority is "[a]n entity, responsible for the issuance of certificates." In the scenario that you present, the same authority signs both the CRL and all of the certificates covered by the CRL, so it is NOT an indirect CRL. The fact that the CA used different keys to sign the certificates and CRL is immaterial. On 01/23/2012 11:50 AM, Martin Rex wrote: > If that single CA uses distinct CRLs for each of its CA certs, dinstinguishing > them only by AKID, then indirect CRLs will no longer work, because it > would become possible for an attacker to cheat RPs with CRLs that > refer to the other CA cert than the one they wanted to check, and due > to the lack of an AKID in the CRLEntryExtension, the RP will be > unable to detect that it is being spoofed. As noted above this has nothing to do with indirect CRLs (even though many people incorrectly refer to this scenario as involving indirect CRLs). In the scenario you described above, the CA is broken. The AKID only aids the relying party in determining which key is needed to verify the signature on the CRL, it does not affect the scope of the CRL. As RFC 5280 says: A full and complete CRL lists all unexpired certificates issued by a CA that have been revoked for any reason. (Note that since CAs and CRL issuers are identified by name, the scope of a CRL is not affected by the key used to sign the CRL or the key(s) used to sign certificates.) X.509 is also clear on this: If the issuing distribution point field, the AA issuing distribution point field, and the CRL scope field are all absent, the CRL shall contain entries for all revoked unexpired public-key certificates issued by the CRL issuer. In the scenario above, if the CA signs certificates using two different keys and issues two CRLs, each CRL covering the certificates that were signed using the same key as the CRL, then the CRLs need to include a critical issuingDistributionPoint extension. In particular, each of the CRLs would have to be assigned a different DistributionPointName and this name would have to appear in the issuingDistributionPoint extensions of the CRLs and the cRLDistributionPoints extensions of the certificates. It would be the distribution point names that would distinguish between the CRLs and would inform relying parties which CRL provided revocation information for any given certificate, not the key identifiers. Dave On 01/23/2012 11:50 AM, Martin Rex wrote: > Santosh Chokhani wrote: >> Martin Rex wrote: >>>> It is not clear why you would need to access CA certificate via >>>> reference to CRL entry extension and thus I do not understand what >>>> you are trying to achieve >>> It appears that there was an exemption retrofitted into X.509/rfc5280 >>> to allow two (or more) CA certificates with different public keys to >>> bear the exact same Subject DName, and in order to disabiguate between >>> those CA certificates, the AKID extension is required in all places >>> where the CA certificate is referenced by IssuerName alone. >> [Santosh] That was not the purpose of AKID. AKID was intended to >> efficiently disambiguate between multiple signing keys held by the >> same CA, e.g., for due to key roll-over. > I fail to see a different between what I wrote and what you wrote. > > >>> AKID was added as an X.509v3 certificate extension and as a >>> CRL extension, but it seesm to be missing in CRLEntryExtension >>> and the CRLDistributionPoint extension. >> [Santosh] I do not see any value for it in CRL Entry extension since >> once the relying party trusts the CRL in question and assumes that >> the same authority would not service with two different CAs with >> the same name, it becomes a non-issue. > This is about one single CA holding certs with the exact same DName > and different keypairs. This may be for different algorithms > in parallel (RSA and ECDSA), or same algorithm but different key&validity > for key roll-over. > > If that single CA uses distinct CRLs for each of its CA certs, dinstinguishing > them only by AKID, then indirect CRLs will no longer work, because it > would become possible for an attacker to cheat RPs with CRLs that > refer to the other CA cert than the one they wanted to check, and due > to the lack of an AKID in the CRLEntryExtension, the RP will be > unable to detect that it is being spoofed. > > >> As to appearing in CRL DP, the CRL DP itself ensures that the correct >> indirect issuer is pointed to. > When CAs reuse DNames for differen keypairs, that does not seem to work > with indirect CRLs, because of the lack of an AKID in the CRL DP > that could be matched to the AKID of indirect signer in the CRLExtension. > > >> If you are concerned about mischief, AKID would not be the way to handle >> it since anyone can assert an AKID. You would need to include the >> Indirect CRL Signer Public Key or Secure Hash thereof. Note that this >> would be a change to the standard as well as remove flexibility from >> the indirect CRL issuer to rekey. > I'm concerned about what looks like an undefined/unspecified area > ITU-T X.509 / rfc5280 when combining CA DName re-use with indirect CRLs. > > >>> For simple (=direct) CRLs, the Cert IssuerName + Cert AKID match the >>> CRLSigner + CRLExtension.AKID and disambiguates for which CA (cert) >>> the CRL is authoritative. >>> >>> For indirect CRLs, the CRLSigner + CRLExtension.AKID refer to the >>> indirect signer, and the Link between the Cert and the >>> CRLEntryExtension.CertificateIssuer is dangling, because it lacks an >>> AKID that refers back to the Cert's AKID. >> [Santosh] As I said before, I do not think an Authority would service >> two different CAs with the same name. > The collision of CA Names from different PKIs or different sections > of the same PKI is not what I'm currently worrying about. > > I'm talking about one single organization/administrative entity > holding multiple CA certs with the same Subject DName but distinct > public key pairs. > > Every "self-issued" CA certificate is a DName re-use. > > > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > . > From david.cooper@nist.gov Mon Jan 23 09:46:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8F221F86F0 for ; Mon, 23 Jan 2012 09:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRYJS3V-mHBU for ; Mon, 23 Jan 2012 09:46:13 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0075321F86B8 for ; Mon, 23 Jan 2012 09:46:12 -0800 (PST) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q0NHk0ER017001; Mon, 23 Jan 2012 12:46:00 -0500 Message-ID: <4F1D9CD8.6050500@nist.gov> Date: Mon, 23 Jan 2012 12:46:00 -0500 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111227 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Miller, Timothy J." References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Jan 2012 17:46:13 -0000 X.509 is very clear. It requires names to be unambiguous. Where did you get the idea that X.509 was written with the understanding that the trust anchor needs to be included when considering a DN? Can you point to any text (other than unsubstantiated assertions made by other people on the mail list) to support this claim? On 01/23/2012 10:00 AM, Miller, Timothy J. wrote: > Not across different PKIs, no. Current software treats Issuer+Serial as a > unique identifier; this is a security risk. I can (and have, in the lab, > for compatibility testing purposes, honest!) created my own CAs that > collide names. > > Both X.509 and RFC 5280 are not clear on this point. They were written > with the understanding that the trust anchor needs to be included when > considering a DN, but this is a point that's lost on lots of > implementations. For example of this error, see Figure 21 in "Windows > Vista Smart Card Infrastructure" at: > > http://msdn.microsoft.com/en-us/library/bb905527.aspx > > > > Specifically, trace the thread for logon using the Subject+Issuer > alternative mapping. > > -- T > > On 1/23/12 8:29 AM, "Santosh Chokhani" wrote: > >> Are you saying that X.509 and RFC 5280 should NOT assume that the DN is >> unique? >> >> -----Original Message----- >> From: Miller, Timothy J. [mailto:tmiller@mitre.org] >> Sent: Monday, January 23, 2012 9:21 AM >> To: Santosh Chokhani; Russ Housley; mrex@sap.com >> Cc: pkix@ietf.org >> Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer >> >> On 1/22/12 7:41 AM, "Santosh Chokhani" wrote: >> >>> Per RFC 5280, Certificate Issuer for the CRL Entry Extension is a >>> GeneralNames, so no AKID is involved. >>> >>> Both X,500 and RFC 5280 assume that the DN (name) and serial number >>> uniquely identify the certificate based on the assumption that the >>> names are unique. >> This is probably something that needs to be written out of the RFC. >> >> -- T >> > From mrex@sap.com Mon Jan 23 09:59:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEDC21F86B8 for ; Mon, 23 Jan 2012 09:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.077 X-Spam-Level: X-Spam-Status: No, score=-10.077 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oocTyxo9w5o2 for ; Mon, 23 Jan 2012 09:59:53 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5D91621F86A4 for ; Mon, 23 Jan 2012 09:59:53 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0NHxqWa004839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jan 2012 18:59:52 +0100 (MET) From: Martin Rex Message-Id: <201201231759.q0NHxp4i017008@fs4113.wdf.sap.corp> To: david.cooper@nist.gov (David A. Cooper) Date: Mon, 23 Jan 2012 18:59:51 +0100 (MET) In-Reply-To: <4F1D986A.9060700@nist.gov> from "David A. Cooper" at Jan 23, 12 12:27:06 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] AuthKeyId and CrlEntryExtension.CertificateIssuer 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, 23 Jan 2012 17:59:54 -0000 David A. Cooper wrote: > > As Santosh noted, your comments seem to be based on a misunderstanding > of X.509. There was no exemption/retrofit to allow to allow two or more > CA certificates with different public keys to bear the same subject DN. Now I am confused. > > In X.509, entities are identified by name, but by the key(s) they use to > sign things, so there was no need for an exemption/retrofit to allow a > CA to use more than one key to create signatures. The key identifier > extensions are merely non-critical extensions that aid in determining > which key was used to sign something/which certificate can be used to > verify a signature. This contradicts the previous statements. If CA certs that differ in public key are also required to differ in subject DName, then there exists no ambiguity that AKID would have to resolve. > > You have made a common mistake in misinterpreting the meaning of an > indirect CRL. An indirect CRL is a "revocation list that at least > contains revocation information about certificates issued by authorities > other than that which issued this CRL", where an authority is "[a]n > entity, responsible for the issuance of certificates." In the scenario > that you present, the same authority signs both the CRL and all of the > certificates covered by the CRL, so it is NOT an indirect CRL. The fact > that the CA used different keys to sign the certificates and CRL is > immaterial. That is not how I understand (and implemented) CRL checking. Direct CRL is the case when the CRLIssuer is the same as the certificate issuer, and that means during path validation, that I use the *EXACT* same CA certificate to verify the CA signature as the CRL signature. -Martin From DPKemp@missi.ncsc.mil Mon Jan 23 10:51:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5D321F869C for ; Mon, 23 Jan 2012 10:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7Fx65NV2WFI for ; Mon, 23 Jan 2012 10:51:42 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4780921F8693 for ; Mon, 23 Jan 2012 10:51:42 -0800 (PST) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q0NIpfkt043534 for ; Mon, 23 Jan 2012 13:51:41 -0500 (EST) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jan 2012 13:52:42 -0500 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: Mon, 23 Jan 2012 13:51:32 -0500 Message-ID: In-Reply-To: <4F1D9CD8.6050500@nist.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: AczZ9u/2Ju340PlaSQK8L/j6RGLhjQABafYA References: <4F1D9CD8.6050500@nist.gov> From: "Kemp, David P." To: X-OriginalArrivalTime: 23 Jan 2012 18:52:42.0796 (UTC) FILETIME=[300DAEC0:01CCDA00] Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Jan 2012 18:51:43 -0000 X.509 is very clear in its scope: "The Directory: Public-key and attribute certificate frameworks". When X.509 is used outside the scope of a global Directory, bad things can happen. It is impossible for any CA to determine (much less prove) the negative: "no X.509 certificate has been issued anywhere in the world with DN ", and only universal participation in a naming framework (such as a global Directory) can ensure name uniqueness*. Where is that naming framework? You can do your best to comply with X.509, but as soon as someone else issues a cert containing a DN that you also use, you are both non-compliant. Dave * excluding names with verified cryptographic uniqueness, of course. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of David A. Cooper Sent: Monday, January 23, 2012 12:46 PM To: Miller, Timothy J. Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X.509 is very clear. It requires names to be unambiguous. Where did you get the idea that X.509 was written with the understanding that the trust anchor needs to be included when considering a DN? Can you point to any text (other than unsubstantiated assertions made by other people on the mail list) to support this claim? On 01/23/2012 10:00 AM, Miller, Timothy J. wrote: > Not across different PKIs, no. Current software treats Issuer+Serial=20 > as a unique identifier; this is a security risk. I can (and have, in=20 > the lab, for compatibility testing purposes, honest!) created my own=20 > CAs that collide names. > > Both X.509 and RFC 5280 are not clear on this point. They were=20 > written with the understanding that the trust anchor needs to be=20 > included when considering a DN, but this is a point that's lost on=20 > lots of implementations. For example of this error, see Figure 21 in > "Windows Vista Smart Card Infrastructure" at: > > http://msdn.microsoft.com/en-us/library/bb905527.aspx > > > > Specifically, trace the thread for logon using the Subject+Issuer=20 > alternative mapping. > > -- T > > On 1/23/12 8:29 AM, "Santosh Chokhani" wrote: > >> Are you saying that X.509 and RFC 5280 should NOT assume that the DN=20 >> is unique? >> >> -----Original Message----- >> From: Miller, Timothy J. [mailto:tmiller@mitre.org] >> Sent: Monday, January 23, 2012 9:21 AM >> To: Santosh Chokhani; Russ Housley; mrex@sap.com >> Cc: pkix@ietf.org >> Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer >> >> On 1/22/12 7:41 AM, "Santosh Chokhani" wrote: >> >>> Per RFC 5280, Certificate Issuer for the CRL Entry Extension is a=20 >>> GeneralNames, so no AKID is involved. >>> >>> Both X,500 and RFC 5280 assume that the DN (name) and serial number=20 >>> uniquely identify the certificate based on the assumption that the=20 >>> names are unique. >> This is probably something that needs to be written out of the RFC. >> >> -- T >> > _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From david.cooper@nist.gov Mon Jan 23 11:43:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EED221F867B for ; Mon, 23 Jan 2012 11:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.27 X-Spam-Level: X-Spam-Status: No, score=-5.27 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzwIoeSUaOp1 for ; Mon, 23 Jan 2012 11:43:41 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 248F821F8688 for ; Mon, 23 Jan 2012 11:43:40 -0800 (PST) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q0NJhTvN015194; Mon, 23 Jan 2012 14:43:29 -0500 Message-ID: <4F1DB860.3020804@nist.gov> Date: Mon, 23 Jan 2012 14:43:28 -0500 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111227 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Kemp, David P." References: <4F1D9CD8.6050500@nist.gov> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 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, 23 Jan 2012 19:43:42 -0000 On 01/23/2012 01:51 PM, Kemp, David P. wrote: 
X.509 is very clear in its scope: "The Directory: Public-key and
attribute certificate frameworks".   When X.509 is used outside the
scope of a global Directory, bad things can happen.

If the scope of X.509 is so clearly limited to the use of certificates as part of a global Directory, while doesn't the document say that somewhere, such as in the "Scope" section?  The existence of the words "The Directory" in the title proves nothing.

It is impossible for any CA to determine (much less prove) the negative:
"no X.509 certificate has been issued anywhere in the world with DN
<x>", and only universal participation in a naming framework (such as a
global Directory) can ensure name uniqueness*.  Where is that naming
framework?  You can do your best to comply with X.509, but as soon as
someone else issues a cert containing a DN that you also use, you are
both non-compliant.

X.509 says:

      For every name form used in the GeneralName type, there shall
      be a name registration system that ensures that any "name used
      unambiguously identifies one entity to both certificate issuer and
      certificate users.


Contrary to your assertion this does not require the existence of a global Directory.  There is no global directory for object identifiers, and yet no one is saying that we can't use OIDs to unambiguously identify things (algorithms, certificate policies, naming attributes, extensions, etc.).

The IETF has even accepted a document (RFC 4122) that claims a Universally Unique IDentitifer (UUID), even though RFC 4122 says that "A UUID is 128 bits long, and can guarantee uniqueness across space and time" and that the creation of UUIDs "requires no central registration process."  Did I miss the part in RFC 4122 where it imposes a requirement for there to be a global directory of UUIDs in order to ensure uniqueness?

The fact is that X.509 requires names to be unambiguous, regardless of whether a global Directory is being used.  Any argument about how CAs cannot ensure that this requirement is satisfied is an argument against X.509, not an argument that the requirement doesn't exist.

Dave

Dave

* excluding names with verified cryptographic uniqueness, of course.


-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of
David A. Cooper
Sent: Monday, January 23, 2012 12:46 PM
To: Miller, Timothy J.
Cc: pkix@ietf.org
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

X.509 is very clear.  It requires names to be unambiguous.  Where did
you get the idea that X.509 was written with the understanding that the
trust anchor needs to be included when considering a DN?  Can you point
to any text (other than unsubstantiated assertions made by other people
on the mail list) to support this claim?

On 01/23/2012 10:00 AM, Miller, Timothy J. wrote:

Not across different PKIs, no.  Current software treats Issuer+Serial 
as a unique identifier; this is a security risk.  I can (and have, in 
the lab, for compatibility testing purposes, honest!) created my own 
CAs that collide names.

Both X.509 and RFC 5280 are not clear on this point.  They were 
written with the understanding that the trust anchor needs to be 
included when considering a DN, but this is a point that's lost on 
lots of implementations.  For example of this error, see Figure 21 in


      

        
"Windows Vista Smart Card Infrastructure" at:

http://msdn.microsoft.com/en-us/library/bb905527.aspx



Specifically, trace the thread for logon using the Subject+Issuer 
alternative mapping.

-- T

On 1/23/12 8:29 AM, "Santosh Chokhani"<SChokhani@cygnacom.com>  wrote:



        

          
Are you saying that X.509 and RFC 5280 should NOT assume that the DN 
is unique?

-----Original Message-----
From: Miller, Timothy J. [mailto:tmiller@mitre.org]
Sent: Monday, January 23, 2012 9:21 AM
To: Santosh Chokhani; Russ Housley; mrex@sap.com
Cc: pkix@ietf.org
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

On 1/22/12 7:41 AM, "Santosh Chokhani"<SChokhani@cygnacom.com>


        

      

      
wrote:


      

        

          

          

            
Per RFC 5280, Certificate Issuer  for the CRL Entry Extension is a 
GeneralNames, so no AKID is involved.

Both X,500 and RFC 5280 assume that the DN (name) and serial number 
uniquely identify the certificate based on the assumption that the 
names are unique.


          

          
This is probably something that needs to be written out of the RFC.

-- T


        

      

    

  


From tmiller@mitre.org  Mon Jan 23 11:53:34 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED1921F8619 for ; Mon, 23 Jan 2012 11:53:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level: 
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l75sAnadmAGk for ; Mon, 23 Jan 2012 11:53:33 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4E721F85BB for ; Mon, 23 Jan 2012 11:53:33 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 78B1921B13AE; Mon, 23 Jan 2012 14:53:32 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6A66721B171D; Mon, 23 Jan 2012 14:53:32 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.158]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Mon, 23 Jan 2012 14:53:32 -0500
From: "Miller, Timothy J." 
To: "David A. Cooper" 
Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
Thread-Index: AczZC5zBkYunh8ou0k2O3ixXfjBtFgAxkqcAAAJcydD///f6AIAAkt8A//+/CYA=
Date: Mon, 23 Jan 2012 19:53:32 +0000
Message-ID: 
In-Reply-To: <4F1D9CD8.6050500@nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [172.31.58.164]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 23 Jan 2012 19:53:34 -0000

On 1/23/12 11:46 AM, "David A. Cooper"  wrote:

>X.509 is very clear.  It requires names to be unambiguous.  Where did
>you get the idea that X.509 was written with the understanding that the
>trust anchor needs to be included when considering a DN?  Can you point
>to any text (other than unsubstantiated assertions made by other people
>on the mail list) to support this claim?

If I give you the chain:

CN=3DCooperCo Root CA,O=3DCooperCo,C=3DUS
  CN=3DCooperCo Issuing CA,O=3DCooperCo,C=3DUS
    CN=3DDavid.Cooper,O=3DCooperCo,C=3DUS
      serialNumber=3D0x0100

And the chain:

CN=3DVeriSign Class 3 Public Primary Certification Authority - G5,OU=3D(c)
2006 VeriSign, Inc. - For authorized use only,OU=3DVeriSign Trust
Network,O=3DVerisign, Inc.,C=3DUS
  CN=3DCooperCo Issuing CA,O=3DCooperCo,C=3DUS
    CN=3DDavid.Cooper,O=3DCooperCo,C=3DUS
      serialNumber=3D0x0100

If I give you the pair:

("CN=3DCooperCo Issuing CA,O=3DCooperCo,C=3DUS","serialNumber=3D0x0100")


To which certificate does it refer?

-- T


From david.cooper@nist.gov  Mon Jan 23 12:00:13 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804F621F86BA for ; Mon, 23 Jan 2012 12:00:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.056
X-Spam-Level: 
X-Spam-Status: No, score=-6.056 tagged_above=-999 required=5 tests=[AWL=0.543,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iMPmfdIFysb for ; Mon, 23 Jan 2012 12:00:12 -0800 (PST)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 086B921F86B0 for ; Mon, 23 Jan 2012 12:00:11 -0800 (PST)
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q0NK01Os016100; Mon, 23 Jan 2012 15:00:02 -0500
Message-ID: <4F1DBC41.4020601@nist.gov>
Date: Mon, 23 Jan 2012 15:00:01 -0500
From: "David A. Cooper" 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111227 Thunderbird/9.0.1
MIME-Version: 1.0
To: "mrex@sap.com" 
References: <201201231759.q0NHxp4i017008@fs4113.wdf.sap.corp>
In-Reply-To: <201201231759.q0NHxp4i017008@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 23 Jan 2012 20:00:13 -0000

Yes, it is very clear that you are confused. You apparently have an 
incorrect model of the way that X.509 works and you are attempting to 
interpret every X.509 says and everything I say in a way that is 
consistent with your flawed model.

At no point did I say that CA certs differ in public key that they are 
also required to differ in subject DN.  What I said is that entities, 
including CAs and CRL issuers, are identified by name only, not by the 
key they use to sign things.

Your understanding of CRL checking is incorrect, as you are 
misinterpreting the meaning of "same issuer".  X.509 says that "CAs are 
unambiguously defined by a distinguished name".  So, "same issuer" means 
"same distinguished name".  It does not necessarily mean that they were 
signed by the same key or that the same certificate may be used to 
verify the signatures on both objects.

If I sign two documents, but sign one with my left hand and one with my 
right hand, weren't both documents still signed by the same entity 
(person)?  It's the same with X.509 and keys.  If a CA, which is 
"unambiguously defined by a distinguished name", signs two objects, but 
uses different keys to sign the two documents, both documents were still 
signed by the same CA.

Dave

On 01/23/2012 12:59 PM, Martin Rex wrote:
> David A. Cooper wrote:
>> As Santosh noted, your comments seem to be based on a misunderstanding
>> of X.509.  There was no exemption/retrofit to allow to allow two or more
>> CA certificates with different public keys to bear the same subject DN.
> Now I am confused.
>
>> In X.509, entities are identified by name, but by the key(s) they use to
>> sign things, so there was no need for an exemption/retrofit to allow a
>> CA to use more than one key to create signatures.  The key identifier
>> extensions are merely non-critical extensions that aid in determining
>> which key was used to sign something/which certificate can be used to
>> verify a signature.
> This contradicts the previous statements.  If CA certs that differ in
> public key are also required to differ in subject DName, then there exists
> no ambiguity that AKID would have to resolve.
>
>
>> You have made a common mistake in misinterpreting the meaning of an
>> indirect CRL.  An indirect CRL is a "revocation list that at least
>> contains revocation information about certificates issued by authorities
>> other than that which issued this CRL", where an authority is "[a]n
>> entity, responsible for the issuance of certificates."  In the scenario
>> that you present, the same authority signs both the CRL and all of the
>> certificates covered by the CRL, so it is NOT an indirect CRL.  The fact
>> that the CA used different keys to sign the certificates and CRL is
>> immaterial.
>
> That is not how I understand (and implemented) CRL checking.
> Direct CRL is the case when the CRLIssuer is the same as the
> certificate issuer, and that means during path validation,
> that I use the *EXACT* same CA certificate to verify the
> CA signature as the CRL signature.
>
>
> -Martin
> .
>


From housley@vigilsec.com  Mon Jan 23 12:11:42 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE6021F8622 for ; Mon, 23 Jan 2012 12:11:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.381
X-Spam-Level: 
X-Spam-Status: No, score=-101.381 tagged_above=-999 required=5 tests=[AWL=-1.082, BAYES_00=-2.599, MANGLED_ONLINE=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pph2QAWBPdTf for ; Mon, 23 Jan 2012 12:11:42 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0763621F85D0 for ; Mon, 23 Jan 2012 12:11:42 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id EC676F240AE; Mon, 23 Jan 2012 15:11:41 -0500 (EST)
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 Lw3uVHvE7Akj; Mon, 23 Jan 2012 15:10:53 -0500 (EST)
Received: from [192.168.2.104] (pool-96-241-165-215.washdc.fios.verizon.net [96.241.165.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 75E36F240A5; Mon, 23 Jan 2012 15:11:41 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley 
In-Reply-To: <07123142-C9D7-493F-8681-548096731043@cisco.com>
Date: Mon, 23 Jan 2012 15:11:40 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E4D80C3-1BFC-4A3C-977B-9D5D828C3D2A@vigilsec.com>
References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com>  <4F1484F4.6020202@telia.com>  <4F18A4B6.3060701@telia.com> <07123142-C9D7-493F-8681-548096731043@cisco.com>
To: Max Pritikin 
X-Mailer: Apple Mail (2.1084)
Cc: IETF PKIX 
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-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: Mon, 23 Jan 2012 20:11:42 -0000

Max:

>> The bank I mentioned where thinking about how bank cards are used
>> (at least outside of the USA...), i.e. with a PIN.  They felt that =
on-
>> line-enrolled credentials should follow this time-proven pattern as =
well.
>>=20
>> Anyway, deploying a PIN to a key is quite different from =
authenticating
>> to a CA with PIN.
>=20
> "[D]eploying a PIN to a key" does sound vaguely like something that =
might occur during enrollment. Would it be fair to characterize this as =
a request/assertion from the CA that the client MUST encrypt/protect the =
private key using a PIN to ensure authorized access? Or is this actual =
deployment of the PIN where the CA has a hand in choosing an appropriate =
PIN value (according to some CA policy)?=20
>=20
> Or do you mean that during the "actual usage of the enrolled =
certificate" the use of a PIN is proven by some subsequent protocol =
enhancements (e.g. some extension to TLS or something).

I think it is the other way round.  A PIN / password / passphrase is =
given  by the RA want a person completes face-to-face proofing, and this =
is used in a one-time fashion during the enrollment process as proof =
that that proofing has taken place with the party that is presenting the =
certificate request.

Russ


From david.cooper@nist.gov  Mon Jan 23 12:27:37 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCD721F8735 for ; Mon, 23 Jan 2012 12:27:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.892
X-Spam-Level: 
X-Spam-Status: No, score=-5.892 tagged_above=-999 required=5 tests=[AWL=0.107,  BAYES_00=-2.599, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGxurgL1pIi8 for ; Mon, 23 Jan 2012 12:27:36 -0800 (PST)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6B93921F85BB for ; Mon, 23 Jan 2012 12:27:36 -0800 (PST)
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q0NKRR9e018459; Mon, 23 Jan 2012 15:27:27 -0500
Message-ID: <4F1DC2AF.6050903@nist.gov>
Date: Mon, 23 Jan 2012 15:27:27 -0500
From: "David A. Cooper" 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111227 Thunderbird/9.0.1
MIME-Version: 1.0
To: "Miller, Timothy J." 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 23 Jan 2012 20:27:37 -0000

While I can only guess at how to interpret your certificate chains, it 
appears that the CA "CN=CooperCo Issuing CA,O=CooperCo,C=US" has issued 
a certificate to "CN=David.Cooper,O=CooperCo,C=US" with serial number 
0x0100, and that two different CAs ("CN=CooperCo Root 
CA,O=CooperCo,C=US" and "CN=VeriSign Class 3 Public Primary 
Certification Authority - G5,OU=(c) 2006 VeriSign, Inc. - For authorized 
use only,OU=VeriSign Trust Network,O=Verisign, Inc.,C=US") have issued 
certificates to "CN=CooperCo Issuing CA,O=CooperCo,C=US".  I have no 
idea what you mean by "To which certificate does it refer?"

Are suggesting that "CN=CooperCo Root CA,O=CooperCo,C=US" and 
"CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU=(c) 
2006 VeriSign, Inc. - For authorized use only,OU=VeriSign Trust 
Network,O=Verisign, Inc.,C=US" have actually issued certificates to two 
different CAs that both issue certificates under the name "CN=CooperCo 
Issuing CA,O=CooperCo,C=US"?  If so, how does this in any way prove that 
X.509 was  "written with the understanding that the trust anchor needs 
to be included when considering a DN"?  I can create a certificate that 
has a negative serial number, but that's not proof that RFC 5280 doesn't 
say "The serial number MUST be a positive integer assigned by the CA to 
each certificate."

Dave

On 01/23/2012 02:53 PM, Miller, Timothy J. wrote:
> On 1/23/12 11:46 AM, "David A. Cooper"  wrote:
>
>> X.509 is very clear.  It requires names to be unambiguous.  Where did
>> you get the idea that X.509 was written with the understanding that the
>> trust anchor needs to be included when considering a DN?  Can you point
>> to any text (other than unsubstantiated assertions made by other people
>> on the mail list) to support this claim?
> If I give you the chain:
>
> CN=CooperCo Root CA,O=CooperCo,C=US
>    CN=CooperCo Issuing CA,O=CooperCo,C=US
>      CN=David.Cooper,O=CooperCo,C=US
>        serialNumber=0x0100
>
> And the chain:
>
> CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU=(c)
> 2006 VeriSign, Inc. - For authorized use only,OU=VeriSign Trust
> Network,O=Verisign, Inc.,C=US
>    CN=CooperCo Issuing CA,O=CooperCo,C=US
>      CN=David.Cooper,O=CooperCo,C=US
>        serialNumber=0x0100
>
> If I give you the pair:
>
> ("CN=CooperCo Issuing CA,O=CooperCo,C=US","serialNumber=0x0100")
>
>
> To which certificate does it refer?
>
> -- T
>
> .
>


From DPKemp@missi.ncsc.mil  Mon Jan 23 12:58:17 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DCF21F86A4 for ; Mon, 23 Jan 2012 12:58:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level: 
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKOStVSQsMJd for ; Mon, 23 Jan 2012 12:58:17 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id EFA9921F860F for ; Mon, 23 Jan 2012 12:58:16 -0800 (PST)
Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q0NKwG2g046163 for ; Mon, 23 Jan 2012 15:58:16 -0500 (EST)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 23 Jan 2012 15:59:17 -0500
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: Mon, 23 Jan 2012 15:57:43 -0500
Message-ID: 
In-Reply-To: <4F1DB860.3020804@nist.gov>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
Thread-Index: AczaB1AL3kxhxB+0SzadSKHexx7VKAAAIuZQ
References:  <4F1D9CD8.6050500@nist.gov>  <4F1DB860.3020804@nist.gov>
From: "Kemp, David P." 
To: 
X-OriginalArrivalTime: 23 Jan 2012 20:59:17.0093 (UTC) FILETIME=[DE9B7150:01CCDA11]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 23 Jan 2012 20:58:18 -0000

An argument that X.509 cannot ensure uniqueness of DNs (in the absence
of a Directory or global DN registry) is, as you say, an argument
against X.509.

The proposal to associate Issuer/Serial with a trust anchor addresses
that argument against X.509 with a mechanism that guarantees global
uniqueness as long as each trust anchor ensures local uniqueness, and
confines any collisions within a single trust anchor to its local scope.

The requirement exists.  And it is circular and specious to argue that
the enhancement is unnecessary "because X.509 requires DNs to be
globally unique".  That's like arguing there's no need to install street
lights because there's already a regulation for streets to be adequately
lit.

Dave K


-----Original Message-----
From: David A. Cooper [mailto:david.cooper@nist.gov]=20
Sent: Monday, January 23, 2012 2:43 PM
To: Kemp, David P.
Cc: pkix@ietf.org
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

On 01/23/2012 01:51 PM, Kemp, David P. wrote:=20

	X.509 is very clear in its scope: "The Directory: Public-key and
	attribute certificate frameworks".   When X.509 is used outside
the
	scope of a global Directory, bad things can happen.


If the scope of X.509 is so clearly limited to the use of certificates
as part of a global Directory, while doesn't the document say that
somewhere, such as in the "Scope" section?  The existence of the words
"The Directory" in the title proves nothing.



	It is impossible for any CA to determine (much less prove) the
negative:
	"no X.509 certificate has been issued anywhere in the world with
DN
	", and only universal participation in a naming framework
(such as a
	global Directory) can ensure name uniqueness*.  Where is that
naming
	framework?  You can do your best to comply with X.509, but as
soon as
	someone else issues a cert containing a DN that you also use,
you are
	both non-compliant.


X.509 says:

      For every name form used in the GeneralName type, there shall
      be a name registration system that ensures that any "name used
      unambiguously identifies one entity to both certificate issuer and
      certificate users.


Contrary to your assertion this does not require the existence of a
global Directory.  There is no global directory for object identifiers,
and yet no one is saying that we can't use OIDs to unambiguously
identify things (algorithms, certificate policies, naming attributes,
extensions, etc.).

The IETF has even accepted a document (RFC 4122) that claims a
Universally Unique IDentitifer (UUID), even though RFC 4122 says that "A
UUID is 128 bits long, and can guarantee uniqueness across space and
time" and that the creation of UUIDs "requires no central registration
process."  Did I miss the part in RFC 4122 where it imposes a
requirement for there to be a global directory of UUIDs in order to
ensure uniqueness?

The fact is that X.509 requires names to be unambiguous, regardless of
whether a global Directory is being used.  Any argument about how CAs
cannot ensure that this requirement is satisfied is an argument against
X.509, not an argument that the requirement doesn't exist.

Dave



=09
	Dave
=09
	* excluding names with verified cryptographic uniqueness, of
course.
=09
=09
	-----Original Message-----
	From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On
Behalf Of
	David A. Cooper
	Sent: Monday, January 23, 2012 12:46 PM
	To: Miller, Timothy J.
	Cc: pkix@ietf.org
	Subject: Re: [pkix] AuthKeyId and
CrlEntryExtension.CertificateIssuer
=09
	X.509 is very clear.  It requires names to be unambiguous.
Where did
	you get the idea that X.509 was written with the understanding
that the
	trust anchor needs to be included when considering a DN?  Can
you point
	to any text (other than unsubstantiated assertions made by other
people
	on the mail list) to support this claim?
=09
	On 01/23/2012 10:00 AM, Miller, Timothy J. wrote:

		Not across different PKIs, no.  Current software treats
Issuer+Serial=20
		as a unique identifier; this is a security risk.  I can
(and have, in=20
		the lab, for compatibility testing purposes, honest!)
created my own=20
		CAs that collide names.
	=09
		Both X.509 and RFC 5280 are not clear on this point.
They were=20
		written with the understanding that the trust anchor
needs to be=20
		included when considering a DN, but this is a point
that's lost on=20
		lots of implementations.  For example of this error, see
Figure 21 in

=09

		"Windows Vista Smart Card Infrastructure" at:
	=09
		http://msdn.microsoft.com/en-us/library/bb905527.aspx
	=09
	=09
	=09
		Specifically, trace the thread for logon using the
Subject+Issuer=20
		alternative mapping.
	=09
		-- T
	=09
		On 1/23/12 8:29 AM, "Santosh
Chokhani" 
wrote:
	=09

			Are you saying that X.509 and RFC 5280 should
NOT assume that the DN=20
			is unique?
		=09
			-----Original Message-----
			From: Miller, Timothy J.
[mailto:tmiller@mitre.org]
			Sent: Monday, January 23, 2012 9:21 AM
			To: Santosh Chokhani; Russ Housley; mrex@sap.com
			Cc: pkix@ietf.org
			Subject: Re: [pkix] AuthKeyId and
CrlEntryExtension.CertificateIssuer
		=09
			On 1/22/12 7:41 AM, "Santosh
Chokhani" =20

	wrote:

		=09

				Per RFC 5280, Certificate Issuer  for
the CRL Entry Extension is a=20
				GeneralNames, so no AKID is involved.
			=09
				Both X,500 and RFC 5280 assume that the
DN (name) and serial number=20
				uniquely identify the certificate based
on the assumption that the=20
				names are unique.

			This is probably something that needs to be
written out of the RFC.
		=09
			-- T


From mrex@sap.com  Mon Jan 23 13:12:08 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1398521F849C for ; Mon, 23 Jan 2012 13:12:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.089
X-Spam-Level: 
X-Spam-Status: No, score=-10.089 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaCyZtYgmbrU for ; Mon, 23 Jan 2012 13:12:07 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4764921F8484 for ; Mon, 23 Jan 2012 13:12:06 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0NLC56M021005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jan 2012 22:12:05 +0100 (MET)
From: Martin Rex 
Message-Id: <201201232112.q0NLC5P6027885@fs4113.wdf.sap.corp>
To: david.cooper@nist.gov (David A. Cooper)
Date: Mon, 23 Jan 2012 22:12:05 +0100 (MET)
In-Reply-To: <4F1DBC41.4020601@nist.gov> from "David A. Cooper" at Jan 23, 12 03:00:01 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] AuthKeyId and CrlEntryExtension.CertificateIssuer
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, 23 Jan 2012 21:12:08 -0000

David A. Cooper wrote:
> 
> Yes, it is very clear that you are confused. You apparently have an 
> incorrect model of the way that X.509 works and you are attempting to 
> interpret every X.509 says and everything I say in a way that is 
> consistent with your flawed model.
> 
> At no point did I say that CA certs differ in public key that they are 
> also required to differ in subject DN.  What I said is that entities, 
> including CAs and CRL issuers, are identified by name only, not by the 
> key they use to sign things.
> 
> Your understanding of CRL checking is incorrect, as you are 
> misinterpreting the meaning of "same issuer".  X.509 says that "CAs are 
> unambiguously defined by a distinguished name".  So, "same issuer" means 
> "same distinguished name".  It does not necessarily mean that they were 
> signed by the same key or that the same certificate may be used to 
> verify the signatures on both objects.

If this would be true, this would entirely kill section 6.3 CRL checking
out of rfc5280.

When I'm doing certificate path validation, then all I have is the
chain that I received from the peer.  If a CRL without indirect
issuer does not verify with the exact same cert that verifies the
signature on the cert, then I fail path validation.


> 
> If I sign two documents, but sign one with my left hand and one with my 
> right hand, weren't both documents still signed by the same entity 
> (person)?  It's the same with X.509 and keys.  If a CA, which is 
> "unambiguously defined by a distinguished name", signs two objects, but 
> uses different keys to sign the two documents, both documents were still 
> signed by the same CA.


The same entity that signed the certificate in my reading
refers to the the exact same signer cert.  There is no other
trusted (verified) CA cert available at that point, anyway.


-Martin

From david.cooper@nist.gov  Mon Jan 23 13:19:57 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1E521F86C7 for ; Mon, 23 Jan 2012 13:19:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.184
X-Spam-Level: 
X-Spam-Status: No, score=-5.184 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqciQwEYz4SC for ; Mon, 23 Jan 2012 13:19:55 -0800 (PST)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 56DA221F8548 for ; Mon, 23 Jan 2012 13:19:55 -0800 (PST)
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q0NLJk6B008430; Mon, 23 Jan 2012 16:19:46 -0500
Message-ID: <4F1DCEF2.2080404@nist.gov>
Date: Mon, 23 Jan 2012 16:19:46 -0500
From: "David A. Cooper" 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111227 Thunderbird/9.0.1
MIME-Version: 1.0
To: "Kemp, David P." 
References:  <4F1D9CD8.6050500@nist.gov>  <4F1DB860.3020804@nist.gov> 
In-Reply-To: 
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 23 Jan 2012 21:19:57 -0000


  
    
  
  
    David,

    

    I suggest you read what people actually say before falsely accusing
    them of making "circular and specious" arguments.  Timothy Miller
    did not propose "to associate Issuer/Serial with a trust
    anchor".  He said:

    

    On 01/23/2012 10:00 AM, Miller, Timothy J. wrote:
    

      
Both X.509 and RFC 5280 are not clear on this point.  They were written
with the understanding that the trust anchor needs to be included when
considering a DN, but this is a point that's lost on lots of
implementations.

    

    

    There is a major difference between prosing something and stating
    that the standard was "written with the understanding that...."

    

    I asked for evidence to support his assertion that "[X.509 and RFC
    5280] were written with the understanding that the trust anchor
    needs to be included when considering a DN".

    

    The fact that you are referring to this as a "proposal" and an
    "enhancement" only demonstrates that you agree with me.  

    

    On 01/23/2012 03:57 PM, Kemp, David P. wrote:
    

      
An argument that X.509 cannot ensure uniqueness of DNs (in the absence
of a Directory or global DN registry) is, as you say, an argument
against X.509.

The proposal to associate Issuer/Serial with a trust anchor addresses
that argument against X.509 with a mechanism that guarantees global
uniqueness as long as each trust anchor ensures local uniqueness, and
confines any collisions within a single trust anchor to its local scope.

The requirement exists.  And it is circular and specious to argue that
the enhancement is unnecessary "because X.509 requires DNs to be
globally unique".  That's like arguing there's no need to install street
lights because there's already a regulation for streets to be adequately
lit.

    

    

    No, this would be someone claiming that the lights on a certain
    street don't meet the regulations, and then me arguing that the
    street does meet the regulations since the regulations only require
    one street light every 100m and the street has one street light
    every 90m, and then you falsely accusing me of having said that the
    street was adequately lit, even though I never suggested that the
    regulations were adequate.

    

    

      
-----Original Message-----
From: David A. Cooper [mailto:david.cooper@nist.gov] 
Sent: Monday, January 23, 2012 2:43 PM
To: Kemp, David P.
Cc: pkix@ietf.org
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

On 01/23/2012 01:51 PM, Kemp, David P. wrote: 

	X.509 is very clear in its scope: "The Directory: Public-key and
	attribute certificate frameworks".   When X.509 is used outside
the
	scope of a global Directory, bad things can happen.


If the scope of X.509 is so clearly limited to the use of certificates
as part of a global Directory, while doesn't the document say that
somewhere, such as in the "Scope" section?  The existence of the words
"The Directory" in the title proves nothing.



	It is impossible for any CA to determine (much less prove) the
negative:
	"no X.509 certificate has been issued anywhere in the world with
DN
	<x>", and only universal participation in a naming framework
(such as a
	global Directory) can ensure name uniqueness*.  Where is that
naming
	framework?  You can do your best to comply with X.509, but as
soon as
	someone else issues a cert containing a DN that you also use,
you are
	both non-compliant.


X.509 says:

      For every name form used in the GeneralName type, there shall
      be a name registration system that ensures that any "name used
      unambiguously identifies one entity to both certificate issuer and
      certificate users.


Contrary to your assertion this does not require the existence of a
global Directory.  There is no global directory for object identifiers,
and yet no one is saying that we can't use OIDs to unambiguously
identify things (algorithms, certificate policies, naming attributes,
extensions, etc.).

The IETF has even accepted a document (RFC 4122) that claims a
Universally Unique IDentitifer (UUID), even though RFC 4122 says that "A
UUID is 128 bits long, and can guarantee uniqueness across space and
time" and that the creation of UUIDs "requires no central registration
process."  Did I miss the part in RFC 4122 where it imposes a
requirement for there to be a global directory of UUIDs in order to
ensure uniqueness?

The fact is that X.509 requires names to be unambiguous, regardless of
whether a global Directory is being used.  Any argument about how CAs
cannot ensure that this requirement is satisfied is an argument against
X.509, not an argument that the requirement doesn't exist.

Dave



	
	Dave
	
	* excluding names with verified cryptographic uniqueness, of
course.
	
	
	-----Original Message-----
	From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On
Behalf Of
	David A. Cooper
	Sent: Monday, January 23, 2012 12:46 PM
	To: Miller, Timothy J.
	Cc: pkix@ietf.org
	Subject: Re: [pkix] AuthKeyId and
CrlEntryExtension.CertificateIssuer
	
	X.509 is very clear.  It requires names to be unambiguous.
Where did
	you get the idea that X.509 was written with the understanding
that the
	trust anchor needs to be included when considering a DN?  Can
you point
	to any text (other than unsubstantiated assertions made by other
people
	on the mail list) to support this claim?
	
	On 01/23/2012 10:00 AM, Miller, Timothy J. wrote:

		Not across different PKIs, no.  Current software treats
Issuer+Serial 
		as a unique identifier; this is a security risk.  I can
(and have, in 
		the lab, for compatibility testing purposes, honest!)
created my own 
		CAs that collide names.
		
		Both X.509 and RFC 5280 are not clear on this point.
They were 
		written with the understanding that the trust anchor
needs to be 
		included when considering a DN, but this is a point
that's lost on 
		lots of implementations.  For example of this error, see
Figure 21 in

	

		"Windows Vista Smart Card Infrastructure" at:
		
		http://msdn.microsoft.com/en-us/library/bb905527.aspx
		
		
		
		Specifically, trace the thread for logon using the
Subject+Issuer 
		alternative mapping.
		
		-- T
		
		On 1/23/12 8:29 AM, "Santosh
Chokhani"<SChokhani@cygnacom.com> <mailto:SChokhani@cygnacom.com>
wrote:
		

			Are you saying that X.509 and RFC 5280 should
NOT assume that the DN 
			is unique?
			
			-----Original Message-----
			From: Miller, Timothy J.
[mailto:tmiller@mitre.org]
			Sent: Monday, January 23, 2012 9:21 AM
			To: Santosh Chokhani; Russ Housley; mrex@sap.com
			Cc: pkix@ietf.org
			Subject: Re: [pkix] AuthKeyId and
CrlEntryExtension.CertificateIssuer
			
			On 1/22/12 7:41 AM, "Santosh
Chokhani"<SChokhani@cygnacom.com> <mailto:SChokhani@cygnacom.com> 

	wrote:

			

				Per RFC 5280, Certificate Issuer  for
the CRL Entry Extension is a 
				GeneralNames, so no AKID is involved.
				
				Both X,500 and RFC 5280 assume that the
DN (name) and serial number 
				uniquely identify the certificate based
on the assumption that the 
				names are unique.

			This is probably something that needs to be
written out of the RFC.
			
			-- T

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



    

    

  


From david.cooper@nist.gov  Mon Jan 23 13:33:58 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CF121F8617 for ; Mon, 23 Jan 2012 13:33:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.106
X-Spam-Level: 
X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[AWL=0.493,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5AZblbZ675w for ; Mon, 23 Jan 2012 13:33:57 -0800 (PST)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 82CF221F857F for ; Mon, 23 Jan 2012 13:33:57 -0800 (PST)
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q0NLXluU009809; Mon, 23 Jan 2012 16:33:47 -0500
Message-ID: <4F1DD23B.1030203@nist.gov>
Date: Mon, 23 Jan 2012 16:33:47 -0500
From: "David A. Cooper" 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111227 Thunderbird/9.0.1
MIME-Version: 1.0
To: "mrex@sap.com" 
References: <201201232112.q0NLC5P6027885@fs4113.wdf.sap.corp>
In-Reply-To: <201201232112.q0NLC5P6027885@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 23 Jan 2012 21:33:58 -0000

On 01/23/2012 04:12 PM, Martin Rex wrote:
> David A. Cooper wrote:
>> Yes, it is very clear that you are confused. You apparently have an
>> incorrect model of the way that X.509 works and you are attempting to
>> interpret every X.509 says and everything I say in a way that is
>> consistent with your flawed model.
>>
>> At no point did I say that CA certs differ in public key that they are
>> also required to differ in subject DN.  What I said is that entities,
>> including CAs and CRL issuers, are identified by name only, not by the
>> key they use to sign things.
>>
>> Your understanding of CRL checking is incorrect, as you are
>> misinterpreting the meaning of "same issuer".  X.509 says that "CAs are
>> unambiguously defined by a distinguished name".  So, "same issuer" means
>> "same distinguished name".  It does not necessarily mean that they were
>> signed by the same key or that the same certificate may be used to
>> verify the signatures on both objects.
> If this would be true, this would entirely kill section 6.3 CRL checking
> out of rfc5280.

No it wouldn't.  See Section 6.3.3., step (f):

       (f)  Obtain and validate the certification path for the issuer of
            the complete CRL.  The trust anchor for the certification
            path MUST be the same as the trust anchor used to validate
            the target certificate.  If a key usage extension is present
            in the CRL issuer's certificate, verify that the cRLSign bit
            is set.

This is completely separate from step (b)(1):

       (b)  Verify the issuer and scope of the complete CRL as follows:

          (1)  If the DP includes cRLIssuer, then verify that the issuer
               field in the complete CRL matches cRLIssuer in the DP and
               that the complete CRL contains an issuing distribution
               point extension with the indirectCRL boolean asserted.
               Otherwise, verify that the CRL issuer matches the
               certificate issuer.

> When I'm doing certificate path validation, then all I have is the
> chain that I received from the peer.  If a CRL without indirect
> issuer does not verify with the exact same cert that verifies the
> signature on the cert, then I fail path validation.

Are we talking about X.509/RFC 5280 or your particular implementation of 
certification path validation?  This may be what your code does, but 
where is your support for the argument that this is what X.509/RFC 5280 
requires?

>
>> If I sign two documents, but sign one with my left hand and one with my
>> right hand, weren't both documents still signed by the same entity
>> (person)?  It's the same with X.509 and keys.  If a CA, which is
>> "unambiguously defined by a distinguished name", signs two objects, but
>> uses different keys to sign the two documents, both documents were still
>> signed by the same CA.
>
> The same entity that signed the certificate in my reading
> refers to the the exact same signer cert.

That may be your reading, but that is not what was meant and there is no 
text in X.509 or RFC 5280 to support that reading.

> There is no other
> trusted (verified) CA cert available at that point, anyway.

That is why step (f) says that you may have to "obtain and validate the 
certification path for issuer of the complete CRL."



From SChokhani@cygnacom.com  Mon Jan 23 13:49:49 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9E221F8674 for ; Mon, 23 Jan 2012 13:49:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level: 
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DVZMK-VX1+g for ; Mon, 23 Jan 2012 13:49:49 -0800 (PST)
Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 23B4721F8670 for ; Mon, 23 Jan 2012 13:49:49 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.71,557,1320642000";  d="scan'208";a="3840246"
Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 23 Jan 2012 16:49:46 -0500
Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 23 Jan 2012 16:49:46 -0500
From: Santosh Chokhani 
To: "pkix@ietf.org" 
Date: Mon, 23 Jan 2012 16:49:44 -0500
Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
Thread-Index: AczaFrxEc+4ywe5pQVy2/4rI6uzfFwAAZ/kw
Message-ID: 
References: <201201232112.q0NLC5P6027885@fs4113.wdf.sap.corp> <4F1DD23B.1030203@nist.gov>
In-Reply-To: <4F1DD23B.1030203@nist.gov>
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] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 23 Jan 2012 21:49:49 -0000

Folks,

I just wanted to say something broader here.

Folks like David Cooper, myself and Dave Kemp who have been around and have=
 wrestled with the issues, know the problems and various ways to fix them. =
 We do not always agree on which solution to use since using some of the so=
lutions imposes added requirements on relying parties.

Lot of questions Martin Rex and Tim Miller ask arise from lack of understan=
ding on how X.509 and 5280 work.

There are days I feel it is 1999 and then I say, I really need a new gig, r=
eally.......

From mrex@sap.com  Mon Jan 23 15:39:02 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0BA21F8681 for ; Mon, 23 Jan 2012 15:39:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.094
X-Spam-Level: 
X-Spam-Status: No, score=-10.094 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0USUxzfTtkf for ; Mon, 23 Jan 2012 15:39:02 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id AFBAB21F867B for ; Mon, 23 Jan 2012 15:39:01 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0NNcxLV006406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2012 00:39:00 +0100 (MET)
From: Martin Rex 
Message-Id: <201201232338.q0NNcxwK005853@fs4113.wdf.sap.corp>
To: david.cooper@nist.gov (David A. Cooper)
Date: Tue, 24 Jan 2012 00:38:59 +0100 (MET)
In-Reply-To: <4F1DD23B.1030203@nist.gov> from "David A. Cooper" at Jan 23, 12 04:33:47 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] AuthKeyId and CrlEntryExtension.CertificateIssuer
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, 23 Jan 2012 23:39:02 -0000

David A. Cooper wrote:
> 
> Martin Rex wrote:
> >
> > If this would be true, this would entirely kill section 6.3 CRL checking
> > out of rfc5280.
> 
> No it wouldn't.  See Section 6.3.3., step (f):
> 
>        (f)  Obtain and validate the certification path for the issuer of
>             the complete CRL.  The trust anchor for the certification
>             path MUST be the same as the trust anchor used to validate
>             the target certificate.  If a key usage extension is present
>             in the CRL issuer's certificate, verify that the cRLSign bit
>             is set.


Well, I'm not implementing a part of an X.500 or LDAP directory,
which the premise that I can securely(!) access the entire universe
of existing certificates.

I'm looking at an average RP, who keeps a small store of trust anchors,
and receives a certificate path from the communication peer, such
as in a TLS Certificate handshake message, and performs certificate
path validation on that path.  So that RPs universe is pretty small.

For such an environment, when performing certificate revocation checking
during certificate path validation for a direct CRL, that "obtain and
validate the certification path for the issuer of the complete CRL",
refers exactly to the validated subset of the certification path
that was input to 6.1.

When talking about conformance to rfc5280, this is about independent
interoperable implementations that can be built from this document
and those that are explicitly listed as prerequisites.  If something
is not specified or designed, it is not relevant for minimum
interoperability.

In case that you assume that those words in (f) might refer to some
fancy "certificate path discovery algorithm" that is completely
unrelated to the certification path that an RP is currently processing,
that would be a misunderstanding.

That could only be conceivable if such an algorithm was (a) spelled out
so that it can be independently implemented in an interoperable
fashion and (b) secure.  I don't see any other path described
in rfc5280 that is available to a generic RP other than the one
in 6.1 obtained from the communication peer.


-Martin

From peter.sylvester@edelweb.fr  Tue Jan 24 00:00:09 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BA411E8075 for ; Tue, 24 Jan 2012 00:00:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_28=0.6, J_CHICKENPOX_63=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V93xlP4wEfAA for ; Tue, 24 Jan 2012 00:00:08 -0800 (PST)
Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id BAF3D11E8074 for ; Tue, 24 Jan 2012 00:00:08 -0800 (PST)
Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 767177EBE for ; Tue, 24 Jan 2012 09:00:07 +0100 (CET)
Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 7FE89766EB0 for ; Tue, 24 Jan 2012 08:28:05 +0100 (CET)
Received: from [192.168.0.34] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTPSA id DF5AF236352 for ; Tue, 24 Jan 2012 02:59:34 -0500 (EST)
Message-ID: <4F1E6506.6060603@edelweb.fr>
Date: Tue, 24 Jan 2012 09:00:06 +0100
From: Peter Sylvester 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.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] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 24 Jan 2012 08:00:09 -0000

On 01/23/2012 08:53 PM, Miller, Timothy J. wrote:
> On 1/23/12 11:46 AM, "David A. Cooper"  wrote:
>
>> X.509 is very clear.  It requires names to be unambiguous.  Where did
>> you get the idea that X.509 was written with the understanding that the
>> trust anchor needs to be included when considering a DN?  Can you point
>> to any text (other than unsubstantiated assertions made by other people
>> on the mail list) to support this claim?
> If I give you the chain:
>
> CN=CooperCo Root CA,O=CooperCo,C=US
>    CN=CooperCo Issuing CA,O=CooperCo,C=US
>      CN=David.Cooper,O=CooperCo,C=US
>        serialNumber=0x0100
>
> And the chain:
>
> CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU=(c)
> 2006 VeriSign, Inc. - For authorized use only,OU=VeriSign Trust
> Network,O=Verisign, Inc.,C=US
>    CN=CooperCo Issuing CA,O=CooperCo,C=US
>      CN=David.Cooper,O=CooperCo,C=US
>        serialNumber=0x0100
>
> If I give you the pair:
>
> ("CN=CooperCo Issuing CA,O=CooperCo,C=US","serialNumber=0x0100")
>
>
> To which certificate does it refer?
this doest look like an  authority key  identifier.

you want to identify which of the possible two

CN=CooperCo Issuing CA,O=CooperCo,C=US

you want,  cn=verisign .. serial xxx  or   cn= root cooperca + serial=yyy






From bruce.stephens@isode.com  Tue Jan 24 03:03:57 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF4F21F8540 for ; Tue, 24 Jan 2012 03:03:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAILyoiG9P9d for ; Tue, 24 Jan 2012 03:03:57 -0800 (PST)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 060EA21F853D for ; Tue, 24 Jan 2012 03:03:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1327403035; d=isode.com; s=selector; i=@isode.com; bh=Fc8PeI/KLQ/J8+VmNUq3ECRlR+lWP2IdTPTW3UAkFFI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=MYSjjHHRjhaL/2y82h45oljCCk1RpwY/0MaejpOVYslHh7V00LZTmS3elZDiOXjoRb/hey w3Zojd4rc5V+ZzWWh0nfjSq2Gt6VuuqjikjcOEZlNk3J/BVV8fWFI9UJKuFRDXb28mEK3E 72ZIqmLNlMv6kJvNW67/CeoTAJTliBU=;
Received: from tinier.isode.net (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id  for ; Tue, 24 Jan 2012 11:03:54 +0000
Received: by tinier.isode.net (sSMTP sendmail emulation); Tue, 24 Jan 2012 11:03:54 +0000
From: Bruce Stephens 
To: pkix@ietf.org
References: <201201232338.q0NNcxwK005853@fs4113.wdf.sap.corp>
X-Hashcash: 1:20:120124:pkix@ietf.org::UY744XBI9jqgao7i:0000NvpC
Date: Tue, 24 Jan 2012 11:03:54 +0000
In-Reply-To: <201201232338.q0NNcxwK005853@fs4113.wdf.sap.corp> (Martin Rex's message of "Tue, 24 Jan 2012 00:38:59 +0100 (MET)")
Message-ID: <807h0huztx.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] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 24 Jan 2012 11:03:58 -0000

Martin Rex  writes:

[...]

> For such an environment, when performing certificate revocation checking
> during certificate path validation for a direct CRL, that "obtain and
> validate the certification path for the issuer of the complete CRL",
> refers exactly to the validated subset of the certification path
> that was input to 6.1.

Such an RP will presumably have to reject many valid paths, but that
may well be acceptable.

As an alternative (even without access to the Global Directory) an RP
could use extensions such as AIA and CRLDP to gather further
certificates and CRLs.

[...]


From tmiller@mitre.org  Tue Jan 24 05:08:57 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD4421F85C4 for ; Tue, 24 Jan 2012 05:08:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.399
X-Spam-Level: 
X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtF3pWAFVn1i for ; Tue, 24 Jan 2012 05:08:56 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1F78821F85C2 for ; Tue, 24 Jan 2012 05:08:54 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DEAF021B00C3; Tue, 24 Jan 2012 08:08:52 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C809721B0006; Tue, 24 Jan 2012 08:08:52 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.158]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Tue, 24 Jan 2012 08:08:52 -0500
From: "Miller, Timothy J." 
To: "David A. Cooper" 
Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
Thread-Index: AczZC5zBkYunh8ou0k2O3ixXfjBtFgAxkqcAAAJcydD///f6AIAAkt8A//+/CYCAAG4SgIAAszWA
Date: Tue, 24 Jan 2012 13:08:52 +0000
Message-ID: 
In-Reply-To: <4F1DC2AF.6050903@nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [172.31.58.79]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 24 Jan 2012 13:08:57 -0000

On 1/23/12 2:27 PM, "David A. Cooper"  wrote:

>While I can only guess at how to interpret your certificate chains, it
>appears that the CA "CN=3DCooperCo Issuing CA,O=3DCooperCo,C=3DUS" has iss=
ued
>a certificate to "CN=3DDavid.Cooper,O=3DCooperCo,C=3DUS" with serial numbe=
r
>0x0100, and that two different CAs ("CN=3DCooperCo Root
>CA,O=3DCooperCo,C=3DUS" and "CN=3DVeriSign Class 3 Public Primary
>Certification Authority - G5,OU=3D(c) 2006 VeriSign, Inc. - For authorized
>use only,OU=3DVeriSign Trust Network,O=3DVerisign, Inc.,C=3DUS") have issu=
ed
>certificates to "CN=3DCooperCo Issuing CA,O=3DCooperCo,C=3DUS".  I have no
>idea what you mean by "To which certificate does it refer?"

Exactly.  :)

>Are suggesting that "CN=3DCooperCo Root CA,O=3DCooperCo,C=3DUS" and
>"CN=3DVeriSign Class 3 Public Primary Certification Authority - G5,OU=3D(c=
)
>2006 VeriSign, Inc. - For authorized use only,OU=3DVeriSign Trust
>Network,O=3DVerisign, Inc.,C=3DUS" have actually issued certificates to tw=
o
>different CAs that both issue certificates under the name "CN=3DCooperCo
>Issuing CA,O=3DCooperCo,C=3DUS"?  If so, how does this in any way prove th=
at
>X.509 was  "written with the understanding that the trust anchor needs
>to be included when considering a DN"?  I can create a certificate that
>has a negative serial number, but that's not proof that RFC 5280 doesn't
>say "The serial number MUST be a positive integer assigned by the CA to
>each certificate."

The point is the idea that (Issuer DN, EE serial number) is an unambiguous
identifier is flawed.  (Issuer DN, EE serial number, trust anchor key
identifier) is the minimum set necessary for disambiguation.

While this should be obvious to anyone as deeply involved in PKI as most
of the participants on this list) it is *not* obvious to everyone else.
Any text or concepts in any of the PKIX work items that state or imply
that (Issuer DN, EE serial number) is an unambiguous identifier need to be
caveated or changed.

-- T




From SChokhani@cygnacom.com  Tue Jan 24 05:13:57 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA74E21F8516 for ; Tue, 24 Jan 2012 05:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level: 
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFMFlmJiY8GS for ; Tue, 24 Jan 2012 05:13:57 -0800 (PST)
Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id EDA8221F852B for ; Tue, 24 Jan 2012 05:13:56 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000";  d="scan'208";a="3846139"
Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 24 Jan 2012 08:13:56 -0500
Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 24 Jan 2012 08:13:56 -0500
From: Santosh Chokhani 
To: "Miller, Timothy J." , "David A. Cooper" 
Date: Tue, 24 Jan 2012 08:13:54 -0500
Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
Thread-Index: AczZC5zBkYunh8ou0k2O3ixXfjBtFgAxkqcAAAJcydD///f6AIAAkt8A//+/CYCAAG4SgIAAszWA///ukyA=
Message-ID: 
References: <4F1DC2AF.6050903@nist.gov> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 24 Jan 2012 13:13:57 -0000

In this world of cross certified PKI, Bridges and no name constraints due t=
o SSP, TA does not disambiguate DN.

Also, note that 5280 in security considerations did add the language that t=
he certificate and its CRL need to emanate from the same TA as a result of =
2004 Nov IETF meeting, but that only reduces the problem.

-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mil=
ler, Timothy J.
Sent: Tuesday, January 24, 2012 8:09 AM
To: David A. Cooper
Cc: pkix@ietf.org
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

On 1/23/12 2:27 PM, "David A. Cooper"  wrote:

>While I can only guess at how to interpret your certificate chains, it=20
>appears that the CA "CN=3DCooperCo Issuing CA,O=3DCooperCo,C=3DUS" has iss=
ued=20
>a certificate to "CN=3DDavid.Cooper,O=3DCooperCo,C=3DUS" with serial numbe=
r=20
>0x0100, and that two different CAs ("CN=3DCooperCo Root=20
>CA,O=3DCooperCo,C=3DUS" and "CN=3DVeriSign Class 3 Public Primary=20
>Certification Authority - G5,OU=3D(c) 2006 VeriSign, Inc. - For=20
>authorized use only,OU=3DVeriSign Trust Network,O=3DVerisign, Inc.,C=3DUS"=
)=20
>have issued certificates to "CN=3DCooperCo Issuing CA,O=3DCooperCo,C=3DUS"=
. =20
>I have no idea what you mean by "To which certificate does it refer?"

Exactly.  :)

>Are suggesting that "CN=3DCooperCo Root CA,O=3DCooperCo,C=3DUS" and=20
>"CN=3DVeriSign Class 3 Public Primary Certification Authority - G5,OU=3D(c=
)
>2006 VeriSign, Inc. - For authorized use only,OU=3DVeriSign Trust=20
>Network,O=3DVerisign, Inc.,C=3DUS" have actually issued certificates to tw=
o=20
>different CAs that both issue certificates under the name "CN=3DCooperCo=20
>Issuing CA,O=3DCooperCo,C=3DUS"?  If so, how does this in any way prove=20
>that
>X.509 was  "written with the understanding that the trust anchor needs=20
>to be included when considering a DN"?  I can create a certificate that=20
>has a negative serial number, but that's not proof that RFC 5280=20
>doesn't say "The serial number MUST be a positive integer assigned by=20
>the CA to each certificate."

The point is the idea that (Issuer DN, EE serial number) is an unambiguous =
identifier is flawed.  (Issuer DN, EE serial number, trust anchor key
identifier) is the minimum set necessary for disambiguation.

While this should be obvious to anyone as deeply involved in PKI as most of=
 the participants on this list) it is *not* obvious to everyone else.
Any text or concepts in any of the PKIX work items that state or imply that=
 (Issuer DN, EE serial number) is an unambiguous identifier need to be cave=
ated or changed.

-- T



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

From tmiller@mitre.org  Tue Jan 24 05:55:32 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AB921F8516 for ; Tue, 24 Jan 2012 05:55:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fanx2zznwDe8 for ; Tue, 24 Jan 2012 05:55:32 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 61E4621F84E2 for ; Tue, 24 Jan 2012 05:55:32 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CD95F21B043B; Tue, 24 Jan 2012 08:55:31 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A080321B17AC; Tue, 24 Jan 2012 08:55:31 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.158]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Tue, 24 Jan 2012 08:55:31 -0500
From: "Miller, Timothy J." 
To: Santosh Chokhani , "pkix@ietf.org" 
Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
Thread-Index: AQHM2hOokYunh8ou0k2O3ixXfjBtFpYazQuAgAAEdACAAKk7AA==
Date: Tue, 24 Jan 2012 13:55:30 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [172.31.57.198]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 24 Jan 2012 13:55:32 -0000

On 1/23/12 3:49 PM, "Santosh Chokhani"  wrote:

>I just wanted to say something broader here.
>
>Folks like David Cooper, myself and Dave Kemp who have been around and
>have wrestled with the issues, know the problems and various ways to fix
>them.  We do not always agree on which solution to use since using some
>of the solutions imposes added requirements on relying parties.
>
>Lot of questions Martin Rex and Tim Miller ask arise from lack of
>understanding on how X.509 and 5280 work.

That's more than a little unfair.  And if I *am* misunderstanding, I'm not
alone.  E.g., from RFC5652:

SignerIdentifier ::=3D CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }

This allows an attacker who can issue certs from *any* trust anchor in the
victim's trust store to spoof *any* identity.  Given that many PKIs are
private entities with no obligation to disclose fraud (or may be coerced
into issuing fraudulent certs by national governments), does this really
seem like a good idea to anyone?


-- T


From tmiller@mitre.org  Tue Jan 24 06:10:11 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DC121F855A for ; Tue, 24 Jan 2012 06:09:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.479
X-Spam-Level: 
X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBJLnFs5Xs4d for ; Tue, 24 Jan 2012 06:09:26 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC2821F8550 for ; Tue, 24 Jan 2012 06:09:26 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CF9A621B14D0; Tue, 24 Jan 2012 09:09:25 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 22BF621B0496; Tue, 24 Jan 2012 09:09:25 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.158]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Tue, 24 Jan 2012 09:09:25 -0500
From: "Miller, Timothy J." 
To: "Miller, Timothy J." , Santosh Chokhani , "pkix@ietf.org" 
Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
Thread-Index: AQHM2hOokYunh8ou0k2O3ixXfjBtFpYazQuAgAAEdACAAKk7AIAAA+AA
Date: Tue, 24 Jan 2012 14:09:24 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [172.31.57.198]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 24 Jan 2012 14:10:12 -0000

And another thing:=20

While it's true that 5280 doesn't make this error, I think 5280 promotes
this error.  It's fair to say that this isn't a PKIX problem, but IMHO
implementors rely on 5280 and if this is an error that occurs more than
once (it does) then I think this indicates something that 5280 can
improve.  If nothing else, a specific security note to the effect that
this kind of identifier is a *bad idea* would be warranted.

-- T

On 1/24/12 7:55 AM, "Miller, Timothy J."  wrote:

>On 1/23/12 3:49 PM, "Santosh Chokhani"  wrote:
>
>>I just wanted to say something broader here.
>>
>>Folks like David Cooper, myself and Dave Kemp who have been around and
>>have wrestled with the issues, know the problems and various ways to fix
>>them.  We do not always agree on which solution to use since using some
>>of the solutions imposes added requirements on relying parties.
>>
>>Lot of questions Martin Rex and Tim Miller ask arise from lack of
>>understanding on how X.509 and 5280 work.
>
>That's more than a little unfair.  And if I *am* misunderstanding, I'm not
>alone.  E.g., from RFC5652:
>
>SignerIdentifier ::=3D CHOICE {
>        issuerAndSerialNumber IssuerAndSerialNumber,
>        subjectKeyIdentifier [0] SubjectKeyIdentifier }
>
>This allows an attacker who can issue certs from *any* trust anchor in the
>victim's trust store to spoof *any* identity.  Given that many PKIs are
>private entities with no obligation to disclose fraud (or may be coerced
>into issuing fraudulent certs by national governments), does this really
>seem like a good idea to anyone?
>
>
>-- T
>
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix


From mrex@sap.com  Tue Jan 24 07:40:47 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED0E21F8597 for ; Tue, 24 Jan 2012 07:40:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.122
X-Spam-Level: 
X-Spam-Status: No, score=-10.122 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8E3e-oli87A for ; Tue, 24 Jan 2012 07:40:46 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 908D821F84D0 for ; Tue, 24 Jan 2012 07:40:46 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0OFeYLe001829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2012 16:40:39 +0100 (MET)
From: Martin Rex 
Message-Id: <201201241540.q0OFeYAh000184@fs4113.wdf.sap.corp>
To: bruce.stephens@isode.com (Bruce Stephens)
Date: Tue, 24 Jan 2012 16:40:34 +0100 (MET)
In-Reply-To: <807h0huztx.fsf@tinier.isode.net> from "Bruce Stephens" at Jan 24, 12 11:03:54 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] AuthKeyId and CrlEntryExtension.CertificateIssuer
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, 24 Jan 2012 15:40:47 -0000

After having checked various parts of rfc5280 and ITU-T X.509 and
slept over it, I believe to have found the relevant information
that caused my confusion.  So I'll try to clarify this myself.

I originally assumed that one possible reason for intermediate CA key
rollover would be that the CA's current CRL size has grown beyond
a reasonable size.  (I know US DOD CAs with CRLs of > 1 million entries
that I consider unreasonably sized).

During discussion with consultants of another vendor of PKI software
I was told that their product does not support rolling your own
intermediate CAs subject name when rolling its keypair, so based on
that description I assumed that X.509 would define partitioning of
CRLs based on AKIDs in order to allow restarting with an empty CRL
for the new intermediate CA keypair.

That is not the case.  X.509 does *NOT* allow partitioning of CRLs
based on AKIDs. (this would have required, among several other things,
CRLEntryExtension and CRL DP to include AKIDs).


So whenever a CA is operating with multiple CA certs with different
public keys, complexity goes up.  The CA will have to provide
a complete CRLs covering all CA certs with the same Subject Name,
and must distribute it in several variants, signed with each and
every one those CA certs and must configure the CRL DPs so that each
issued cert references the CRL DP with the CRLSigner cert matching
EXACTLY the certificate signer CA cert.


Bruce Stephens wrote:
> 
> Martin Rex  writes:
> >
> > For such an environment, when performing certificate revocation checking
> > during certificate path validation for a direct CRL, that "obtain and
> > validate the certification path for the issuer of the complete CRL",
> > refers exactly to the validated subset of the certification path
> > that was input to 6.1.
> 
> Such an RP will presumably have to reject many valid paths, but that
> may well be acceptable.

It is the most reasonable RP behaviour, essentially required by X.509 
and recommended by rfc5280 to request such a questionable path.

> 
> As an alternative (even without access to the Global Directory) an RP
> could use extensions such as AIA and CRLDP to gather further
> certificates and CRLs.

Using CRL DP is safe (because you look at it only after verifying
the signature to check for revocation), but it does not get you anywhere.

Using (URLs) from AIA on the other hand is folly because it is unsafe,
and no sensible implementation would be doing this as part of an RP
performing unattended certificate path validation.
Per X.509 it is a SHALL NOT, per rfc5280 it is a RECOMMENDED must not.


Quoting from rfc5280 Section 6.1 Basic Path Validation (3rd paragraph):

   http://tools.ietf.org/html/rfc5280#section-6.1

   While the certificate and CRL profiles specified in Sections 4 and 5
   of this document specify values for certificate and CRL fields and
   extensions that are considered to be appropriate for the Internet
   PKI, the algorithm presented in this section is not limited to
   accepting certificates and CRLs that conform to these profiles.
!! Therefore, the algorithm only includes checks to verify that the
!! certification path is valid according to X.509 and does not include
!! checks to verify that the certificates and CRLs conform to this
!! profile.  While the algorithm could be extended to include checks for
!! conformance to the profiles in Sections 4 and 5, this profile
!! RECOMMENDS against including such checks.


With this explicit caveat, it is conforming to rfc5280 to use instead the
algorithm specified in ITU-T X.509 for performing certificate path
validation and CRL checking.  And in several places, X.509 is significantly
clearer.


Quoting from ITU-T X.509

   B.1.2 CRL processing

                                             [...] The algorithm used
   by a particular implementation to derive the correct output
   (i.e., revocation status for a certificate) from the given inputs
   (the certificate itself and input from local policy) is not
   standardized. For example, although this procedure is described
   as a sequence of steps to be processed in order, an implementation
   may use CRLs which are in its local cache rather than retrieving
   CRLs each time it processes a certificate, provided those CRLs are
   complete for the scope of the certificate and do not violate any
   of the parameters of the certificate or policy.
 
   The following general steps are described in B.2 through B.5 below:
      1) Determine Parameters for CRLs;
      2) Determine CRLs Required;
      3) Obtain the CRLs;
      4) Process the CRLs.


   B.5.3 Validity and currency checks on the base CRL

   In order to verify that a base CRL is accurate and has not been
   modified since its issuance, all of the following conditions shall
   be satisfied:

     * The relying party shall be able to obtain the public key of the
       issuer identified in the CRL using authenticated means; and

     * The signature on the base CRL shall be verified using this
       authenticated public key; and+

     * If the nextUpdate field is present, the current time should be
       prior to the nextUpdate field; and

     * The issuer name in the CRL shall match the issuer name in the
       certificate that is being checked for revocation, unless the CRL
       is retrieved from the CRL DP in the certificate and the
       CRL DP extension contains the CRL issuer component. In that case,
       one of the names in CRL issuer component in the CRL DP extension
       shall match issuer name in the CRL.


X.509 (B.1.2 CRL) processing does not include any dowloading of other
CA certificates besides the certification path that an RP is
currently validating, and while it suggests caching of CRLs,
it does not suggest any caching of certs.

X.509 (B.5.3) first bullet is very explicit about what is and is
not sensible for obtaining the public key of the CRL issuer.

   * using locally available trusted information is OK, such as
      - trust anchors

   * using locally available certs is OK *AFTER* successful validation
     of these certs
      - locally cached certs
      - certs from a remote _trusted_ store
      - certs that have been conveyed in-band within the communication
        with the network peer, such as a peer certificate chain,


Only querying a trusted store for an AKID found in AIA can be implemented
with a managable risk, while attempting to download certs from arbitrary
untrusted resources specified in the AIA of a unverified certificate
is always a serious security problem and contrary to
"obtain ... using authenticated means".


An RP doing forward path discovery of AIA URLs would be vulnerable to
attackers abusing that facility to entice the peer into doing
stupid, dangerous or nasty stuff, including:

   - port/service-scanning on the peers local network
   - arbitrarily poking at the peers firewall&proxies from the inside
   - have the peer arbitrarily access statcounters
   - perform ad-click fraud
   - access kiddy-pr0n URLs,
     potentially earning you a visit from law enforcment
   - hang on tcp connect timeouts


Conclusion: The typical compliant RP, with no access to an online trusted
directory, will perform certificate path validation and CRL
checking based on the following information:

   - the certification path supplied by the communication peer
   - a set of preconfigured trust anchors
   - CRLs retrieved (and optionally cached) for CRL-DPs of certs
     that have been verified to chain to an existing trust anchor

And btw. since support for AKID is strictly optional (not required
for minimum compliant implementations of rfc5280), it is up to
the CAs and the more feature-rich implementations to ensure that
certification paths sent to peers can be validated by RPs
conforming to minimum requirements.


-Martin


From bruce.stephens@isode.com  Tue Jan 24 08:04:37 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5151C21F8629 for ; Tue, 24 Jan 2012 08:04:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFphGJ2L63Qv for ; Tue, 24 Jan 2012 08:04:36 -0800 (PST)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC8921F861D for ; Tue, 24 Jan 2012 08:04:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1327421074; d=isode.com; s=selector; i=@isode.com; bh=WozVgBL14MWD10VoHqBCMnwrU6KJTgucBLUBQpziDJU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=irZkZez//kFkJv1IgaPe9Xm30regmNGkSfLvItWH6l1uDrsfgg3UHx4tXAZTfiBOsXrvqj F/jb3/LkCJGbtbSsnBoLvXH3MdoeZhmmyS2c3rRC/Lq/+u1FLgLP6OumJBnaDEWOxHFlI5 7CdeGSNaeVrrFHLi1MPpCfqlkMYTTv0=;
Received: from tinier.isode.net (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id ; Tue, 24 Jan 2012 16:04:33 +0000
Received: by tinier.isode.net (sSMTP sendmail emulation); Tue, 24 Jan 2012 16:04:33 +0000
From: Bruce Stephens 
To: mrex@sap.com
References: <201201241540.q0OFeYAh000184@fs4113.wdf.sap.corp>
X-Hashcash: 1:20:120124:mrex@sap.com::ZyMClFFHZhcM0IdF:0000054ss
X-Hashcash: 1:20:120124:pkix@ietf.org::XT7jgFX2FTC5/8Ij:00005E1O
Date: Tue, 24 Jan 2012 16:04:33 +0000
In-Reply-To: <201201241540.q0OFeYAh000184@fs4113.wdf.sap.corp> (Martin Rex's message of "Tue, 24 Jan 2012 16:40:34 +0100 (MET)")
Message-ID: <80hazlkrxq.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
Cc: pkix@ietf.org
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 24 Jan 2012 16:04:37 -0000

Martin Rex  writes:

[...]

> X.509 (B.1.2 CRL) processing does not include any dowloading of other
> CA certificates besides the certification path that an RP is
> currently validating, and while it suggests caching of CRLs,
> it does not suggest any caching of certs.

Hmm. Then NIST.gov's Path Discovery Test Suite ought to be updated? For
example, test 4.1.2.11:

    4.1.2.11 Rudimentary LDAP Path Discovery Test11

    In this test, the end entity certificate is hierarchically
    subordinate to the trust anchor CA. The intermediate CA has used a
    different key to sign its CRL than the key used to sign the end
    entity certificate. The certificate issued by the Trust Anchor Root
    CA certifies the key needed to verify the end entity
    certificate. The self-issued certificate issued by the intermediate
    CA is signed by the key used to sign the end entity certificate and
    certifies the key needed to verify the CRL.

[...]

> An RP doing forward path discovery of AIA URLs would be vulnerable to
> attackers abusing that facility to entice the peer into doing
> stupid, dangerous or nasty stuff, including:
>
>    - port/service-scanning on the peers local network
>    - arbitrarily poking at the peers firewall&proxies from the inside
>    - have the peer arbitrarily access statcounters
>    - perform ad-click fraud
>    - access kiddy-pr0n URLs,
>      potentially earning you a visit from law enforcment
>    - hang on tcp connect timeouts

Yes, I guess that's all true. That suggests an update to RFC 4158 (I'm
not sure exactly what; some of the risks could presumably be mitigated
in various ways)?

> Conclusion: The typical compliant RP, with no access to an online trusted
> directory, will perform certificate path validation and CRL
> checking based on the following information:
>
>    - the certification path supplied by the communication peer
>    - a set of preconfigured trust anchors
>    - CRLs retrieved (and optionally cached) for CRL-DPs of certs
>      that have been verified to chain to an existing trust anchor

So the HTTP URI tests in NIST's PDTS ought to be removed and the LDAP
URI tests ignored?

In these tests you start just with trust anchors and the EE certificates
(and access to an LDAP directory) so there's no certification path
(which is rather the point).

[...]


From SChokhani@cygnacom.com  Tue Jan 24 08:48:35 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3FD21F863C for ; Tue, 24 Jan 2012 08:48:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level: 
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+ifoYF9H2LT for ; Tue, 24 Jan 2012 08:48:35 -0800 (PST)
Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 422FB21F863B for ; Tue, 24 Jan 2012 08:48:35 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.71,563,1320642000";  d="scan'208";a="3850559"
Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 24 Jan 2012 11:48:34 -0500
Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 24 Jan 2012 11:48:34 -0500
From: Santosh Chokhani 
To: "Miller, Timothy J." , "pkix@ietf.org" 
Date: Tue, 24 Jan 2012 11:48:33 -0500
Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
Thread-Index: AQHM2hOokYunh8ou0k2O3ixXfjBtFpYazQuAgAAEdACAAKk7AIAAKc3w
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
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 24 Jan 2012 16:48:36 -0000

Tim,

The AKID, SKID, AIA, CDO< and signer identifier etc. are efficiency mechani=
sms to mine the data.

An attacker can only use these to cause denial of service.

They do not identify anything except help you locate and/or disambiguate.

Section 6 of 5280 is the one that helps you establish trust in a public key=
 and these items play no role in validation of the public key.

-----Original Message-----
From: Miller, Timothy J. [mailto:tmiller@mitre.org]=20
Sent: Tuesday, January 24, 2012 8:56 AM
To: Santosh Chokhani; pkix@ietf.org
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

On 1/23/12 3:49 PM, "Santosh Chokhani"  wrote:

>I just wanted to say something broader here.
>
>Folks like David Cooper, myself and Dave Kemp who have been around and=20
>have wrestled with the issues, know the problems and various ways to=20
>fix them.  We do not always agree on which solution to use since using=20
>some of the solutions imposes added requirements on relying parties.
>
>Lot of questions Martin Rex and Tim Miller ask arise from lack of=20
>understanding on how X.509 and 5280 work.

That's more than a little unfair.  And if I *am* misunderstanding, I'm not =
alone.  E.g., from RFC5652:

SignerIdentifier ::=3D CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }

This allows an attacker who can issue certs from *any* trust anchor in the =
victim's trust store to spoof *any* identity.  Given that many PKIs are pri=
vate entities with no obligation to disclose fraud (or may be coerced into =
issuing fraudulent certs by national governments), does this really seem li=
ke a good idea to anyone?


-- T


From DPKemp@missi.ncsc.mil  Tue Jan 24 08:56:35 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED0311E8076 for ; Tue, 24 Jan 2012 08:56:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.399
X-Spam-Level: 
X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLhD70kpBWBq for ; Tue, 24 Jan 2012 08:56:34 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3F61821F85ED for ; Tue, 24 Jan 2012 08:56:31 -0800 (PST)
Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q0OGuUaB066531 for ; Tue, 24 Jan 2012 11:56:30 -0500 (EST)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 24 Jan 2012 11:57:31 -0500
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: Tue, 24 Jan 2012 11:49:31 -0500
Message-ID: 
In-Reply-To: <4F1DCEF2.2080404@nist.gov>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
Thread-Index: AczaFMQRi9P5MbScQK69n4dx92hgRgAn2F3g
References:  <4F1D9CD8.6050500@nist.gov>  <4F1DB860.3020804@nist.gov>  <4F1DCEF2.2080404@nist.gov>
From: "Kemp, David P." 
To: 
X-OriginalArrivalTime: 24 Jan 2012 16:57:31.0843 (UTC) FILETIME=[4337B130:01CCDAB9]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 24 Jan 2012 16:56:35 -0000

OK, I admit that it was poor judgment on my part to use a physical
analogy.  So amend that to the security analog of the Internet
Interoperability Principle:  Be strict in what you send means that the
Internet PKI must comply with the requirement that DNs be unique.  Be
safe in what you receive means that both senders and RPs should take
measures to limit damage when senders fail to comply.  That is
particularly important in the case where 1) it is possible for a
well-meaning sender to not comply in the absence of a global DN
registry, and 2) it is an obvious attack for an adversary to
deliberately not comply.

Because X.509 and 5280 do not clearly articulate the possibility that
DNs may not be unique due to error or maliciousness, I agree with you
that addressing the problem is an enhancement to the standards, not a
clarification of something that should already be understood by
developers.  What I do not agree with is any statement, if one was ever
made, that "there is an unambiguous requirement for DN uniqueness,
therefore it is safe to assume that DNs are always unique."

Dave K



-----Original Message-----
From: David A. Cooper [mailto:david.cooper@nist.gov]=20
Sent: Monday, January 23, 2012 4:20 PM
To: Kemp, David P.
Cc: pkix@ietf.org
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

David,

I suggest you read what people actually say before falsely accusing them
of making "circular and specious" arguments.  Timothy Miller did not
propose "to associate Issuer/Serial with a trust anchor".  He said:

On 01/23/2012 10:00 AM, Miller, Timothy J. wrote:=20

	Both X.509 and RFC 5280 are not clear on this point.  They were
written
	with the understanding that the trust anchor needs to be
included when
	considering a DN, but this is a point that's lost on lots of
	implementations.


There is a major difference between prosing something and stating that
the standard was "written with the understanding that...."

I asked for evidence to support his assertion that "[X.509 and RFC 5280]
were written with the understanding that the trust anchor needs to be
included when considering a DN".

The fact that you are referring to this as a "proposal" and an
"enhancement" only demonstrates that you agree with me. =20

On 01/23/2012 03:57 PM, Kemp, David P. wrote:=20

	An argument that X.509 cannot ensure uniqueness of DNs (in the
absence
	of a Directory or global DN registry) is, as you say, an
argument
	against X.509.
=09
	The proposal to associate Issuer/Serial with a trust anchor
addresses
	that argument against X.509 with a mechanism that guarantees
global
	uniqueness as long as each trust anchor ensures local
uniqueness, and
	confines any collisions within a single trust anchor to its
local scope.
=09
	The requirement exists.  And it is circular and specious to
argue that
	the enhancement is unnecessary "because X.509 requires DNs to be
	globally unique".  That's like arguing there's no need to
install street
	lights because there's already a regulation for streets to be
adequately
	lit.


No, this would be someone claiming that the lights on a certain street
don't meet the regulations, and then me arguing that the street does
meet the regulations since the regulations only require one street light
every 100m and the street has one street light every 90m, and then you
falsely accusing me of having said that the street was adequately lit,
even though I never suggested that the regulations were adequate.



From SChokhani@cygnacom.com  Tue Jan 24 08:59:45 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA0921F8616 for ; Tue, 24 Jan 2012 08:59:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Level: 
X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPRDASREnNv5 for ; Tue, 24 Jan 2012 08:59:44 -0800 (PST)
Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8AC21F8615 for ; Tue, 24 Jan 2012 08:59:44 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.71,563,1320642000";  d="scan'208";a="3850759"
Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 24 Jan 2012 11:59:43 -0500
Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 24 Jan 2012 11:59:43 -0500
From: Santosh Chokhani 
To: "mrex@sap.com" , Bruce Stephens 
Date: Tue, 24 Jan 2012 11:59:42 -0500
Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
Thread-Index: Aczaro02+WmgtRcvR+a88Y+rFCndyQACcsPw
Message-ID: 
References: <807h0huztx.fsf@tinier.isode.net> from "Bruce Stephens" at Jan 24,	12 11:03:54 am <201201241540.q0OFeYAh000184@fs4113.wdf.sap.corp>
In-Reply-To: <201201241540.q0OFeYAh000184@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: "pkix@ietf.org" 
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 24 Jan 2012 16:59:45 -0000

You misunderstand partitioning of CRL.

A CA can use any process (stochastic or deterministic) to partition CRLs an=
d use IDP in the CRL appropriately.

If a CA wishes to partition CRL based on CA signing keys, it can do so by a=
sserting proper DP in CDP in the certificates and proper DP in IDP in the C=
RL.

-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mar=
tin Rex
Sent: Tuesday, January 24, 2012 10:41 AM
To: Bruce Stephens
Cc: pkix@ietf.org
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

After having checked various parts of rfc5280 and ITU-T X.509 and slept ove=
r it, I believe to have found the relevant information that caused my confu=
sion.  So I'll try to clarify this myself.

I originally assumed that one possible reason for intermediate CA key rollo=
ver would be that the CA's current CRL size has grown beyond a reasonable s=
ize.  (I know US DOD CAs with CRLs of > 1 million entries that I consider u=
nreasonably sized).

During discussion with consultants of another vendor of PKI software I was =
told that their product does not support rolling your own intermediate CAs =
subject name when rolling its keypair, so based on that description I assum=
ed that X.509 would define partitioning of CRLs based on AKIDs in order to =
allow restarting with an empty CRL for the new intermediate CA keypair.

That is not the case.  X.509 does *NOT* allow partitioning of CRLs based on=
 AKIDs. (this would have required, among several other things, CRLEntryExte=
nsion and CRL DP to include AKIDs).


So whenever a CA is operating with multiple CA certs with different public =
keys, complexity goes up.  The CA will have to provide a complete CRLs cove=
ring all CA certs with the same Subject Name, and must distribute it in sev=
eral variants, signed with each and every one those CA certs and must confi=
gure the CRL DPs so that each issued cert references the CRL DP with the CR=
LSigner cert matching EXACTLY the certificate signer CA cert.


Bruce Stephens wrote:
>=20
> Martin Rex  writes:
> >
> > For such an environment, when performing certificate revocation=20
> > checking during certificate path validation for a direct CRL, that=20
> > "obtain and validate the certification path for the issuer of the=20
> > complete CRL", refers exactly to the validated subset of the=20
> > certification path that was input to 6.1.
>=20
> Such an RP will presumably have to reject many valid paths, but that=20
> may well be acceptable.

It is the most reasonable RP behaviour, essentially required by X.509 and r=
ecommended by rfc5280 to request such a questionable path.

>=20
> As an alternative (even without access to the Global Directory) an RP=20
> could use extensions such as AIA and CRLDP to gather further=20
> certificates and CRLs.

Using CRL DP is safe (because you look at it only after verifying the signa=
ture to check for revocation), but it does not get you anywhere.

Using (URLs) from AIA on the other hand is folly because it is unsafe, and =
no sensible implementation would be doing this as part of an RP performing =
unattended certificate path validation.
Per X.509 it is a SHALL NOT, per rfc5280 it is a RECOMMENDED must not.


Quoting from rfc5280 Section 6.1 Basic Path Validation (3rd paragraph):

   http://tools.ietf.org/html/rfc5280#section-6.1

   While the certificate and CRL profiles specified in Sections 4 and 5
   of this document specify values for certificate and CRL fields and
   extensions that are considered to be appropriate for the Internet
   PKI, the algorithm presented in this section is not limited to
   accepting certificates and CRLs that conform to these profiles.
!! Therefore, the algorithm only includes checks to verify that the !! cert=
ification path is valid according to X.509 and does not include !! checks t=
o verify that the certificates and CRLs conform to this !! profile.  While =
the algorithm could be extended to include checks for !! conformance to the=
 profiles in Sections 4 and 5, this profile !! RECOMMENDS against including=
 such checks.


With this explicit caveat, it is conforming to rfc5280 to use instead the a=
lgorithm specified in ITU-T X.509 for performing certificate path validatio=
n and CRL checking.  And in several places, X.509 is significantly clearer.


Quoting from ITU-T X.509

   B.1.2 CRL processing

                                             [...] The algorithm used
   by a particular implementation to derive the correct output
   (i.e., revocation status for a certificate) from the given inputs
   (the certificate itself and input from local policy) is not
   standardized. For example, although this procedure is described
   as a sequence of steps to be processed in order, an implementation
   may use CRLs which are in its local cache rather than retrieving
   CRLs each time it processes a certificate, provided those CRLs are
   complete for the scope of the certificate and do not violate any
   of the parameters of the certificate or policy.
=20
   The following general steps are described in B.2 through B.5 below:
      1) Determine Parameters for CRLs;
      2) Determine CRLs Required;
      3) Obtain the CRLs;
      4) Process the CRLs.


   B.5.3 Validity and currency checks on the base CRL

   In order to verify that a base CRL is accurate and has not been
   modified since its issuance, all of the following conditions shall
   be satisfied:

     * The relying party shall be able to obtain the public key of the
       issuer identified in the CRL using authenticated means; and

     * The signature on the base CRL shall be verified using this
       authenticated public key; and+

     * If the nextUpdate field is present, the current time should be
       prior to the nextUpdate field; and

     * The issuer name in the CRL shall match the issuer name in the
       certificate that is being checked for revocation, unless the CRL
       is retrieved from the CRL DP in the certificate and the
       CRL DP extension contains the CRL issuer component. In that case,
       one of the names in CRL issuer component in the CRL DP extension
       shall match issuer name in the CRL.


X.509 (B.1.2 CRL) processing does not include any dowloading of other CA ce=
rtificates besides the certification path that an RP is currently validatin=
g, and while it suggests caching of CRLs, it does not suggest any caching o=
f certs.

X.509 (B.5.3) first bullet is very explicit about what is and is not sensib=
le for obtaining the public key of the CRL issuer.

   * using locally available trusted information is OK, such as
      - trust anchors

   * using locally available certs is OK *AFTER* successful validation
     of these certs
      - locally cached certs
      - certs from a remote _trusted_ store
      - certs that have been conveyed in-band within the communication
        with the network peer, such as a peer certificate chain,


Only querying a trusted store for an AKID found in AIA can be implemented w=
ith a managable risk, while attempting to download certs from arbitrary unt=
rusted resources specified in the AIA of a unverified certificate is always=
 a serious security problem and contrary to "obtain ... using authenticated=
 means".


An RP doing forward path discovery of AIA URLs would be vulnerable to attac=
kers abusing that facility to entice the peer into doing stupid, dangerous =
or nasty stuff, including:

   - port/service-scanning on the peers local network
   - arbitrarily poking at the peers firewall&proxies from the inside
   - have the peer arbitrarily access statcounters
   - perform ad-click fraud
   - access kiddy-pr0n URLs,
     potentially earning you a visit from law enforcment
   - hang on tcp connect timeouts


Conclusion: The typical compliant RP, with no access to an online trusted d=
irectory, will perform certificate path validation and CRL checking based o=
n the following information:

   - the certification path supplied by the communication peer
   - a set of preconfigured trust anchors
   - CRLs retrieved (and optionally cached) for CRL-DPs of certs
     that have been verified to chain to an existing trust anchor

And btw. since support for AKID is strictly optional (not required for mini=
mum compliant implementations of rfc5280), it is up to the CAs and the more=
 feature-rich implementations to ensure that certification paths sent to pe=
ers can be validated by RPs conforming to minimum requirements.


-Martin

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

From anders.rundgren@telia.com  Tue Jan 24 09:59:47 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7621721F865A for ; Tue, 24 Jan 2012 09:59:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.37
X-Spam-Level: 
X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=-0.929,  BAYES_20=-0.74, MANGLED_ONLINE=2.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+2TFOs61-xv for ; Tue, 24 Jan 2012 09:59:46 -0800 (PST)
Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 5694821F864D for ; Tue, 24 Jan 2012 09:59:46 -0800 (PST)
Received: from [192.168.0.203] (81.232.141.73) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4EFC380E0069AA81; Tue, 24 Jan 2012 18:59:42 +0100
Message-ID: <4F1EF188.8030709@telia.com>
Date: Tue, 24 Jan 2012 18:59:36 +0100
From: Anders Rundgren 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Max Pritikin 
References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com>  <4F1484F4.6020202@telia.com>  <4F18A4B6.3060701@telia.com> <07123142-C9D7-493F-8681-548096731043@cisco.com>
In-Reply-To: <07123142-C9D7-493F-8681-548096731043@cisco.com>
X-Enigmail-Version: 1.3.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-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: Tue, 24 Jan 2012 17:59:47 -0000

Max et al,

Please read the following as "constructive criticism" because that is
what the intent was at least.

On 2012-01-23 18:14, Max Pritikin wrote:

>> The bank I mentioned where thinking about how bank cards are used
>> (at least outside of the USA...), i.e. with a PIN.  They felt that on-
>> line-enrolled credentials should follow this time-proven pattern as well.
>>
>> Anyway, deploying a PIN to a key is quite different from authenticating
>> to a CA with PIN.
> 
> "[D]eploying a PIN to a key" does sound vaguely like something that 
> might occur during enrollment.

Vague or not, several billions of chip-cards (EMV, PIV, SIM) have already
passed through PIN deployment/enrollment processes.  Now we are facing a
situation where cards are becoming "virtual" which calls for new enrollment
solutions that also work in the field.


> Would it be fair to characterize this 
> as a request/assertion from the CA that the client MUST encrypt/protect
> the private key using a PIN to ensure authorized access? Or is this
> actual deployment of the PIN where the CA has a hand in choosing an
> appropriate PIN value (according to some CA policy)?

My only reason for bringing this up was for improving the scoping:
EST is a fine protocol but it doesn't address the "bank use-case".

Since not even Microsoft have bothered with the "bank use-case" this
probably isn't particularly relevant for PKIX either, or is it?

That Google and I have come to another conclusion is because we indeed
(but in profoundly different ways...), target the financial sector.


> Or do you mean that during the "actual usage of the enrolled certificate" 
> the use of a PIN is proven by some subsequent protocol enhancements 
> (e.g. some extension to TLS or something).

EMV, PIV, SIM, and the Google wallet all rely on *local* PINs so I
would consider this as the primary scope for "PINs deployed to keys".


>>  I may be dumb but I don't see how PIN deployment could
>> be squeezed into EST without more or less starting over from scratch.
> 
> One possible way to see if this idea could be squeezed into an 
> existing document would be for you to suggest exact document text.
> Or, alternatively, to provide a new draft that specifically addresses
> your concern.

As already mentioned, I have no idea of how you could add this to EST.

Although probably of no interest to PKIX, I consider SM (known as
Secure Messaging by the smart card community), as a more extensible
concept than wrapping CMS-based data in TLS, at least in a context
where you want to perform *multiple and intimately related operations*
possibly including user interactions, while still keeping the
"footprint" of the cryptographic module reasonable.

SM is also the common denominator between the Google wallet and
my SKS/KeyGen2 scheme.  Everything else differ :-) :-)



> That way you can provide the exact normative text that meets 
> your concern and, in the process of writing it all down using
> normative language sufficient for implementors to understand,
> will also generate sufficiently detailed text that I might
> follow your thoughts as well.

Well, as you know, I don't believe the PKIX approach to enrollment
represents the way ahead for an on-line world where credentials are
delivered directly to moderately tech- or security-savvy end-users.

This is [currently] rather Apple's and Google's hunting grounds
which also makes it extremely hard succeeding without having a
very good solution as well as a matching strategy for adoption.

If you take the number of groups (platform, browser, protocol,
middleware, smart cards, etc.), needed to create a functioning
system, you pretty soon realize that this simply isn't going to
happen the traditional (preferred?) way.

Due to this, I have spent considerable energy and time on developing
an on-line scheme that as far as is possible "emulates" off-line
enrolled and physically distributed smart cards.  In this work I
used GlobalPlatform as *one* source of "inspiration".

Unlike most other folks I had no ambition to be compatible with
existing standards because that would create an almost infinitely
complex interoperability matrix.  Going for the second-best,
"profiling" the 500p+ GP, ISO-7816, and ETSI standards also
didn't look like a realistic project, so I early on decided
defining the whole caboodle from scratch.  The latter shouldn't
be interpreted as "all new" but rather as selective "borrowing".

It is possible that I in that process have violated considerable
amounts of IPR but I only see this as a way getting more attention :-)

BTW, I wouldn't consider casting my "colorful" and (IMO) rather
nice SKS/KeyGen2 architecture and API document into an RFC-format.
None of our (mutual?) competitors do that either.

Regards,
Anders

http://webpki.org/papers/keygen2/sks-api-arch.pdf

From mrex@sap.com  Tue Jan 24 10:26:40 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFE011E80AB for ; Tue, 24 Jan 2012 10:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.126
X-Spam-Level: 
X-Spam-Status: No, score=-10.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOBrGjGkydtP for ; Tue, 24 Jan 2012 10:26:39 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7C92311E809D for ; Tue, 24 Jan 2012 10:26:39 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0OIQZkU024382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2012 19:26:35 +0100 (MET)
From: Martin Rex 
Message-Id: <201201241826.q0OIQYTH009949@fs4113.wdf.sap.corp>
To: SChokhani@cygnacom.com (Santosh Chokhani)
Date: Tue, 24 Jan 2012 19:26:34 +0100 (MET)
In-Reply-To:  from "Santosh Chokhani" at Jan 24, 12 11:59: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] AuthKeyId and CrlEntryExtension.CertificateIssuer
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, 24 Jan 2012 18:26:40 -0000

Santosh Chokhani wrote:
> 
> You misunderstand partitioning of CRL.
> 
> A CA can use any process (stochastic or deterministic) to
> partition CRLs and use IDP in the CRL appropriately.
> 
> If a CA wishes to partition CRL based on CA signing keys, it can do so by
> asserting proper DP in CDP in the certificates and proper DP in IDP
> in the CRL.

This works *ONLY* by using distinct issuer DNames, in which case we
are talking about different issuers, even when they're operated by the
exact same entity and differ only by e.g. a SerialNumber RDName.

The rules defined by X.509 for processing CRLs will not protect you from
accepting one partial CRL instead of another partial CRL for the exact
same issuer name that do not differ by reason code.


If you try to use operational tricks in an attempt to protect
against exploitation of protocol features for which the underlying
architecture design does not provide any protection, then you are
often going miss some scenarios and loose.  


It is much better to stay within the design limits of the base specification
and rely on the features that can reasonably be expected to be available
(the minimum interoperable set).

-Martin

From SChokhani@cygnacom.com  Tue Jan 24 10:43:54 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD9711E809A for ; Tue, 24 Jan 2012 10:43:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level: 
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-Ul3XYvFiVV for ; Tue, 24 Jan 2012 10:43:54 -0800 (PST)
Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id D745C11E8098 for ; Tue, 24 Jan 2012 10:43:53 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.71,563,1320642000";  d="scan'208";a="3852582"
Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 24 Jan 2012 13:43:53 -0500
Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 24 Jan 2012 13:43:53 -0500
From: Santosh Chokhani 
To: "mrex@sap.com" 
Date: Tue, 24 Jan 2012 13:43:52 -0500
Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
Thread-Index: AczaxbYDjfTo6Oa/SuawqeTaf02opAAAKeFw
Message-ID: 
References:  from "Santosh Chokhani" at Jan 24, 12 11:59:42 am <201201241826.q0OIQYTH009949@fs4113.wdf.sap.corp>
In-Reply-To: <201201241826.q0OIQYTH009949@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: "pkix@ietf.org" 
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 24 Jan 2012 18:43:54 -0000

Martin,

Your understanding remains in error.  You need to read and understand the C=
RL processing rules annex (which is normative) in X.509.

The CA DN remains unchanged.

The relying party matches the DP in CRL DP and the DP in IDP to ensure that=
 it has the correct partition.

May be you are not understanding the approach or are thinking that the CRL =
DP must match the CA DN, which is not the case.

Basically it works as follows.  Let us say that the CA DN is X and the CA h=
as n keys and decides to partition based on keys.  It uses DP Y1, Y2, Y3...=
 Yn.

When key j is used, the DP in corresponding CRL DP in that certificate is Y=
j and DP in IDP in CRL for key j partition is Yj.

When the relying party gets the CRL with critical IDP, and sees Yj in DP, i=
t ensures that the corresponding certificate has Yj in DP in CRL DP.  Note =
that both the objects are signed by the CA.

BTW, partitioned CRL is secure and very powerful; powerful in the sense tha=
t the CA can change its approach to partitioning unbeknownst to the relying=
 parties since the only stipulation the relying party needs to verify to en=
sure that it got the correct CRL is matching two signed objects from the CA=
: DP in CRL DP in the certificate and DP in IDP in CRL.

Feel free to tell us where the security issue is.  We have analyzed this si=
nce 1995 and documented it in X.509 and fail to see security problem/

-----Original Message-----
From: Martin Rex [mailto:mrex@sap.com]=20
Sent: Tuesday, January 24, 2012 1:27 PM
To: Santosh Chokhani
Cc: mrex@sap.com; bruce.stephens@isode.com; pkix@ietf.org
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

Santosh Chokhani wrote:
>=20
> You misunderstand partitioning of CRL.
>=20
> A CA can use any process (stochastic or deterministic) to partition=20
> CRLs and use IDP in the CRL appropriately.
>=20
> If a CA wishes to partition CRL based on CA signing keys, it can do so=20
> by asserting proper DP in CDP in the certificates and proper DP in IDP=20
> in the CRL.

This works *ONLY* by using distinct issuer DNames, in which case we are tal=
king about different issuers, even when they're operated by the exact same =
entity and differ only by e.g. a SerialNumber RDName.

The rules defined by X.509 for processing CRLs will not protect you from ac=
cepting one partial CRL instead of another partial CRL for the exact same i=
ssuer name that do not differ by reason code.


If you try to use operational tricks in an attempt to protect against explo=
itation of protocol features for which the underlying architecture design d=
oes not provide any protection, then you are often going miss some scenario=
s and loose. =20


It is much better to stay within the design limits of the base specificatio=
n and rely on the features that can reasonably be expected to be available =
(the minimum interoperable set).

-Martin

From mrex@sap.com  Tue Jan 24 11:30:09 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC15E11E8072 for ; Tue, 24 Jan 2012 11:30:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.132
X-Spam-Level: 
X-Spam-Status: No, score=-10.132 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYF+uwaJeCot for ; Tue, 24 Jan 2012 11:30:08 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id BBDB011E80A5 for ; Tue, 24 Jan 2012 11:30:03 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0OJTxuf001768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2012 20:29:59 +0100 (MET)
From: Martin Rex 
Message-Id: <201201241929.q0OJTwvC013415@fs4113.wdf.sap.corp>
To: SChokhani@cygnacom.com (Santosh Chokhani)
Date: Tue, 24 Jan 2012 20:29:58 +0100 (MET)
In-Reply-To:  from "Santosh Chokhani" at Jan 24, 12 01:43:52 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] AuthKeyId and CrlEntryExtension.CertificateIssuer
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, 24 Jan 2012 19:30:09 -0000

Santosh Chokhani wrote:
> 
> Your understanding remains in error.  You need to read and understand the CRL processing rules annex (which is normative) in X.509.
> 
> The CA DN remains unchanged.
> 
> The relying party matches the DP in CRL DP and the DP in IDP to ensure that it has the correct partition.
> 
> May be you are not understanding the approach or are thinking that the CRL DP must match the CA DN, which is not the case.
> 
> Basically it works as follows.  Let us say that the CA DN is X and the CA has n keys and decides to partition based on keys.  It uses DP Y1, Y2, Y3... Yn.
> 
> When key j is used, the DP in corresponding CRL DP in that certificate is Yj and DP in IDP in CRL for key j partition is Yj.
> 
> When the relying party gets the CRL with critical IDP, and sees Yj in DP, it ensures that the corresponding certificate has Yj in DP in CRL DP.  Note that both the objects are signed by the CA.
> 
> BTW, partitioned CRL is secure and very powerful; powerful in the sense that the CA can change its approach to partitioning unbeknownst to the relying parties since the only stipulation the relying party needs to verify to ensure that it got the correct CRL is matching two signed objects from the CA: DP in CRL DP in the certificate and DP in IDP in CRL.
> 
> Feel free to tell us where the security issue is.  We have analyzed this
> since 1995 and documented it in X.509 and fail to see security problem/


Your scheme appears to rely on the CRL DP of the cert always being compared
to the CRL DP on the CRL.  Tough luck--the CRL DP in the CRL is optional,
so you will have to expect some RPs to implement an efficient CRL caching
(completely unwrapped) where the CRL DP on the CRL is completely ignored
for the actual revocation lookup.


-Martin

From SChokhani@cygnacom.com  Tue Jan 24 11:40:49 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA93121F8533 for ; Tue, 24 Jan 2012 11:40:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level: 
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRYiMTHsLGoL for ; Tue, 24 Jan 2012 11:40:49 -0800 (PST)
Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1035121F8532 for ; Tue, 24 Jan 2012 11:40:48 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.71,563,1320642000";  d="scan'208";a="3853582"
Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 24 Jan 2012 14:40:44 -0500
Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 24 Jan 2012 14:40:44 -0500
From: Santosh Chokhani 
To: "mrex@sap.com" 
Date: Tue, 24 Jan 2012 14:40:44 -0500
Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
Thread-Index: AczazpDtrN7ypIyETimzakq/Fyjd6AAAByRw
Message-ID: 
References:  from "Santosh Chokhani" at Jan 24, 12 01:43:52 pm <201201241929.q0OJTwvC013415@fs4113.wdf.sap.corp>
In-Reply-To: <201201241929.q0OJTwvC013415@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: "pkix@ietf.org" 
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 24 Jan 2012 19:40:49 -0000

Originally, CRL DP was designed to partition the CRL.  If CRL DP is not inc=
luded in a certificate, that certificate cannot go in a partition.

When you ignore a critical IDP extension in CRL, you are insecure.  So, the=
 relying party has a choice when IDP is present in the CRL (IDP is always a=
 critical extension) to either understand and process it or reject the CRL.

Most PKE clients I know such as CAPI, PKIF and NSS do not have problem hand=
ling this,

-----Original Message-----
From: Martin Rex [mailto:mrex@sap.com]=20
Sent: Tuesday, January 24, 2012 2:30 PM
To: Santosh Chokhani
Cc: mrex@sap.com; bruce.stephens@isode.com; pkix@ietf.org
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

Santosh Chokhani wrote:
>=20
> Your understanding remains in error.  You need to read and understand the=
 CRL processing rules annex (which is normative) in X.509.
>=20
> The CA DN remains unchanged.
>=20
> The relying party matches the DP in CRL DP and the DP in IDP to ensure th=
at it has the correct partition.
>=20
> May be you are not understanding the approach or are thinking that the CR=
L DP must match the CA DN, which is not the case.
>=20
> Basically it works as follows.  Let us say that the CA DN is X and the CA=
 has n keys and decides to partition based on keys.  It uses DP Y1, Y2, Y3.=
.. Yn.
>=20
> When key j is used, the DP in corresponding CRL DP in that certificate is=
 Yj and DP in IDP in CRL for key j partition is Yj.
>=20
> When the relying party gets the CRL with critical IDP, and sees Yj in DP,=
 it ensures that the corresponding certificate has Yj in DP in CRL DP.  Not=
e that both the objects are signed by the CA.
>=20
> BTW, partitioned CRL is secure and very powerful; powerful in the sense t=
hat the CA can change its approach to partitioning unbeknownst to the relyi=
ng parties since the only stipulation the relying party needs to verify to =
ensure that it got the correct CRL is matching two signed objects from the =
CA: DP in CRL DP in the certificate and DP in IDP in CRL.
>=20
> Feel free to tell us where the security issue is.  We have analyzed=20
> this since 1995 and documented it in X.509 and fail to see security=20
> problem/


Your scheme appears to rely on the CRL DP of the cert always being compared=
 to the CRL DP on the CRL.  Tough luck--the CRL DP in the CRL is optional, =
so you will have to expect some RPs to implement an efficient CRL caching (=
completely unwrapped) where the CRL DP on the CRL is completely ignored for=
 the actual revocation lookup.


-Martin

From mrex@sap.com  Tue Jan 24 12:38:40 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4330121F8570 for ; Tue, 24 Jan 2012 12:38:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.134
X-Spam-Level: 
X-Spam-Status: No, score=-10.134 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSn1YMwv8MBN for ; Tue, 24 Jan 2012 12:38:39 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id CCB7521F8584 for ; Tue, 24 Jan 2012 12:38:38 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0OKcTu5004261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2012 21:38:29 +0100 (MET)
From: Martin Rex 
Message-Id: <201201242038.q0OKcSdU017054@fs4113.wdf.sap.corp>
To: SChokhani@cygnacom.com (Santosh Chokhani)
Date: Tue, 24 Jan 2012 21:38:28 +0100 (MET)
In-Reply-To:  from "Santosh Chokhani" at Jan 24, 12 02:40:44 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] AuthKeyId and CrlEntryExtension.CertificateIssuer
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, 24 Jan 2012 20:38:40 -0000

Santosh Chokhani wrote:
> 
> Originally, CRL DP was designed to partition the CRL.
> If CRL DP is not included in a certificate, that certificate
> cannot go in a partition.
> 
> When you ignore a critical IDP extension in CRL, you are insecure.

Actually, I believe your envisioned PKI setup is insecure because
it is outside of the design limits of X.509.

If someone fubars his PKI so badly, so that there is no
CRL DP with full scope listed in his certs, or that the CRL
returned from that URL is unusable for the promised purpose,
then for our RP the customer will have to manually configure a download
URL for that issuerName so that our CRL cache can populated/updated
out-of-band with conforming CRLs ... or disable revocation checking
for that issuerName.

Quoting from the last paragraph of rfc5280 section 5

    http://tools.ietf.org/html/rfc5280#page-55

                                            Conforming applications
   that support CRLs are REQUIRED to process both version 1 and version
   2 complete CRLs that provide revocation information for all
   certificates issued by one CA.  Conforming applications are not
   required to support processing of delta CRLs, indirect CRLs, or CRLs
   with a scope other than all certificates issued by one CA.


The obvious and straightforward approach to partitioning CRLs
by CA certs is to create CA certs that differ in the issuerName e.g.
by adding a SerialNumber RDName component.  That will work
reliably with every RP that supports CRLs.

Telling apart intermediate CA DNames during troubleshooting is
magnitudes harder when they do not differ in name (especially
when error messages only quote the supposedly unique issuerNames).

And you get fresh empty CRLs for free whenever you roll your CA cert.


-Martin

From eabalea@gmail.com  Tue Jan 24 13:33:18 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0063521F852E for ; Tue, 24 Jan 2012 13:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yU9UkvhOLaD1 for ; Tue, 24 Jan 2012 13:33:17 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD2421F8523 for ; Tue, 24 Jan 2012 13:33:17 -0800 (PST)
Received: by yhnn12 with SMTP id n12so2243553yhn.31 for ; Tue, 24 Jan 2012 13:33:16 -0800 (PST)
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=h3Km7gZ1gdMnHNbrKmIFpuHE3Ls2QwFLepFr0traGsE=; b=d5u9C1FDlXVG2KGav0iywzf4Dobyd/3M/K4zmetgke+L/z+CbC1e+Iv3joBcqCqQQf tDvbIdgiHxqJJ19lR8TWvHK0lFtZt9ZIJB/0LVorIIYGCvNxXmafDaF+wCpaq9mm33ti 1JQWr+P3dKw3ieXXEHcmoxPed9IJA0aOtw4Is=
MIME-Version: 1.0
Received: by 10.236.139.132 with SMTP id c4mr20824512yhj.68.1327440796855; Tue, 24 Jan 2012 13:33:16 -0800 (PST)
Received: by 10.236.109.143 with HTTP; Tue, 24 Jan 2012 13:33:16 -0800 (PST)
Received: by 10.236.109.143 with HTTP; Tue, 24 Jan 2012 13:33:16 -0800 (PST)
In-Reply-To: <201201242038.q0OKcSdU017054@fs4113.wdf.sap.corp>
References:  <201201242038.q0OKcSdU017054@fs4113.wdf.sap.corp>
Date: Tue, 24 Jan 2012 22:33:16 +0100
Message-ID: 
From: Erwann Abalea 
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=20cf303e9e10282de304b74ce53c
Cc: pkix@ietf.org
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 24 Jan 2012 21:33:18 -0000

--20cf303e9e10282de304b74ce53c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le 24 janv. 2012 21:38, "Martin Rex"  a =C3=A9crit :
>
> Santosh Chokhani wrote:
> >
> > Originally, CRL DP was designed to partition the CRL.
> > If CRL DP is not included in a certificate, that certificate
> > cannot go in a partition.
> >
> > When you ignore a critical IDP extension in CRL, you are insecure.

This point is important.
If you ignore a *critical* extension, then you fail. Completely. You're
free to ignore any non critical extension (at least in X.509, not RFC5280),
but if you encounter a critical extension that you don't understand, you
MUST reject the object.

> If someone fubars his PKI so badly, so that there is no
> CRL DP with full scope listed in his certs, or that the CRL
> returned from that URL is unusable for the promised purpose,
> then for our RP the customer will have to manually configure a download
> URL for that issuerName so that our CRL cache can populated/updated
> out-of-band with conforming CRLs ... or disable revocation checking
> for that issuerName.

Would you trust such a CA?

--=20
Erwann.

--20cf303e9e10282de304b74ce53c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




Le 24 janv. 2012 21:38, "Martin Rex" <mrex@sap.com> a =C3=A9crit=C2=A0:

>

> Santosh Chokhani wrote:

> >

> > Originally, CRL DP was designed to partition the CRL.

> > If CRL DP is not included in a certificate, that certificate

> > cannot go in a partition.

> >

> > When you ignore a critical IDP extension in CRL, you are insecure=
.


This point is important.

If you ignore a *critical* extension, then you fail. Completely. You're=
 free to ignore any non critical extension (at least in X.509, not RFC5280)=
, but if you encounter a critical extension that you don't understand, =
you MUST reject the object. 



> If someone fubars his PKI so badly, so that there is no

> CRL DP with full scope listed in his certs, or that the CRL

> returned from that URL is unusable for the promised purpose,

> then for our RP the customer will have to manually configure a downloa=
d

> URL for that issuerName so that our CRL cache can populated/updated
> out-of-band with conforming CRLs ... or disable revocation checking
> for that issuerName.


Would you trust such a CA?


-- 

Erwann.


--20cf303e9e10282de304b74ce53c--

From simon@josefsson.org  Fri Jan 27 05:45:16 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4061721F852B; Fri, 27 Jan 2012 05:45:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.909
X-Spam-Level: 
X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnMqK5Gv-Ftq; Fri, 27 Jan 2012 05:45:15 -0800 (PST)
Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3658921F8528; Fri, 27 Jan 2012 05:45:14 -0800 (PST)
Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q0RDj7g7004287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Jan 2012 14:45:08 +0100
X-Hashcash: 1:22:120127:apps-discuss@ietf.org::03twXgSwdKYllJqr:0++R
X-Hashcash: 1:22:120127:pkix@ietf.org::FGnwcqrqSzNh/F4b:tSN1
From: Simon Josefsson 
To: apps-discuss@ietf.org, pkix@ietf.org
References: <20120127133401.25242.24253.idtracker@ietfa.amsl.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Mail-Followup-To: apps-discuss@ietf.org
X-Hashcash: 1:22:120127:i-d-announce@ietf.org::Dy0Hw68nYXEkYC4i:4+ST
X-Hashcash: 1:22:120127:internet-drafts@ietf.org::XvgflzkHMI0cmCUS:DXqv
Date: Fri, 27 Jan 2012 14:45:06 +0100
In-Reply-To: <20120127133401.25242.24253.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Fri, 27 Jan 2012 05:34:01 -0800")
Message-ID: <877h0dcl99.fsf@latte.josefsson.org>
User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v
X-Virus-Status: Clean
Subject: [pkix] PKIX text encodings
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 27 Jan 2012 13:45:16 -0000

Folks,

See announcement below for a document that attempts to describe the
de-facto deployed usage of so called "PEM encoding" of X.509 related
data blobs, including the '-----BEGIN CERTIFICATE-----' format.  Many
applications and security libraries rely on these formats, but to my
knowledge they have never been standardized and there is unfortunately
some confusion and ambiguity as a result.

https://tools.ietf.org/html/draft-josefsson-pkix-textual

As usual, comments and suggestions are appreciated.  I'm not certain
what fora is best for discussing the document, but I suspect the apps
area group may be an appropriate venue, thus I'm adding an appropriate
Mail-Followup-To header.  If anyone believes discussion is inappropriate
there, I'm happy to move the discussion elsewhere.

If someone remembers the history around how the format was created,
anecdotal or otherwise, that would also be helpful.

Thanks,
Simon

internet-drafts@ietf.org writes:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : Text Encodings of Some Security Related Structures
> 	Author(s)       : Simon Josefsson
> 	Filename        : draft-josefsson-pkix-textual-00.txt
> 	Pages           : 10
> 	Date            : 2012-01-27
>
>    This document describe and discuss the text encodings of Public-Key
>    Infrastructure using X.509 (PKIX) Certificates, PKIX Certificate
>    Revocation Lists (CRLs), PKCS #10 Certificate Request Syntax, PKCS #7
>    structures, and Attribute Certificates.  The text encodings are well-
>    known, implemented by several applications and libraries, and is
>    widely deployed.  This document is intended to articulate the de-
>    facto rules that existing implementations operate by, and to give
>    recommendations that will promote interoperability going forward.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-pkix-textual-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-josefsson-pkix-textual-00.txt

From mrex@sap.com  Fri Jan 27 10:11:25 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBFD21F866E; Fri, 27 Jan 2012 10:11:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.943
X-Spam-Level: 
X-Spam-Status: No, score=-8.943 tagged_above=-999 required=5 tests=[AWL=-1.108, BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTlwWshBA1mC; Fri, 27 Jan 2012 10:11:24 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CC6A621F8655; Fri, 27 Jan 2012 10:11:23 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0RIB65p020677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Jan 2012 19:11:06 +0100 (MET)
From: Martin Rex 
Message-Id: <201201271811.q0RIB5Wu012578@fs4113.wdf.sap.corp>
To: simon@josefsson.org (Simon Josefsson)
Date: Fri, 27 Jan 2012 19:11:05 +0100 (MET)
In-Reply-To: <877h0dcl99.fsf@latte.josefsson.org> from "Simon Josefsson" at Jan 27, 12 02:45:06 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: pkix@ietf.org, apps-discuss@ietf.org
Subject: Re: [pkix] PKIX text encodings
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, 27 Jan 2012 18:11:25 -0000

Simon,

Simon Josefsson wrote:
> 
> See announcement below for a document that attempts to describe the
> de-facto deployed usage of so called "PEM encoding" of X.509 related
> data blobs, including the '-----BEGIN CERTIFICATE-----' format.  Many
> applications and security libraries rely on these formats, but to my
> knowledge they have never been standardized and there is unfortunately
> some confusion and ambiguity as a result.
> 
> https://tools.ietf.org/html/draft-josefsson-pkix-textual
 
the Label that is used within '-----BEGIN ----'
should be ignored on the receiver side, and all implemented formats
should be tried, that are applicable for the requested operation.

Normally, these PEM-framed base64 encodings are used for administrative
interfaces used by humans that are used with a low frequency,
rather for authentication exchanges that are used with a high
frequency. For administrative user interfaces it is usually sensible to
spend a few extra CPU cycles to improve the usability.

Strongly recommeding standardized labelling on output of these formats
is OK, and may facilitate troubleshooting.

But on input, e.g. when processing a certification response, the
administrative interface should IMO be tolerant to accept a single
certificate (provided the remaining certs required to build a
complete path are already present), accept a sequence of several
certificates, or a PKCS#7 container carry multiple certificates,
independent of what labels are used with BEGIN/END.

When the administrative interface has access to the PKI credentials
for which a certification response is to be processed, then it
can detect the end-entity cert automatically, compose the full
and correctly ordererd certificate chain automatically, and ignore
any superfluous/unrelated certs that may have been part of the input.


Btw. PKCS#7 can also be used as a carry bag for multiple CRLs,
which can be used to allow revocation checking in offline
scenarios or on isolated networks.

-Martin

From paul.hoffman@vpnc.org  Fri Jan 27 10:20:50 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B2421F867D; Fri, 27 Jan 2012 10:20:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.553
X-Spam-Level: 
X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrlyerkvEQfu; Fri, 27 Jan 2012 10:20:45 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 09AE621F8647; Fri, 27 Jan 2012 10:20:45 -0800 (PST)
Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0RIKhO7054128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Jan 2012 11:20:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman 
In-Reply-To: <201201271811.q0RIB5Wu012578@fs4113.wdf.sap.corp>
Date: Fri, 27 Jan 2012 10:20:42 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <028B4903-E2C7-41BA-9C9A-B416A41C4E8F@vpnc.org>
References: <201201271811.q0RIB5Wu012578@fs4113.wdf.sap.corp>
To: Simon Josefsson 
X-Mailer: Apple Mail (2.1251.1)
Cc: PKIX , "apps-discuss@ietf.org Discuss" 
Subject: Re: [pkix] PKIX text encodings
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 27 Jan 2012 18:20:50 -0000

On Jan 27, 2012, at 10:11 AM, Martin Rex wrote:

> the Label that is used within '-----BEGIN ----'
> should be ignored on the receiver side, and all implemented formats
> should be tried, that are applicable for the requested operation.

This would cause things like private keys and public keys to be mixed =
up. I propose this is not a good idea from a security perspective. =
Instead, Simon might add some text saying that some applications =
sometimes ignore the label in order to be more liberal, but in doing so =
can cause problems with systems that assume those labels are important.

>=20
> Normally, these PEM-framed base64 encodings are used for =
administrative
> interfaces used by humans that are used with a low frequency,
> rather for authentication exchanges that are used with a high
> frequency. For administrative user interfaces it is usually sensible =
to
> spend a few extra CPU cycles to improve the usability.
>=20
> Strongly recommeding standardized labelling on output of these formats
> is OK, and may facilitate troubleshooting.
>=20
> But on input, e.g. when processing a certification response, the
> administrative interface should IMO be tolerant to accept a single
> certificate (provided the remaining certs required to build a
> complete path are already present), accept a sequence of several
> certificates, or a PKCS#7 container carry multiple certificates,
> independent of what labels are used with BEGIN/END.

These are all separate issues, but definitely worthy of discussion in =
the document. "Some systems will accept multiple certificates in a =
single text block, while others will reject the entire text block as =
malformed if more than one certificate is included."

> When the administrative interface has access to the PKI credentials
> for which a certification response is to be processed, then it
> can detect the end-entity cert automatically, compose the full
> and correctly ordererd certificate chain automatically, and ignore
> any superfluous/unrelated certs that may have been part of the input.
>=20
>=20
> Btw. PKCS#7 can also be used as a carry bag for multiple CRLs,
> which can be used to allow revocation checking in offline
> scenarios or on isolated networks.


Indeed.

Just a thought: we define *new* labels that do what we think everyone =
should do, such as multiple items in the block. There would not be much =
uptake on those new labels in the short run, but could become the =
standard 20 years from now.

--Paul Hoffman


From pritikin@cisco.com  Fri Jan 27 13:05:49 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9D021F867C for ; Fri, 27 Jan 2012 13:05:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.024
X-Spam-Level: 
X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.575,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xkV286uIXkR for ; Fri, 27 Jan 2012 13:05:48 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 657E021F856F for ; Fri, 27 Jan 2012 13:05:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=5818; q=dns/txt; s=iport; t=1327698348; x=1328907948; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8mTvk0cM7JLjzprYmXk7wW1c7aZCZM0A4UMb5rXXlhY=; b=XwxuLhk34FM1cRl283Awc7Df20ifRzeILP0TreSzK38mlbpof5b+Pjfy 69D8DGwusOHs9bt0bUHJBlDgKBXdSBsJwlhycXSQa2OauYPD/B4dCxbuo gsm5wHUVGIuGGMijfcgw2XIj1+VuXKf1dgS7bdRb8sTe7+AwRAH18wJK9 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EABsRI0+rRDoI/2dsb2JhbAAuFq5UgQWBcgEBAQIBARIBZgULCxIGExtJDgYnBweHWgiZWQGePIhfMAYEDg4QAQgBBgQDAwQHgw4aAg4CBn0DCIJ5YwSIP4xbkm0
X-IronPort-AV: E=Sophos;i="4.71,582,1320624000"; d="scan'208";a="27328216"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 27 Jan 2012 21:05:48 +0000
Received: from sjc-vpn1-477.cisco.com (sjc-vpn1-477.cisco.com [10.21.97.221]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0RL5lCF005213; Fri, 27 Jan 2012 21:05:47 GMT
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Max Pritikin 
In-Reply-To: <4F1EF188.8030709@telia.com>
Date: Fri, 27 Jan 2012 14:05:47 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com>  <4F1484F4.6020202@telia.com>  <4F18A4B6.3060701@telia.com> <07123142-C9D7-493F-8681-548096731043@cisco.com> <4F1EF188.8030709@telia.com>
To: Anders Rundgren 
X-Mailer: Apple Mail (2.1251.1)
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-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: Fri, 27 Jan 2012 21:05:49 -0000

Inlines,

On Jan 24, 2012, at 10:59 AM, Anders Rundgren wrote:

> Max et al,
>=20
> Please read the following as "constructive criticism" because that is
> what the intent was at least.
>=20
> On 2012-01-23 18:14, Max Pritikin wrote:
> 
>>> The bank I mentioned where thinking about how bank cards are used
>>> (at least outside of the USA...), i.e. with a PIN.  They felt that =
on-
>>> line-enrolled credentials should follow this time-proven pattern as =
well.
>>>=20
>>> Anyway, deploying a PIN to a key is quite different from =
authenticating
>>> to a CA with PIN.
>>=20
>> "[D]eploying a PIN to a key" does sound vaguely like something that=20=

>> might occur during enrollment.
>=20
> Vague or not, several billions of chip-cards (EMV, PIV, SIM) have =
already
> passed through PIN deployment/enrollment processes.  Now we are facing =
a
> situation where cards are becoming "virtual" which calls for new =
enrollment
> solutions that also work in the field.
>=20
>=20
>> Would it be fair to characterize this=20
>> as a request/assertion from the CA that the client MUST =
encrypt/protect
>> the private key using a PIN to ensure authorized access? Or is this
>> actual deployment of the PIN where the CA has a hand in choosing an
>> appropriate PIN value (according to some CA policy)?
>=20
> My only reason for bringing this up was for improving the scoping:
> EST is a fine protocol but it doesn't address the "bank use-case".
>=20
> Since not even Microsoft have bothered with the "bank use-case" this
> probably isn't particularly relevant for PKIX either, or is it?
>=20
> That Google and I have come to another conclusion is because we indeed
> (but in profoundly different ways...), target the financial sector.
>=20
>=20
>> Or do you mean that during the "actual usage of the enrolled =
certificate"=20
>> the use of a PIN is proven by some subsequent protocol enhancements=20=

>> (e.g. some extension to TLS or something).
>=20
> EMV, PIV, SIM, and the Google wallet all rely on *local* PINs so I
> would consider this as the primary scope for "PINs deployed to keys".
>=20
>=20
>>> I may be dumb but I don't see how PIN deployment could
>>> be squeezed into EST without more or less starting over from =
scratch.
>>=20
>> One possible way to see if this idea could be squeezed into an=20
>> existing document would be for you to suggest exact document text.
>> Or, alternatively, to provide a new draft that specifically addresses
>> your concern.
>=20
> As already mentioned, I have no idea of how you could add this to EST.

Perhaps you could respond to the exchange between Russ and myself and =
clarify what you mean by "deploy a PIN to a key". Are you asking for the =
PIN deployment to be part of the protocol operation or not?

> Although probably of no interest to PKIX, I consider SM (known as
> Secure Messaging by the smart card community), as a more extensible
> concept than wrapping CMS-based data in TLS, at least in a context
> where you want to perform *multiple and intimately related operations*
> possibly including user interactions, while still keeping the
> "footprint" of the cryptographic module reasonable.
>=20
> SM is also the common denominator between the Google wallet and
> my SKS/KeyGen2 scheme.  Everything else differ :-) :-)

You should be well positioned to answer the questions then or to provide =
text explaining your thoughts.=20

>> That way you can provide the exact normative text that meets=20
>> your concern and, in the process of writing it all down using
>> normative language sufficient for implementors to understand,
>> will also generate sufficiently detailed text that I might
>> follow your thoughts as well.
>=20
> Well, as you know, I don't believe the PKIX approach to enrollment
> represents the way ahead for an on-line world where credentials are
> delivered directly to moderately tech- or security-savvy end-users.
>=20
> This is [currently] rather Apple's and Google's hunting grounds
> which also makes it extremely hard succeeding without having a
> very good solution as well as a matching strategy for adoption.
>=20
> If you take the number of groups (platform, browser, protocol,
> middleware, smart cards, etc.), needed to create a functioning
> system, you pretty soon realize that this simply isn't going to
> happen the traditional (preferred?) way.
>=20
> Due to this, I have spent considerable energy and time on developing
> an on-line scheme that as far as is possible "emulates" off-line
> enrolled and physically distributed smart cards.  In this work I
> used GlobalPlatform as *one* source of "inspiration".
>=20
> Unlike most other folks I had no ambition to be compatible with
> existing standards because that would create an almost infinitely
> complex interoperability matrix.  Going for the second-best,
> "profiling" the 500p+ GP, ISO-7816, and ETSI standards also
> didn't look like a realistic project, so I early on decided
> defining the whole caboodle from scratch.  The latter shouldn't
> be interpreted as "all new" but rather as selective "borrowing".
>=20
> It is possible that I in that process have violated considerable
> amounts of IPR but I only see this as a way getting more attention :-)
>=20
> BTW, I wouldn't consider casting my "colorful" and (IMO) rather
> nice SKS/KeyGen2 architecture and API document into an RFC-format.
> None of our (mutual?) competitors do that either.

If you're not willing, or unable, to extract the core ideas from the =
colorful formatting then we're going to have a hard time communicating =
over email about RFC text.

- max
=20
>=20
> Regards,
> Anders
>=20
> http://webpki.org/papers/keygen2/sks-api-arch.pdf


From pritikin@cisco.com  Fri Jan 27 13:05:50 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C6621F86CA for ; Fri, 27 Jan 2012 13:05:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.216
X-Spam-Level: 
X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1ttzRVjVFyr for ; Fri, 27 Jan 2012 13:05:50 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 10C3F21F856F for ; Fri, 27 Jan 2012 13:05:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=1983; q=dns/txt; s=iport; t=1327698349; x=1328907949; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oT2KA5KzXc90w1cgzC9PRPH2aCvk4KOehChJwQq687Q=; b=ZIuStRLm1W4VOUrWZYp5TLCbSYuOKnCps9/KZn8rew4z0pbSHSfjC3f/ JPqutDBYow16mxn4Zz3uN8+iRkWdi8h4mP+SoyQePfFt48+Vg5o3M7E2a xP7RKc/yKoJoKj/FMFhr5gkatehBCTISlQJtoqrsbG5D3estkbIwhsMDe s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAIwQI0+rRDoI/2dsb2JhbAAuFq5UgQWBcgEBAQMBEgEnPwULCysFFlcGNYdamWABnjyIXzAHAwoDCwQQAQgBBgQDAwQHGwOCcBoCDgIGfQMIHwkagjdjBIg/jFuSbQ
X-IronPort-AV: E=Sophos;i="4.71,582,1320624000"; d="scan'208";a="25815769"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 27 Jan 2012 21:05:49 +0000
Received: from sjc-vpn1-477.cisco.com (sjc-vpn1-477.cisco.com [10.21.97.221]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0RL5lCG005213; Fri, 27 Jan 2012 21:05:49 GMT
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Max Pritikin 
In-Reply-To: <8E4D80C3-1BFC-4A3C-977B-9D5D828C3D2A@vigilsec.com>
Date: Fri, 27 Jan 2012 14:05:49 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BDA4869-A40C-4DDC-997A-D7CE67E8DCF0@cisco.com>
References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com>  <4F1484F4.6020202@telia.com>  <4F18A4B6.3060701@telia.com> <07123142-C9D7-493F-8681-548096731043@cisco.com> <8E4D80C3-1BFC-4A3C-977B-9D5D828C3D2A@vigilsec.com>
To: Russ Housley 
X-Mailer: Apple Mail (2.1251.1)
Cc: IETF PKIX 
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-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: Fri, 27 Jan 2012 21:05:50 -0000

Russ,=20

I'm having some trouble parsing your sentence but I think you and I =
agree about this use: A PIN/password/passphrase is given by the RA to a =
person at the completion of some out-of-protocol "proofing", and this is =
used in a one-time fashion during the enrollment process as proof of =
prior proofing.=20

I thought that Anders has a different vision based on his discussion of =
"deploying a PIN to a key" which is why I asked for clarification from =
him. In his response he didn't answer the question. I'll work from yours =
and mines shared understanding.

- max

On Jan 23, 2012, at 1:11 PM, Russ Housley wrote:

> Max:
>=20
>>> The bank I mentioned where thinking about how bank cards are used
>>> (at least outside of the USA...), i.e. with a PIN.  They felt that =
on-
>>> line-enrolled credentials should follow this time-proven pattern as =
well.
>>>=20
>>> Anyway, deploying a PIN to a key is quite different from =
authenticating
>>> to a CA with PIN.
>>=20
>> "[D]eploying a PIN to a key" does sound vaguely like something that =
might occur during enrollment. Would it be fair to characterize this as =
a request/assertion from the CA that the client MUST encrypt/protect the =
private key using a PIN to ensure authorized access? Or is this actual =
deployment of the PIN where the CA has a hand in choosing an appropriate =
PIN value (according to some CA policy)?=20
>>=20
>> Or do you mean that during the "actual usage of the enrolled =
certificate" the use of a PIN is proven by some subsequent protocol =
enhancements (e.g. some extension to TLS or something).
>=20
> I think it is the other way round.  A PIN / password / passphrase is =
given  by the RA want a person completes face-to-face proofing, and this =
is used in a one-time fashion during the enrollment process as proof =
that that proofing has taken place with the party that is presenting the =
certificate request.
>=20
> Russ
>=20


From mrex@sap.com  Fri Jan 27 16:37:48 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DA521F850F; Fri, 27 Jan 2012 16:37:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.131
X-Spam-Level: 
X-Spam-Status: No, score=-10.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjJjNP1dXi2m; Fri, 27 Jan 2012 16:37:48 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A759421F84C9; Fri, 27 Jan 2012 16:37:47 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0S0bkw5004367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 Jan 2012 01:37:46 +0100 (MET)
From: Martin Rex 
Message-Id: <201201280037.q0S0bjqe004577@fs4113.wdf.sap.corp>
To: paul.hoffman@vpnc.org (Paul Hoffman)
Date: Sat, 28 Jan 2012 01:37:45 +0100 (MET)
In-Reply-To: <028B4903-E2C7-41BA-9C9A-B416A41C4E8F@vpnc.org> from "Paul Hoffman" at Jan 27, 12 10:20:42 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: simon@josefsson.org, apps-discuss@ietf.org, pkix@ietf.org
Subject: Re: [pkix] PKIX text encodings
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, 28 Jan 2012 00:37:48 -0000

Paul Hoffman wrote:
> 
> Martin Rex wrote:
> >
> > the Label that is used within '-----BEGIN ----'
> > should be ignored on the receiver side, and all implemented formats
> > should be tried, that are applicable for the requested operation.
> 
> This would cause things like private keys and public keys to be mixed up.

Not necessarily.  If your ASN.1 decoder can not distinguish your private
from your public key, then you have a whole different kind of problem.


>
> I propose this is not a good idea from a security perspective.

Huh?  That textual label is not integrity protected in any way,
so how should this be a security problem?

This is really only about convenience for admins.


>
> Instead, Simon might add some text saying that some applications
> sometimes ignore the label in order to be more liberal, but in doing
> so can cause problems with systems that assume those labels are important.

HUH?  How could being liberal on *INPUT* possibly cause problems?

Any reasonable ASN.1 decoder can reliably tell apart
  - X.509 certificates
  - private keys
  - encrypted private keys
  - pkcs10 requests
  - crls
  - pkcs7/cms 
  - pkcs7/cms as certificate bag
  - pkcs7/cms as crl bag
  - pkcs12

So any implementation that is ignoring the explicit label, will have to
use the implicit label from successfuly ASN.1 decode of the types
of objects that are applicable for the requested operation.


Microsoft seems to ignore the label.  If you double-click on
a pkcs7 file (extension .p7s or .p7b) it will be PEM-decoded independent
of what label is used.  Same for certificate (.cer).


I find it much more confusing when only a few, but non-unique labels
are accepted:
OpenSSL seems to accept certs with "X509 CERTIFICATE" and "CERTIFICATE"
and PKCS7 as "PKCS7" or "CERTIFICATE" but _not_ "X509 CERTIFICATE"


> 
> Just a thought: we define *new* labels that do what we think everyone
> should do, such as multiple items in the block. There would not be much
> uptake on those new labels in the short run, but could become the
> standard 20 years from now.

For OUTPUT we should try to find an reuse the most commonly used label,
because the installed base is going to be with us another 10+ years.


-Martin

From paul.hoffman@vpnc.org  Fri Jan 27 20:29:30 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BC621F8508; Fri, 27 Jan 2012 20:29:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.554
X-Spam-Level: 
X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a--o+5S0Gyju; Fri, 27 Jan 2012 20:29:30 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA4A21F84FF; Fri, 27 Jan 2012 20:29:30 -0800 (PST)
Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0S4TRt7084777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Jan 2012 21:29:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Paul Hoffman 
In-Reply-To: <201201280037.q0S0bjqe004577@fs4113.wdf.sap.corp>
Date: Fri, 27 Jan 2012 20:29:27 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A5293F6-83A7-48CB-BAA6-FF85F0D6A903@vpnc.org>
References: <201201280037.q0S0bjqe004577@fs4113.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.1251.1)
Cc: simon@josefsson.org, apps-discuss@ietf.org, pkix@ietf.org
Subject: Re: [pkix] PKIX text encodings
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 28 Jan 2012 04:29:30 -0000

On Jan 27, 2012, at 4:37 PM, Martin Rex wrote:

> Paul Hoffman wrote:
>>=20
>> Martin Rex wrote:
>>>=20
>>> the Label that is used within '-----BEGIN ----'
>>> should be ignored on the receiver side, and all implemented formats
>>> should be tried, that are applicable for the requested operation.
>>=20
>> This would cause things like private keys and public keys to be mixed =
up.
>=20
> Not necessarily.  If your ASN.1 decoder can not distinguish your =
private
> from your public key, then you have a whole different kind of problem.

Indeed, but it is a new problem that you probably didn't plan for. There =
is no need to introduce the problem at this late date.

>> I propose this is not a good idea from a security perspective.
>=20
> Huh?  That textual label is not integrity protected in any way,
> so how should this be a security problem?

These blobs are often handed around out-of-band, so removing a bit of =
information can indeed introduce a security problem.

> This is really only about convenience for admins.

That's one view, but not the only one.

>> Instead, Simon might add some text saying that some applications
>> sometimes ignore the label in order to be more liberal, but in doing
>> so can cause problems with systems that assume those labels are =
important.
>=20
> HUH?  How could being liberal on *INPUT* possibly cause problems?
>=20
> Any reasonable ASN.1 decoder can reliably tell apart
>  - X.509 certificates
>  - private keys
>  - encrypted private keys
>  - pkcs10 requests
>  - crls
>  - pkcs7/cms=20
>  - pkcs7/cms as certificate bag
>  - pkcs7/cms as crl bag
>  - pkcs12
>=20
> So any implementation that is ignoring the explicit label, will have =
to
> use the implicit label from successfuly ASN.1 decode of the types
> of objects that are applicable for the requested operation.

You are assuming, I believe incorrectly, that the ASN.1 decoding is =
happening in the same part of the system as the base64 decoding. That's =
not a safe assumption. In your code, it might be fine; it is probably =
not fine in all code. Why throw away valuable information?

> Microsoft seems to ignore the label.  If you double-click on
> a pkcs7 file (extension .p7s or .p7b) it will be PEM-decoded =
independent
> of what label is used.  Same for certificate (.cer).

Um, so? That's one implementation.

> I find it much more confusing when only a few, but non-unique labels
> are accepted:
> OpenSSL seems to accept certs with "X509 CERTIFICATE" and =
"CERTIFICATE"
> and PKCS7 as "PKCS7" or "CERTIFICATE" but _not_ "X509 CERTIFICATE"

Fully agree. That's why it is good that someone (Simon!) is doing this =
work.

>> Just a thought: we define *new* labels that do what we think everyone
>> should do, such as multiple items in the block. There would not be =
much
>> uptake on those new labels in the short run, but could become the
>> standard 20 years from now.
>=20
> For OUTPUT we should try to find an reuse the most commonly used =
label,
> because the installed base is going to be with us another 10+ years.


You and I live in different universes.

--Paul Hoffman


From anders.rundgren@telia.com  Sat Jan 28 00:32:03 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169DA21F84AF for ; Sat, 28 Jan 2012 00:32:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.984
X-Spam-Level: 
X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=1.615,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WAnI8LY5QCK for ; Sat, 28 Jan 2012 00:32:02 -0800 (PST)
Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 27D7421F84AA for ; Sat, 28 Jan 2012 00:32:01 -0800 (PST)
Received: from [192.168.0.200] (81.232.141.73) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4EC0B93A01C00A7E; Sat, 28 Jan 2012 09:31:37 +0100
Message-ID: <4F23B25F.5010101@telia.com>
Date: Sat, 28 Jan 2012 09:31:27 +0100
From: Anders Rundgren 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Max Pritikin 
References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com>  <4F1484F4.6020202@telia.com>  <4F18A4B6.3060701@telia.com> <07123142-C9D7-493F-8681-548096731043@cisco.com> <8E4D80C3-1BFC-4A3C-977B-9D5D828C3D2A@vigilsec.com> <9BDA4869-A40C-4DDC-997A-D7CE67E8DCF0@cisco.com>
In-Reply-To: <9BDA4869-A40C-4DDC-997A-D7CE67E8DCF0@cisco.com>
X-Enigmail-Version: 1.3.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF PKIX 
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-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: Sat, 28 Jan 2012 08:32:03 -0000

I don't think that people involved in the "bank use-case" have much difficulties
understanding what a "PIN deployed to a key" could possibly be.

In fact, this discussion clarifies why PKIX isn't the right forum for addressing
the needs of the mobile connected world where virtual smart cards will be the norm.

 http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-462T

Anders

On 2012-01-27 22:05, Max Pritikin wrote:
> 
> Russ, 
> 
> I'm having some trouble parsing your sentence but I think you and I agree about this use: A PIN/password/passphrase is given by the RA to a person at the completion of some out-of-protocol "proofing", and this is used in a one-time fashion during the enrollment process as proof of prior proofing. 
> 
> I thought that Anders has a different vision based on his discussion of "deploying a PIN to a key" which is why I asked for clarification from him. In his response he didn't answer the question. I'll work from yours and mines shared understanding.
> 
> - max
> 
> On Jan 23, 2012, at 1:11 PM, Russ Housley wrote:
> 
>> Max:
>>
>>>> The bank I mentioned where thinking about how bank cards are used
>>>> (at least outside of the USA...), i.e. with a PIN.  They felt that on-
>>>> line-enrolled credentials should follow this time-proven pattern as well.
>>>>
>>>> Anyway, deploying a PIN to a key is quite different from authenticating
>>>> to a CA with PIN.
>>>
>>> "[D]eploying a PIN to a key" does sound vaguely like something that might occur during enrollment. Would it be fair to characterize this as a request/assertion from the CA that the client MUST encrypt/protect the private key using a PIN to ensure authorized access? Or is this actual deployment of the PIN where the CA has a hand in choosing an appropriate PIN value (according to some CA policy)? 
>>>
>>> Or do you mean that during the "actual usage of the enrolled certificate" the use of a PIN is proven by some subsequent protocol enhancements (e.g. some extension to TLS or something).
>>
>> I think it is the other way round.  A PIN / password / passphrase is given  by the RA want a person completes face-to-face proofing, and this is used in a one-time fashion during the enrollment process as proof that that proofing has taken place with the party that is presenting the certificate request.
>>
>> Russ
>>
> 
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
> 


From swilson@lockstep.com.au  Sat Jan 28 14:37:15 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC58B21F8494 for ; Sat, 28 Jan 2012 14:37:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qdDXZQFrMQ3 for ; Sat, 28 Jan 2012 14:37:15 -0800 (PST)
Received: from smtp152.iad.emailsrvr.com (smtp152.iad.emailsrvr.com [207.97.245.152]) by ietfa.amsl.com (Postfix) with ESMTP id C6C3221F8484 for ; Sat, 28 Jan 2012 14:37:14 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp45.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 4BEBD9018D for ; Sat, 28 Jan 2012 17:37:14 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp45.relay.iad1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id 8FFDE90187 for ; Sat, 28 Jan 2012 17:37:13 -0500 (EST)
Message-ID: <4F247871.4080205@lockstep.com.au>
Date: Sun, 29 Jan 2012 09:36:33 +1100
From: Stephen Wilson 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: IETF PKIX 
References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com>  <4F1484F4.6020202@telia.com>  <4F18A4B6.3060701@telia.com> <07123142-C9D7-493F-8681-548096731043@cisco.com> <8E4D80C3-1BFC-4A3C-977B-9D5D828C3D2A@vigilsec.com> <9BDA4869-A40C-4DDC-997A-D7CE67E8DCF0@cisco.com> <4F23B25F.5010101@telia.com>
In-Reply-To: <4F23B25F.5010101@telia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-00.txt
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: Sat, 28 Jan 2012 22:37:15 -0000

I for one don't know what "PIN deployed to a key" really means.
It sounds like it might be wordplay.  In general there are many ways of 
password protecting a resource and managing the password. In the world 
of SIMs and Chip-and-PIN cards, there are several common conventional 
ways of implementing PINs, like match-on-card, and different processes 
for setting initial PINs and subsequently changing them or resetting them.
Anders: What do your specifically mean?
We need no ambiguity in these technology discussions.
Cheers,
Steve Wilson.


On 28/01/2012 7:31 PM, Anders Rundgren wrote:
> I don't think that people involved in the "bank use-case" have much difficulties
> understanding what a "PIN deployed to a key" could possibly be.
>
> In fact, this discussion clarifies why PKIX isn't the right forum for addressing
> the needs of the mobile connected world where virtual smart cards will be the norm.
>
>   http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-462T
>
> Anders
>
> On 2012-01-27 22:05, Max Pritikin wrote:
>> Russ,
>>
>> I'm having some trouble parsing your sentence but I think you and I agree about this use: A PIN/password/passphrase is given by the RA to a person at the completion of some out-of-protocol "proofing", and this is used in a one-time fashion during the enrollment process as proof of prior proofing.
>>
>> I thought that Anders has a different vision based on his discussion of "deploying a PIN to a key" which is why I asked for clarification from him. In his response he didn't answer the question. I'll work from yours and mines shared understanding.
>>
>> - max
>>
>> On Jan 23, 2012, at 1:11 PM, Russ Housley wrote:
>>
>>> Max:
>>>
>>>>> The bank I mentioned where thinking about how bank cards are used
>>>>> (at least outside of the USA...), i.e. with a PIN.  They felt that on-
>>>>> line-enrolled credentials should follow this time-proven pattern as well.
>>>>>
>>>>> Anyway, deploying a PIN to a key is quite different from authenticating
>>>>> to a CA with PIN.
>>>> "[D]eploying a PIN to a key" does sound vaguely like something that might occur during enrollment. Would it be fair to characterize this as a request/assertion from the CA that the client MUST encrypt/protect the private key using a PIN to ensure authorized access? Or is this actual deployment of the PIN where the CA has a hand in choosing an appropriate PIN value (according to some CA policy)?
>>>>
>>>> Or do you mean that during the "actual usage of the enrolled certificate" the use of a PIN is proven by some subsequent protocol enhancements (e.g. some extension to TLS or something).
>>> I think it is the other way round.  A PIN / password / passphrase is given  by the RA want a person completes face-to-face proofing, and this is used in a one-time fashion during the enrollment process as proof that that proofing has taken place with the party that is presenting the certificate request.
>>>
>>> Russ
>>>
>> _______________________________________________
>> 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 anders.rundgren@telia.com  Sat Jan 28 22:17:58 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E174221F856C for ; Sat, 28 Jan 2012 22:17:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level: 
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=1.077,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id it2LdAVqdUsj for ; Sat, 28 Jan 2012 22:17:58 -0800 (PST)
Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id B782B21F84A1 for ; Sat, 28 Jan 2012 22:17:57 -0800 (PST)
Received: from [192.168.0.200] (81.232.141.73) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4EFC380E007C4B31; Sun, 29 Jan 2012 07:17:54 +0100
Message-ID: <4F24E491.6080106@telia.com>
Date: Sun, 29 Jan 2012 07:17:53 +0100
From: Anders Rundgren 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: swilson@lockstep.com.au
References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com>  <4F1484F4.6020202@telia.com>  <4F18A4B6.3060701@telia.com> <07123142-C9D7-493F-8681-548096731043@cisco.com> <8E4D80C3-1BFC-4A3C-977B-9D5D828C3D2A@vigilsec.com> <9BDA4869-A40C-4DDC-997A-D7CE67E8DCF0@cisco.com> <4F23B25F.5010101@telia.com> <4F247871.4080205@lockstep.com.au>
In-Reply-To: <4F247871.4080205@lockstep.com.au>
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF PKIX 
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-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: Sun, 29 Jan 2012 06:17:59 -0000

Stephen,
feel free coming up with a better term.

"Deploy a PIN to a key" is my short-form of describing what SKS/KeyGen2
does when it assigns a PIN policy object to a set of keys.  The initial
PIN value(s) may subsequently either be supplied through the protocol
or be requested from the user (while still in the enrollment process).

See 3.2 Key Protection Objects in:
http://webpki.org/papers/keygen2/sks-api-arch.pdf

Anyway, IMO the virtual bank card use-case cannot be crammed into EST
without a complete rewrite including nuking CMS.

Talking about terminology, maybe you know what a "Simple PKI client"
is?  This is what EST is targeting.

Anders

On 2012-01-28 23:36, Stephen Wilson wrote:
> 
> I for one don't know what "PIN deployed to a key" really means.
> It sounds like it might be wordplay.  In general there are many ways of 
> password protecting a resource and managing the password. In the world 
> of SIMs and Chip-and-PIN cards, there are several common conventional 
> ways of implementing PINs, like match-on-card, and different processes 
> for setting initial PINs and subsequently changing them or resetting them.
> Anders: What do your specifically mean?
> We need no ambiguity in these technology discussions.
> Cheers,
> Steve Wilson.
> 
> 
> On 28/01/2012 7:31 PM, Anders Rundgren wrote:
>> I don't think that people involved in the "bank use-case" have much difficulties
>> understanding what a "PIN deployed to a key" could possibly be.
>>
>> In fact, this discussion clarifies why PKIX isn't the right forum for addressing
>> the needs of the mobile connected world where virtual smart cards will be the norm.
>>
>>   http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-462T
>>
>> Anders
>>
>> On 2012-01-27 22:05, Max Pritikin wrote:
>>> Russ,
>>>
>>> I'm having some trouble parsing your sentence but I think you and I agree about this use: A PIN/password/passphrase is given by the RA to a person at the completion of some out-of-protocol "proofing", and this is used in a one-time fashion during the enrollment process as proof of prior proofing.
>>>
>>> I thought that Anders has a different vision based on his discussion of "deploying a PIN to a key" which is why I asked for clarification from him. In his response he didn't answer the question. I'll work from yours and mines shared understanding.
>>>
>>> - max
>>>
>>> On Jan 23, 2012, at 1:11 PM, Russ Housley wrote:
>>>
>>>> Max:
>>>>
>>>>>> The bank I mentioned where thinking about how bank cards are used
>>>>>> (at least outside of the USA...), i.e. with a PIN.  They felt that on-
>>>>>> line-enrolled credentials should follow this time-proven pattern as well.
>>>>>>
>>>>>> Anyway, deploying a PIN to a key is quite different from authenticating
>>>>>> to a CA with PIN.
>>>>> "[D]eploying a PIN to a key" does sound vaguely like something that might occur during enrollment. Would it be fair to characterize this as a request/assertion from the CA that the client MUST encrypt/protect the private key using a PIN to ensure authorized access? Or is this actual deployment of the PIN where the CA has a hand in choosing an appropriate PIN value (according to some CA policy)?
>>>>>
>>>>> Or do you mean that during the "actual usage of the enrolled certificate" the use of a PIN is proven by some subsequent protocol enhancements (e.g. some extension to TLS or something).
>>>> I think it is the other way round.  A PIN / password / passphrase is given  by the RA want a person completes face-to-face proofing, and this is used in a one-time fashion during the enrollment process as proof that that proofing has taken place with the party that is presenting the certificate request.
>>>>
>>>> Russ
>>>>
>>> _______________________________________________
>>> pkix mailing list
>>> pkix@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pkix
>>>
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>>
> 
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
> 


From tmiller@mitre.org  Mon Jan 30 05:06:29 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3047921F86D1; Mon, 30 Jan 2012 05:06:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffY4rm1sEeSZ; Mon, 30 Jan 2012 05:06:28 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 783BB21F86C4; Mon, 30 Jan 2012 05:06:28 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C964421B0926; Mon, 30 Jan 2012 08:06:27 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BABB721B094C; Mon, 30 Jan 2012 08:06:27 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Mon, 30 Jan 2012 08:06:27 -0500
From: "Miller, Timothy J." 
To: "mrex@sap.com" , Paul Hoffman 
Thread-Topic: [pkix] PKIX text encodings
Thread-Index: AQHM3VUNcMLmsjko+UWci5xLcgDxQpYk1JcA
Date: Mon, 30 Jan 2012 13:06:26 +0000
Message-ID: 
In-Reply-To: <201201280037.q0S0bjqe004577@fs4113.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [172.31.0.115]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0E6AEC8B15E8824ABDABAAF9370EC85B@imc.mitre.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "simon@josefsson.org" , "apps-discuss@ietf.org" , "pkix@ietf.org" 
Subject: Re: [pkix] PKIX text encodings
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 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, 30 Jan 2012 13:06:29 -0000

> Any reasonable ASN.1 decoder can reliably tell apart [...]


While any ASN.1 decoder + a little logic can discern one ASN.1 encoded
object from another, it would *really* help *non-decoding* applications to
have simple magic numbers when serializing ASN.1 to a file.

This has been a long-standing pet peeve of mine since I was asked to write
a scanner to find PKCS#12 files.  There's enough variation in encoding
that it's a real PITA to do a lightweight decode and still have a
reasonable false positive rate.

-- T

On 1/27/12 6:37 PM, "Martin Rex"  wrote:

>Paul Hoffman wrote:
>>=20
>> Martin Rex wrote:
>> >
>> > the Label that is used within '-----BEGIN ----'
>> > should be ignored on the receiver side, and all implemented formats
>> > should be tried, that are applicable for the requested operation.
>>=20
>> This would cause things like private keys and public keys to be mixed
>>up.
>
>Not necessarily.  If your ASN.1 decoder can not distinguish your private
>from your public key, then you have a whole different kind of problem.
>
>
>>
>> I propose this is not a good idea from a security perspective.
>
>Huh?  That textual label is not integrity protected in any way,
>so how should this be a security problem?
>
>This is really only about convenience for admins.
>
>
>>
>> Instead, Simon might add some text saying that some applications
>> sometimes ignore the label in order to be more liberal, but in doing
>> so can cause problems with systems that assume those labels are
>>important.
>
>HUH?  How could being liberal on *INPUT* possibly cause problems?
>
>Any reasonable ASN.1 decoder can reliably tell apart
>  - X.509 certificates
>  - private keys
>  - encrypted private keys
>  - pkcs10 requests
>  - crls
>  - pkcs7/cms=20
>  - pkcs7/cms as certificate bag
>  - pkcs7/cms as crl bag
>  - pkcs12
>
>So any implementation that is ignoring the explicit label, will have to
>use the implicit label from successfuly ASN.1 decode of the types
>of objects that are applicable for the requested operation.
>
>
>Microsoft seems to ignore the label.  If you double-click on
>a pkcs7 file (extension .p7s or .p7b) it will be PEM-decoded independent
>of what label is used.  Same for certificate (.cer).
>
>
>I find it much more confusing when only a few, but non-unique labels
>are accepted:
>OpenSSL seems to accept certs with "X509 CERTIFICATE" and "CERTIFICATE"
>and PKCS7 as "PKCS7" or "CERTIFICATE" but _not_ "X509 CERTIFICATE"
>
>
>>=20
>> Just a thought: we define *new* labels that do what we think everyone
>> should do, such as multiple items in the block. There would not be much
>> uptake on those new labels in the short run, but could become the
>> standard 20 years from now.
>
>For OUTPUT we should try to find an reuse the most commonly used label,
>because the installed base is going to be with us another 10+ years.
>
>
>-Martin
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix


From ppatterson@carillon.ca  Mon Jan 30 05:07:20 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D07721F84FF for ; Mon, 30 Jan 2012 05:07:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.595
X-Spam-Level: 
X-Spam-Status: No, score=0.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_NJABL_PROXY=1.643, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXN+Ienh7+s4 for ; Mon, 30 Jan 2012 05:07:19 -0800 (PST)
Received: from mail.carillon.ca (unknown [207.115.107.18]) by ietfa.amsl.com (Postfix) with ESMTP id E5F3F21F849D for ; Mon, 30 Jan 2012 05:07:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id 94CC2A83DBF for ; Mon, 30 Jan 2012 08:08:12 -0500 (EST)
X-Virus-Scanned: Debian amavisd-new at rhea-new.carillon.ca
Received: from mail.carillon.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-2s-z3zEF9n for ; Mon, 30 Jan 2012 08:08:11 -0500 (EST)
Received: from [192.168.42.129] (modemcable140.236-131-66.mc.videotron.ca [66.131.236.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTPSA id 2E03CA812B8 for ; Mon, 30 Jan 2012 08:08:11 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: Patrick Patterson 
In-Reply-To: <4F24E491.6080106@telia.com>
Date: Mon, 30 Jan 2012 08:07:16 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <525748F0-2BC1-4A2A-92EF-9430ECEC5C57@carillon.ca>
References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com>  <4F1484F4.6020202@telia.com>  <4F18A4B6.3060701@telia.com> <07123142-C9D7-493F-8681-548096731043@cisco.com> <8E4D80C3-1BFC-4A3C-977B-9D5D828C3D2A@vigilsec.com> <9BDA4869-A40C-4DDC-997A-D7CE67E8DCF0@cisco.com> <4F23B25F.5010101@telia.com> <4F247871.4080205@lockstep.com.au> <4F24E491.6080106@telia.com>
To: IETF PKIX 
X-Mailer: Apple Mail (2.1084)
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-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: Mon, 30 Jan 2012 13:07:20 -0000

Hi Anders:

Now, I am not fully cognisant of all of the details of the bank and =
credit card use cases, but my understanding is that there are roughly =
two or three ways that these organisations handle secondary =
authentications to activate and use the cards (i.e. PIN).

The first is that, when the card is initialized in the service bureau, a =
PIN is generated and programmed into a card, which is subsequently =
locked. The PIN and card are then sent out via two channels, with the =
PIN usually being sent in a tamper evident, blinded envelope. Once the =
cardholder gets both card and PIN (or sometimes just the card), they =
call some sort of customer service number, and the card is activated. In =
this case, there is a "match on card" for the PIN, and, past the point =
of printing, the Bank or CC company doesn't know the PIN (although they =
can cause it to be reset).

The second is essentially identical to the first, except that the PIN =
isn't encoded on the card, but is produced and sent to the cardholder, =
and, during day to day use, must be matched to some sort of Database at =
the Bank or CC Company. (i.e. no match on card) My understanding is the =
the companies involved would like to solely use the first method, but =
must support the second in some circumstances due to braindead terminals =
/ processing facilities.

The third model encodes the card, but no PIN, sends the locked card to =
the cardholder, and then forces the cardholder to go into some location =
where a face-to-face proofing is done and a PIN is set (this probably =
matches most closely to a number of more familiar PKI use cases). Again, =
in this case, like the first, match on card is done, and the Bank or =
issuing company doesn't know the PIN.

Now, not having read the draft in detail, but having been involved in a =
few deployments, I would say that the protocol involved here is between =
the card management system and the CA. The Card Management System, =
though, is responsible for using some protocol to talk to the card =
(Secure Channel, or similar, such as is used today by a number of the =
current Card Management System vendors), lock/unlock the card, and =
perform PIN functions. I see these as working at a two different layers. =
They aren't mutually exclusive, and the fact that the current draft =
doesn't involve any communication of activation data doesn't necessarily =
mean that it is fatally broken.

Is there a reason for the CA itself to tie the activation data and the =
keys together, or can that function be safely handled by a carefully =
managed card management system (like it is today for most PIV, PIV-I, =
and other smartcard based PKI deployments)?

If my understanding is flawed here, please let me know - as I said - I'm =
not fully aware of the intricacies of PKI inside of financial =
institutions, but I'm a firm believer in not re-inventing wheels, and if =
the rest of the PKI world can learn from a sector that has a wide =
deployed base, then please enlighten us :)

Cheers,

Patrick.



On 2012-01-29, at 1:17 AM, Anders Rundgren wrote:

> Stephen,
> feel free coming up with a better term.
>=20
> "Deploy a PIN to a key" is my short-form of describing what =
SKS/KeyGen2
> does when it assigns a PIN policy object to a set of keys.  The =
initial
> PIN value(s) may subsequently either be supplied through the protocol
> or be requested from the user (while still in the enrollment process).
>=20
> See 3.2 Key Protection Objects in:
> http://webpki.org/papers/keygen2/sks-api-arch.pdf
>=20
> Anyway, IMO the virtual bank card use-case cannot be crammed into EST
> without a complete rewrite including nuking CMS.
>=20
> Talking about terminology, maybe you know what a "Simple PKI client"
> is?  This is what EST is targeting.
>=20
> Anders
>=20
> On 2012-01-28 23:36, Stephen Wilson wrote:
>>=20
>> I for one don't know what "PIN deployed to a key" really means.
>> It sounds like it might be wordplay.  In general there are many ways =
of=20
>> password protecting a resource and managing the password. In the =
world=20
>> of SIMs and Chip-and-PIN cards, there are several common conventional=20=

>> ways of implementing PINs, like match-on-card, and different =
processes=20
>> for setting initial PINs and subsequently changing them or resetting =
them.
>> Anders: What do your specifically mean?
>> We need no ambiguity in these technology discussions.
>> Cheers,
>> Steve Wilson.
>>=20
>>=20
>> On 28/01/2012 7:31 PM, Anders Rundgren wrote:
>>> I don't think that people involved in the "bank use-case" have much =
difficulties
>>> understanding what a "PIN deployed to a key" could possibly be.
>>>=20
>>> In fact, this discussion clarifies why PKIX isn't the right forum =
for addressing
>>> the needs of the mobile connected world where virtual smart cards =
will be the norm.
>>>=20
>>>  http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-462T
>>>=20
>>> Anders
>>>=20
>>> On 2012-01-27 22:05, Max Pritikin wrote:
>>>> Russ,
>>>>=20
>>>> I'm having some trouble parsing your sentence but I think you and I =
agree about this use: A PIN/password/passphrase is given by the RA to a =
person at the completion of some out-of-protocol "proofing", and this is =
used in a one-time fashion during the enrollment process as proof of =
prior proofing.
>>>>=20
>>>> I thought that Anders has a different vision based on his =
discussion of "deploying a PIN to a key" which is why I asked for =
clarification from him. In his response he didn't answer the question. =
I'll work from yours and mines shared understanding.
>>>>=20
>>>> - max
>>>>=20
>>>> On Jan 23, 2012, at 1:11 PM, Russ Housley wrote:
>>>>=20
>>>>> Max:
>>>>>=20
>>>>>>> The bank I mentioned where thinking about how bank cards are =
used
>>>>>>> (at least outside of the USA...), i.e. with a PIN.  They felt =
that on-
>>>>>>> line-enrolled credentials should follow this time-proven pattern =
as well.
>>>>>>>=20
>>>>>>> Anyway, deploying a PIN to a key is quite different from =
authenticating
>>>>>>> to a CA with PIN.
>>>>>> "[D]eploying a PIN to a key" does sound vaguely like something =
that might occur during enrollment. Would it be fair to characterize =
this as a request/assertion from the CA that the client MUST =
encrypt/protect the private key using a PIN to ensure authorized access? =
Or is this actual deployment of the PIN where the CA has a hand in =
choosing an appropriate PIN value (according to some CA policy)?
>>>>>>=20
>>>>>> Or do you mean that during the "actual usage of the enrolled =
certificate" the use of a PIN is proven by some subsequent protocol =
enhancements (e.g. some extension to TLS or something).
>>>>> I think it is the other way round.  A PIN / password / passphrase =
is given  by the RA want a person completes face-to-face proofing, and =
this is used in a one-time fashion during the enrollment process as =
proof that that proofing has taken place with the party that is =
presenting the certificate request.
>>>>>=20
>>>>> Russ
>>>>>=20
>>>> _______________________________________________
>>>> pkix mailing list
>>>> pkix@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>>=20
>>> _______________________________________________
>>> pkix mailing list
>>> pkix@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pkix
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>=20
>=20
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix

---
Patrick Patterson
Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca






From anders.rundgren@telia.com  Mon Jan 30 13:40:18 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2539911E80B2 for ; Mon, 30 Jan 2012 13:40:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.792
X-Spam-Level: 
X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[AWL=0.807,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26-jnEbPWl+N for ; Mon, 30 Jan 2012 13:40:16 -0800 (PST)
Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9EC11E80B1 for ; Mon, 30 Jan 2012 13:40:15 -0800 (PST)
Received: from [192.168.0.200] (81.232.141.73) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4EC0B93A01CDB59C; Mon, 30 Jan 2012 22:40:07 +0100
Message-ID: <4F270E33.7060909@telia.com>
Date: Mon, 30 Jan 2012 22:40:03 +0100
From: Anders Rundgren 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Patrick Patterson 
References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com>  <4F1484F4.6020202@telia.com>  <4F18A4B6.3060701@telia.com> <07123142-C9D7-493F-8681-548096731043@cisco.com> <8E4D80C3-1BFC-4A3C-977B-9D5D828C3D2A@vigilsec.com> <9BDA4869-A40C-4DDC-997A-D7CE67E8DCF0@cisco.com> <4F23B25F.5010101@telia.com> <4F247871.4080205@lockstep.com.au> <4F24E491.6080106@telia.com> <525748F0-2BC1-4A2A-92EF-9430ECEC5C57@carillon.ca>
In-Reply-To: <525748F0-2BC1-4A2A-92EF-9430ECEC5C57@carillon.ca>
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF PKIX 
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-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: Mon, 30 Jan 2012 21:40:18 -0000

Hi Patrick,
It was nice to see someone who have actually worked with smart cards comment on this!

Just to set the record straight: I never said that EST is "fatally broken", only that it
doesn't satisfy the bank use-case. 

A complication is that probably none of the (very few) people who take interest in this
topic have bothered reading the SKS/KeyGen2 specification although is at least shows
one person's view of what may be needed including the Secure Channel you mention.

In addition, the PKIX WG seem unaware of that Microsoft and Apple have added (entirely
proprietary) protocol bootstrap messages in their adaption of PKIX enrollment protocols.
These are fundamental because they effectively form the foundation for the CSR.
This means that it is the *server* that asks the client to generate keys of the kind that
the server wants, possibly including some variations for different client platforms.

SKS/KeyGen2 takes this notion to another level by letting the server (after an initial
session setup including user interaction), control the entire process.  This is AFAICT
also *a prerequisite for achieving true end-to-end security*.

Regarding Card Management Systems, they do not mix well with mobile phones.
Using SKS/KeyGen2 and a new bread of smart cards, you may eliminate the client-
side of this part as well.

Regards,
Anders Rundgren
http://webpki.org/auth-token-4-the-cloud.html




On 2012-01-30 14:07, Patrick Patterson wrote:
> Hi Anders:
>
> Now, I am not fully cognisant of all of the details of the bank and credit card use cases, but my understanding is that there are roughly two or three ways that these organisations handle secondary authentications to activate and use the cards (i.e. PIN).
>
> The first is that, when the card is initialized in the service bureau, a PIN is generated and programmed into a card, which is subsequently locked. The PIN and card are then sent out via two channels, with the PIN usually being sent in a tamper evident, blinded envelope. Once the cardholder gets both card and PIN (or sometimes just the card), they call some sort of customer service number, and the card is activated. In this case, there is a "match on card" for the PIN, and, past the point of printing, the Bank or CC company doesn't know the PIN (although they can cause it to be reset).
>
> The second is essentially identical to the first, except that the PIN isn't encoded on the card, but is produced and sent to the cardholder, and, during day to day use, must be matched to some sort of Database at the Bank or CC Company. (i.e. no match on card) My understanding is the the companies involved would like to solely use the first method, but must support the second in some circumstances due to braindead terminals / processing facilities.
>
> The third model encodes the card, but no PIN, sends the locked card to the cardholder, and then forces the cardholder to go into some location where a face-to-face proofing is done and a PIN is set (this probably matches most closely to a number of more familiar PKI use cases). Again, in this case, like the first, match on card is done, and the Bank or issuing company doesn't know the PIN.
>
> Now, not having read the draft in detail, but having been involved in a few deployments, I would say that the protocol involved here is between the card management system and the CA. The Card Management System, though, is responsible for using some protocol to talk to the card (Secure Channel, or similar, such as is used today by a number of the current Card Management System vendors), lock/unlock the card, and perform PIN functions. I see these as working at a two different layers. They aren't mutually exclusive, and the fact that the current draft doesn't involve any communication of activation data doesn't necessarily mean that it is fatally broken.
>
> Is there a reason for the CA itself to tie the activation data and the keys together, or can that function be safely handled by a carefully managed card management system (like it is today for most PIV, PIV-I, and other smartcard based PKI deployments)?
>
> If my understanding is flawed here, please let me know - as I said - I'm not fully aware of the intricacies of PKI inside of financial institutions, but I'm a firm believer in not re-inventing wheels, and if the rest of the PKI world can learn from a sector that has a wide deployed base, then please enlighten us :)
>
> Cheers,
>
> Patrick.
>
>
>
> On 2012-01-29, at 1:17 AM, Anders Rundgren wrote:
>
>> Stephen,
>> feel free coming up with a better term.
>>
>> "Deploy a PIN to a key" is my short-form of describing what SKS/KeyGen2
>> does when it assigns a PIN policy object to a set of keys.  The initial
>> PIN value(s) may subsequently either be supplied through the protocol
>> or be requested from the user (while still in the enrollment process).
>>
>> See 3.2 Key Protection Objects in:
>> http://webpki.org/papers/keygen2/sks-api-arch.pdf
>>
>> Anyway, IMO the virtual bank card use-case cannot be crammed into EST
>> without a complete rewrite including nuking CMS.
>>
>> Talking about terminology, maybe you know what a "Simple PKI client"
>> is?  This is what EST is targeting.
>>
>> Anders
>>
>> On 2012-01-28 23:36, Stephen Wilson wrote:
>>> I for one don't know what "PIN deployed to a key" really means.
>>> It sounds like it might be wordplay.  In general there are many ways of 
>>> password protecting a resource and managing the password. In the world 
>>> of SIMs and Chip-and-PIN cards, there are several common conventional 
>>> ways of implementing PINs, like match-on-card, and different processes 
>>> for setting initial PINs and subsequently changing them or resetting them.
>>> Anders: What do your specifically mean?
>>> We need no ambiguity in these technology discussions.
>>> Cheers,
>>> Steve Wilson.
>>>
>>>
>>> On 28/01/2012 7:31 PM, Anders Rundgren wrote:
>>>> I don't think that people involved in the "bank use-case" have much difficulties
>>>> understanding what a "PIN deployed to a key" could possibly be.
>>>>
>>>> In fact, this discussion clarifies why PKIX isn't the right forum for addressing
>>>> the needs of the mobile connected world where virtual smart cards will be the norm.
>>>>
>>>>  http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-462T
>>>>
>>>> Anders
>>>>
>>>> On 2012-01-27 22:05, Max Pritikin wrote:
>>>>> Russ,
>>>>>
>>>>> I'm having some trouble parsing your sentence but I think you and I agree about this use: A PIN/password/passphrase is given by the RA to a person at the completion of some out-of-protocol "proofing", and this is used in a one-time fashion during the enrollment process as proof of prior proofing.
>>>>>
>>>>> I thought that Anders has a different vision based on his discussion of "deploying a PIN to a key" which is why I asked for clarification from him. In his response he didn't answer the question. I'll work from yours and mines shared understanding.
>>>>>
>>>>> - max
>>>>>
>>>>> On Jan 23, 2012, at 1:11 PM, Russ Housley wrote:
>>>>>
>>>>>> Max:
>>>>>>
>>>>>>>> The bank I mentioned where thinking about how bank cards are used
>>>>>>>> (at least outside of the USA...), i.e. with a PIN.  They felt that on-
>>>>>>>> line-enrolled credentials should follow this time-proven pattern as well.
>>>>>>>>
>>>>>>>> Anyway, deploying a PIN to a key is quite different from authenticating
>>>>>>>> to a CA with PIN.
>>>>>>> "[D]eploying a PIN to a key" does sound vaguely like something that might occur during enrollment. Would it be fair to characterize this as a request/assertion from the CA that the client MUST encrypt/protect the private key using a PIN to ensure authorized access? Or is this actual deployment of the PIN where the CA has a hand in choosing an appropriate PIN value (according to some CA policy)?
>>>>>>>
>>>>>>> Or do you mean that during the "actual usage of the enrolled certificate" the use of a PIN is proven by some subsequent protocol enhancements (e.g. some extension to TLS or something).
>>>>>> I think it is the other way round.  A PIN / password / passphrase is given  by the RA want a person completes face-to-face proofing, and this is used in a one-time fashion during the enrollment process as proof that that proofing has taken place with the party that is presenting the certificate request.
>>>>>>
>>>>>> Russ
>>>>>>
>>>>> _______________________________________________
>>>>> pkix mailing list
>>>>> pkix@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>>>
>>>> _______________________________________________
>>>> pkix mailing list
>>>> pkix@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>>
>>>>
>>> _______________________________________________
>>> pkix mailing list
>>> pkix@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pkix
>>>
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
> ---
> Patrick Patterson
> Chief PKI Architect
> Carillon Information Security Inc.
> http://www.carillon.ca
>
>
>
>
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>


From ppatterson@carillon.ca  Mon Jan 30 16:13:35 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA8811E80FF for ; Mon, 30 Jan 2012 16:13:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.048
X-Spam-Level: 
X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXTSF+-sSLhr for ; Mon, 30 Jan 2012 16:13:34 -0800 (PST)
Received: from mail.carillon.ca (unknown [207.115.107.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4583B11E8100 for ; Mon, 30 Jan 2012 16:13:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id C793AA83D96 for ; Mon, 30 Jan 2012 19:14:28 -0500 (EST)
X-Virus-Scanned: Debian amavisd-new at rhea-new.carillon.ca
Received: from mail.carillon.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfYN8U9OOfpI for ; Mon, 30 Jan 2012 19:14:27 -0500 (EST)
Received: from [192.168.6.175] (69-196-152-118.dsl.teksavvy.com [69.196.152.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTPSA id 89B9BA83D94 for ; Mon, 30 Jan 2012 19:14:26 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: Patrick Patterson 
In-Reply-To: <4F270E33.7060909@telia.com>
Date: Mon, 30 Jan 2012 19:13:27 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com>  <4F1484F4.6020202@telia.com>  <4F18A4B6.3060701@telia.com> <07123142-C9D7-493F-8681-548096731043@cisco.com> <8E4D80C3-1BFC-4A3C-977B-9D5D828C3D2A@vigilsec.com> <9BDA4869-A40C-4DDC-997A-D7CE67E8DCF0@cisco.com> <4F23B25F.5010101@telia.com> <4F247871.4080205@lockstep.com.au> <4F24E491.6080106@telia.com> <525748F0-2BC1-4A2A-92EF-9430ECEC5C57@carillon.ca> <4F270E33.7060909@telia.com>
To: IETF PKIX 
X-Mailer: Apple Mail (2.1084)
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-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: Tue, 31 Jan 2012 00:13:35 -0000

Hi Anders:

On 2012-01-30, at 4:40 PM, Anders Rundgren wrote:

> Hi Patrick,
> It was nice to see someone who have actually worked with smart cards =
comment on this!
>=20

Oh, I don't know - there are a number of folks in the mailing list with =
a fair bit more experience than I.

> Just to set the record straight: I never said that EST is "fatally =
broken", only that it
> doesn't satisfy the bank use-case.=20
>=20

Ok - which part of the use case does it not satisfy? As I indicated in =
my mail, there appears to be room for EST for the CMS to CA part of the =
conversation. If we DO require "end to end", then how do we merge the =
enrolment protocols with the card management protocols???

> A complication is that probably none of the (very few) people who take =
interest in this
> topic have bothered reading the SKS/KeyGen2 specification although is =
at least shows
> one person's view of what may be needed including the Secure Channel =
you mention.
>=20

Let's start by asking the question why the classic "CMS + CA" (where, =
for disambiguation, CMS =3D=3D Card Management System/Service) is =
insufficient for the "Bank" use case?

> In addition, the PKIX WG seem unaware of that Microsoft and Apple have =
added (entirely
> proprietary) protocol bootstrap messages in their adaption of PKIX =
enrollment protocols.
> These are fundamental because they effectively form the foundation for =
the CSR.
> This means that it is the *server* that asks the client to generate =
keys of the kind that
> the server wants, possibly including some variations for different =
client platforms.
>=20

Ok - I agree with you here - there are some (rather nice) additions to =
the Microsoft cert enrolment stuff that allow a developer / CA to =
control the CSP, crypto strength, etc. that isn't afforded by the rather =
spartan (but more widely deployed)  tag.

I DO agree that what we probably need to add to any enrolment protocol =
is a way for the CA to say that "If you are going to request a cert from =
me, you have to be able to support X, Y or Z capability").

> SKS/KeyGen2 takes this notion to another level by letting the server =
(after an initial
> session setup including user interaction), control the entire process. =
 This is AFAICT
> also *a prerequisite for achieving true end-to-end security*.
>=20

In the mobile space, I suppose (although I am not at all familiar with =
all of the issues) it is important to eliminate the CMS (or, at least =
that is what you are implying), and go direct to the device. I can see =
several ways to do this with some of the widely deployed tech (including =
some rather simple extensions to the keygen tag without adding an entire =
new protocol). I can also see several drawbacks (including the fact that =
, in at least the mobile space, the time for approval / certification is =
greater than that useful lifetime of the product). Please explain =
further the requirements here, and how the current capability needs to =
be augmented to address these requirements.

Best Regards,

---
Patrick Patterson
Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca






From eric_bianchetti@yahoo.com  Mon Jan 30 20:48:46 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E5211E8112 for ; Mon, 30 Jan 2012 20:48:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.981
X-Spam-Level: 
X-Spam-Status: No, score=0.981 tagged_above=-999 required=5 tests=[AWL=-0.980,  BAYES_50=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqVQEQ2lfDoY for ; Mon, 30 Jan 2012 20:48:45 -0800 (PST)
Received: from nm40-vm7.bullet.mail.ne1.yahoo.com (nm40-vm7.bullet.mail.ne1.yahoo.com [98.138.229.183]) by ietfa.amsl.com (Postfix) with SMTP id 543BB11E80EC for ; Mon, 30 Jan 2012 20:48:45 -0800 (PST)
Received: from [98.138.90.55] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 31 Jan 2012 04:48:42 -0000
Received: from [98.138.89.164] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 31 Jan 2012 04:48:42 -0000
Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 31 Jan 2012 04:48:42 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 203748.31510.bm@omp1020.mail.ne1.yahoo.com
Received: (qmail 10259 invoked by uid 60001); 31 Jan 2012 04:48:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1327985321; bh=ZuLu0Qm09UDI4ykop2hLqu0mCL1mn6hLxmTcYxkewqY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kviFAeI6zJbB5sk60JCU+6K/fOWcc8kSNaCJfitLAL9D/yZIZT9RI+JqR2YbEmNYfbH/+XZl0oPH/i9hhJERgh8Jhy1ZLn45oIOydZV3Za2kv5e38sXH2fO/bRlPffN+1jJMwCVYMlbaNRUZbhigffT8NALEagIuhMqYtZYRubM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FJ5iHSCAYqZG8lNfJKRdx2hWhQcdoTNVKSQ5rOq4TPpUFt2Pznmlykv8K5tfroE3BjrcIYnlpOxopfWyQPtiJ6LWnlrYahL5uLWJZtFZdpyZetRqgeU23vvBdUcJunbuZfCjOzovBmGaocnDR7336tv4Vh0Ss/CyE9owNS40Uq8=;
X-YMail-OSG: 98IVG48VM1kbkkcOH8xD0nc_0tA5r.uS7xKHllVnWktxEsw aXCaN8aP8RCTK.pZ_sYag4nbmgAtyUhjmT4v1AE_EgfAXXAse2u5aJc69wh4 4X7ySNBh.6THQNG6ZfxaRtRxf.gPhLhnlixf.KDuust.QV_rr0yiJD3rzftG .Wvtx3umrZJbXrq.140y8fKC_ZE0lMozCYLzq2DmJGEzg04886wojQs8w1Mx 0avYiCgm5tyPvcAnIN0yq3V4cLnjTk3KujGWsvKINAzIIoXYC9VVCs09SZVI BLfVsFGkKwiExDYVPzAgJWon5ylGRI1mMlXsViiWDD7cX_TnpFTUpTpK9y3q L1vPKy.tZlPnRCcXFwlBW1GSHRoNGn84LLdL1LJIoFFVw4cEDRkUKB0k28tJ qAP_VQxvSQgz8UJx6ah1hjrKg9dyx49KMdOqSB3C8Wy9gKIvxaDn5LrTLEwZ g09n7x0mcvgG08fN9T5VJaKwCdqA5vzHghBih031UlxZ5OTZhF.srEXY-
Received: from [171.99.144.138] by web130202.mail.mud.yahoo.com via HTTP; Mon, 30 Jan 2012 20:48:41 PST
X-Mailer: YahooMailWebService/0.8.116.331537
References: <4F10AA5B.8050503@KingsMountain.com> <4218085B-5136-4ADF-AD00-50DB3C7EB72F@checkpoint.com>
Message-ID: <1327985321.8147.YahooMailNeo@web130202.mail.mud.yahoo.com>
Date: Mon, 30 Jan 2012 20:48:41 -0800 (PST)
From: eric bianchetti 
To: Yoav Nir , =JeffH 
In-Reply-To: <4218085B-5136-4ADF-AD00-50DB3C7EB72F@checkpoint.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailman-Approved-At: Tue, 31 Jan 2012 07:19:33 -0800
Cc: pkix , dane , "saag@ietf.org" , "tls@ietf.org" 
Subject: Re: [pkix] [saag] [dane] Fwd: New Non-WG Mailing List: therightkey
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: eric bianchetti 
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 04:48:46 -0000

works here 

----- Original Message -----
From: Yoav Nir 
To: =JeffH 
Cc: pkix ; "saag@ietf.org" ; "tls@ietf.org" ; dane 
Sent: Saturday, January 14, 2012 4:03 PM
Subject: Re: [saag] [dane] Fwd: New Non-WG Mailing List: therightkey


On Jan 14, 2012, at 12:04 AM, =JeffH wrote:

>> On Fri, Jan 13, 2012 at 1:26 PM, Stephen Farrell
>>  wrote:
>>> Archive: http://www.ietf.org/mail-archive/web/therightkey/
>> 
>> This link is dead. Typo, or not yet available?
> 
> works for me!

+1
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


From anders.rundgren@telia.com  Tue Jan 31 13:28:26 2012
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CDB11E8095 for ; Tue, 31 Jan 2012 13:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.953
X-Spam-Level: 
X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[AWL=0.646,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0t1ihu-spHT for ; Tue, 31 Jan 2012 13:28:25 -0800 (PST)
Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 62CBB11E8096 for ; Tue, 31 Jan 2012 13:28:25 -0800 (PST)
Received: from [192.168.0.200] (81.232.141.73) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4EFC380E0089DB2E; Tue, 31 Jan 2012 22:28:17 +0100
Message-ID: <4F285CED.9000802@telia.com>
Date: Tue, 31 Jan 2012 22:28:13 +0100
From: Anders Rundgren 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Patrick Patterson 
References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com>  <4F1484F4.6020202@telia.com>  <4F18A4B6.3060701@telia.com> <07123142-C9D7-493F-8681-548096731043@cisco.com> <8E4D80C3-1BFC-4A3C-977B-9D5D828C3D2A@vigilsec.com> <9BDA4869-A40C-4DDC-997A-D7CE67E8DCF0@cisco.com> <4F23B25F.5010101@telia.com> <4F247871.4080205@lockstep.com.au> <4F24E491.6080106@telia.com> <525748F0-2BC1-4A2A-92EF-9430ECEC5C57@carillon.ca> <4F270E33.7060909@telia.com> 
In-Reply-To: 
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF PKIX 
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-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: Tue, 31 Jan 2012 21:28:26 -0000

IMO, the people who brought EST to PKIX need to specify what
EST-00's stated target "Simple PKI clients" actually means,
preferably by listing a few concrete examples.

Now over to your specific questions and comments...

On 2012-01-31 01:13, Patrick Patterson wrote:
> Hi Anders:
> 
> On 2012-01-30, at 4:40 PM, Anders Rundgren wrote:
> 
>> Hi Patrick,
>> It was nice to see someone who have actually worked with smart cards comment on this!
>>
> 
> Oh, I don't know - there are a number of folks in the mailing list with a fair bit more experience than I.
> 
>> Just to set the record straight: I never said that EST is "fatally broken", only that it
>> doesn't satisfy the bank use-case. 
>>
> 
> Ok - which part of the use case does it not satisfy? As I indicated in my mail, 
> there appears to be room for EST for the CMS to CA part of the conversation.

Absolutely, but why would the CMS vendors replace their perfectly working CMP
solutions with EST?


> If we DO require "end to end", then how do we merge the enrolment protocols with the card management protocols???

End-to-end of the kind you and I are referring to isn't known by the
the PKIX WG at large and therefore this discussion (early on) went south.

Anyway, my take on this topic is creating a united solution where
certificate enrollment has morphed into or token management.


>> A complication is that probably none of the (very few) people who take interest in this
>> topic have bothered reading the SKS/KeyGen2 specification although is at least shows
>> one person's view of what may be needed including the Secure Channel you mention.
>>
> 
> Let's start by asking the question why the classic "CMS + CA" (where, for disambiguation, CMS == Card Management System/Service) is insufficient for the "Bank" use case?

If you go back to my initial posting it was about iPhone/Android.
The bank wanted to have PIN-protected keys which PKIX enrollment
protocols doesn't support.


>> In addition, the PKIX WG seem unaware of that Microsoft and Apple have added (entirely
>> proprietary) protocol bootstrap messages in their adaption of PKIX enrollment protocols.
>> These are fundamental because they effectively form the foundation for the CSR.
>> This means that it is the *server* that asks the client to generate keys of the kind that
>> the server wants, possibly including some variations for different client platforms.
>>
> 
> Ok - I agree with you here - there are some (rather nice) additions to 
> the Microsoft cert enrolment stuff that allow a developer / CA to control
> the CSP, crypto strength, etc. that isn't afforded by the rather spartan
> (but more widely deployed)  tag.

The CertEnroll "concept" is good but unfortunately the implementation is built
on a severely broken trust and security model which have created a virtual
industry of writing proprietary enrollment software.  Just about every country
in the EU have been forced doing that.



> I DO agree that what we probably need to add to any enrolment protocol is a way for
> the CA to say that "If you are going to request a cert from me, you have to be able to
> support X, Y or Z capability").
> 
>> SKS/KeyGen2 takes this notion to another level by letting the server (after an initial
>> session setup including user interaction), control the entire process.  This is AFAICT
>> also *a prerequisite for achieving true end-to-end security*.
>>
> 
> In the mobile space, I suppose (although I am not at all familiar with all of
> the issues) it is important to eliminate the CMS (or, at least that is what
> you are implying), and go direct to the device.

Yes.


> I can see several ways to do this with some of the widely deployed tech 
> (including some rather simple extensions to the keygen tag without
> adding an entire new protocol).

When Google designed their Wallet they didn't want to be bogged-down by
technology that was conceived in another time for another purpose.
They did exactly what I would do: built a new system from scratch.



> I can also see several drawbacks (including the fact that , in at 
> least the mobile space, the time for approval / certification is
> greater than that useful lifetime of the product). Please explain
> further the requirements here, and how the current capability needs
> to be augmented to address these requirements.

I don't have any solutions to the certification requirement except
that vendors keep outdated models available for those who insist
having it.  I may be better that vendors use certified building
and testing processes than having external certification of
every mobile terminal.  Automatic updates also helps.

The BYOD phenomena makes this topic even more interesting :-)

Anders


> Best Regards,
> 
> ---
> Patrick Patterson
> Chief PKI Architect
> Carillon Information Security Inc.
> http://www.carillon.ca
> 
> 
> 
> 
> 
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>