Subject: Have You heard about the latest weight loss trial?

From: [email-masked]
Date: Sat, 30 May 2009 23:06:29 +0100

If you have trouble viewing this e-mail, please click here.

Everyone

Will Want

Your New Secret

ACAI POWER SLIM

Discover the secret today!

Click here for details

To
review our Privacy Policy, please click here.

To ensure the delivery of your informative updates from Dr. Lark and the Daily Balance
Team, please add
[email-masked]

to your email address book.

************TO UNSUBSCRIBE************

You are receiving this e-mail at [email-masked] because you

indicated an interest in receiving special updates and offers
from Dr. Lark.

We hope that you find these updates helpful, but if you would
rather
not

receive them, you can unsubscribe by clicking here. You will be

immediately unsubscribed from our database. Remember, your personal information

will only be used by Healthy Directions, LLC, for editorial and marketing purposes.

Thank you.

Daily Balance

809 Indian Springs Drive

Lancaster, PA 77905

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TCkkOg061675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 05:46:47 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TCkkQx061673; Fri, 29 May 2009 05:46:46 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TCkkeQ061667 for ; Fri, 29 May 2009 05:46:46 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id 0C85D3A6B1C; Fri, 29 May 2009 05:45:01 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-other-certs-04.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Fri, 29 May 2009 05:45:02 -0700 (PDT)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

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.

Title : Other Certificates Extension
Author(s) : S. Farrell
Filename : draft-ietf-pkix-other-certs-04.txt
Pages : 8
Date : 2009-05-29

Some applications that associate state information with public key
certificates can benefit from a way to link together a set of
certificates belonging to the same end entity that can safely be
considered to be equivalent for the purposes of referencing that
application state information. This memo defines a certificate
extension that allows applications to establish the required linkage
without introducing a new application protocol data unit.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-other-certs-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-pkix-other-certs-04.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SKiUdo088991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 13:44:30 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4SKiULn088990; Thu, 28 May 2009 13:44:30 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SKiCow088966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 13:44:13 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Thu, 28 May 2009 13:38:17 -0700
To: Daniel Brown , "[email-masked]"
From: Paul Hoffman
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 1:59 PM -0400 5/28/09, Daniel Brown wrote:
>Paul,
>
>Regarding your comment 3) below about validation requirements, I suggest that this RFC 3279 update mandate SHA2 as a "SHOULD" (rather than a MUST as it is in the WGLC draft).
>
>Not making it a MUST avoids making existing implementations non-conformant. Making it a SHOULD alerts implementers to the security issues and to the NIST compliance/interoperability issues.

Please be more specific. What exact wording are you proposing? If you were simply going to replace "MUST" with "SHOULD" in the last paragraph of section 3, how would an implementer know when it is OK not to follow the mandate?

As you can tell, this whole train of thought still bothers me. It is fine for us to list the issues and to make recommendations about them; that is quite different than invoking RFC 2119 language, particularly in a vague fashion.

>Regarding your comment 2) below about key sizes and lifetimes, I suggest this RFC 3279 update make the associated NIST recommendations a SHOULD. Again, this is for security reasons and better NIST compliance/interoperability issues.

And I fully disagree for the same reasons. NIST makes it clear that their recommendations are for one particular market, not the entire world. If we want to make them world-wide, then we should help NIST come up with more consistent and readable recommendations that match the new mandate; so far, NIST has not asked for that type of help, and I would not expect them to do so in the future.

>Generally, the DSA/ECDSA and SHA-1/2 algorithms come from NIST and ANSI, and have some normative security requirements about key sizes. Completely dropping some of the normative security requirements should require strong justification.

The IETF attempts to create standards that implementers can understand. Mandating the NIST logic, which conflates different sizes and strengths for reasons that make sense for NIST but not for us, does not lead to such standards.

Again, it is a good idea to point to the NIST documents as guidance for implementers. If there were competing documents with different guidance, pointing to them would be good as well (I'm not aware of any such competing documents). That's quite different than mandating compliance with the NIST specs that were written for different purposes than we have.

I would still like comment on my greatly-shortened version of this document, as well as on the other concerns expressed on this thread.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SKiKUK088979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 13:44:20 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4SKiKqd088978; Thu, 28 May 2009 13:44:20 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SKiCp0088966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 13:44:14 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Thu, 28 May 2009 13:44:10 -0700
To: Daniel Brown , Stefan Santesson , "[email-masked]"
From: Paul Hoffman
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 2:03 PM -0400 5/28/09, Daniel Brown wrote:
>X9.62-2005, Annex K, Security Considerations does cover topics that I have not seen SP 800-57.

The most relevant ones from X9.62 seem to be covered somewhere in either SP 800-57 or FIPS 186-3. Sure, the crypto geekiness in the earlier part of the appendix is interesting, but probably not relevant to this draft.

>Therefore, I think X9.62 would be worth mentioning in the security considerations of this RFC 3279 update.

It is worth mentioning, sure.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SI3cSh076408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 11:03:38 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4SI3cg5076406; Thu, 28 May 2009 11:03:38 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from cx296.800onemail.com (CX296.800onemail.com [209.171.54.154]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SI3b6K076395 for ; Thu, 28 May 2009 11:03:37 -0700 (MST) (envelope-from [email-masked])
Received: from ex13-n01.exchserver.com ([192.168.162.157]) by cx296.800onemail.com (8.13.8/8.13.8) with ESMTP id n4SI3Kaq032172; Thu, 28 May 2009 14:03:20 -0400
Received: from EX41-2.exchserver.com ([169.254.4.162]) by ex13-n01.exchserver.com ([192.168.162.160]) with mapi; Thu, 28 May 2009 14:03:21 -0400
From: Daniel Brown
To: Paul Hoffman , Stefan Santesson , "[email-masked]"
Date: Thu, 28 May 2009 14:03:19 -0400
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Thread-Topic: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Thread-Index: AcnRpwcIZySGxBxmRwusi/A5Oo1KpwOFzEBw
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
X-CRXEFW-Info: Please contact Ceryx for more information
X-CRXEFW-Virus: Clean
X-CRXEFW-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul,

X9.62-2005, Annex K, Security Considerations does cover topics that I have =
not seen SP 800-57.=20

Therefore, I think X9.62 would be worth mentioning in the security consider=
ations of this RFC 3279 update.

Best regards,

Dan

-----Original Message-----
From: Paul Hoffman
Sent: Sunday, May 10, 2009 3:29 PM
To: Stefan Santesson; [email-masked]
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

At 7:25 PM +0200 5/10/09, Stefan Santesson wrote:

...

>Your security considerations section does not mention FIPS 183-3 or X9.62 =
at
>all.

Correct. If you see some security considerations in either of those two doc=
umentst that aren't in SP 800-57, I'm fine with mentioning them in the Secu=
rity Considerations section; I didn't see them.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SI0R8O076191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 11:00:27 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4SI0R2C076190; Thu, 28 May 2009 11:00:27 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from cx296.800onemail.com (CX296.800onemail.com [209.171.54.154]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SI0GTG076178 for ; Thu, 28 May 2009 11:00:27 -0700 (MST) (envelope-from [email-masked])
Received: from ex13-n01.exchserver.com ([192.168.162.157]) by cx296.800onemail.com (8.13.8/8.13.8) with ESMTP id n4SHxx1s029591; Thu, 28 May 2009 13:59:59 -0400
Received: from EX41-2.exchserver.com ([169.254.4.162]) by ex13-n01.exchserver.com ([192.168.162.160]) with mapi; Thu, 28 May 2009 13:59:59 -0400
From: Daniel Brown
To: Paul Hoffman , "[email-masked]"
Date: Thu, 28 May 2009 13:59:57 -0400
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Thread-Topic: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Thread-Index: AcnQx++na6Ski+Z4SLa7yHGr0R1SPQO9JgyQ
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
X-CRXEFW-Info: Please contact Ceryx for more information
X-CRXEFW-Virus: Clean
X-CRXEFW-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul,

Regarding your comment 3) below about validation requirements, I suggest th=
at this RFC 3279 update mandate SHA2 as a "SHOULD" (rather than a MUST as i=
t is in the WGLC draft). =20

Not making it a MUST avoids making existing implementations non-conformant.=
Making it a SHOULD alerts implementers to the security issues and to the =
NIST compliance/interoperability issues.

Regarding your comment 2) below about key sizes and lifetimes, I suggest th=
is RFC 3279 update make the associated NIST recommendations a SHOULD. Agai=
n, this is for security reasons and better NIST compliance/interoperability=
issues. =20

Generally, the DSA/ECDSA and SHA-1/2 algorithms come from NIST and ANSI, an=
d have some normative security requirements about key sizes. Completely dr=
opping some of the normative security requirements should require strong ju=
stification.=20

Best regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On=
Behalf Of Paul Hoffman
Sent: Saturday, May 09, 2009 12:51 PM
To: [email-masked]
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

...

2) Mandating key sizes and lifetimes is inappropriate in this document

RFC 3279 does not mandate key sizes; this draft does. Worse, this draft rel=
ies on the tortured logic in NIST SP 800-57 Part 1 that conflates multiple =
effective key strengths onto a single hash algorithm. The logic that NIST u=
sed in making that decision had to do with the difficulty of upgrading a di=
sparate US government infrastructure over a long period of time. That's fin=
e for NIST, but an IETF standard should not make such compromises. It is ju=
st wrong to update an existing algorithm RFC by adding a new set of restric=
tions, but only for some of the algorithms, namely the new ones being added=
.

The key strength matching and lifetime mandates should be ripped out. It is=
fine to have a non-normative reference to NIST SP 800-57 Part 1 and NIST S=
P 800-78-1 in the Security Considerations to help people find the documents=
.

3) Adding new validation requirements at this late date is wrong

RFC 3279 specified DSA only with SHA-1; this document adds DSA with SHA-2. =
However, this document now makes all implementations of RFC 3279 that could=
validate DSA non-conformant. It is wrong to add new algorithms and then pu=
nish existing implementations by labelling them non-conformant to a long-es=
tablished standard.

Following the three guidelines above, the meat of the document is reduced t=
o that below.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QLVjd2072454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 14:31:45 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QLVjwe072453; Tue, 26 May 2009 14:31:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QLViiI072446 for ; Tue, 26 May 2009 14:31:45 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id C4F243A69B5; Tue, 26 May 2009 14:30:01 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-tac-04.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Tue, 26 May 2009 14:30:01 -0700 (PDT)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

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.

Title : Traceable Anonymous Certificate
Author(s) : S. Park, H. Park, Y. Won, J. Lee, S. Kent
Filename : draft-ietf-pkix-tac-04.txt
Pages : 32
Date : 2009-5-26

Public Key Infrastructure (PKI) provides a powerful means of
authenticating individuals, organizations, and computers(e.g.,
web servers). However, when individuals use certificates to
access resources on the public Internet, there are legitimate
concerns about personal privacy, and thus there are increasing
demands for privacy enhancing techniques on the Internet.

In a PKI, an authorized entity such as a certification Authority
(CA) or a Registration Authority (RA) may be perceived, from a
privacy perspective, as a "big brother," even when a CA issues a
certificate containing a Subject name that is a pseudonym. This
is because such entities can always map a pseudonym in a
certificate they issued to the name of the real user to whom it
was issued. This document defines a practical architecture and
protocols for offering privacy for a user who requests and uses
an X.509 certificate containing a pseudonym, while still retaining
the ability to map such a certificate to the real user who
requested it. The architecture is compatible with IETF certificate
request formats such as PKCS10 [3]and CMC[4]. The architecture
separates the authorities involved in issuing a certificate: one
for verifying ownership of a private key (Blind Issuer) and the
other for validating the contents of a certificate (Anonymity
Issuer). The end-entity(EE) certificates issued under this model
are called Traceable Anonymous Certificates (TACs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-tac-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-pkix-tac-04.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QDki92033376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 06:46:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QDkiDO033375; Tue, 26 May 2009 06:46:44 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QDkhMY033369 for ; Tue, 26 May 2009 06:46:43 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id 66CB53A6D05; Tue, 26 May 2009 06:45:01 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-asn1-translation-00.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Tue, 26 May 2009 06:45:01 -0700 (PDT)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

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.

Title : ASN.1 Translation
Author(s) : C. Wallace, C. Gardiner
Filename : draft-ietf-pkix-asn1-translation-00.txt
Pages : 22
Date : 2009-05-26

Abstract Syntax Notation One (ASN.1) is widely used throughout the
IETF security area and has been for many years. Some specifications
were written using a now deprecated version of ASN.1 and some were
written using the current version of ASN.1. Not all ASN.1 compilers
support both older and current syntax. This document is intended to
provide guidance to specification authors and to implementers
converting ASN.1 modules written using one version of ASN.1 to
another version without causing changes to the "bits on the wire".
This document does not provide a comprehensive tutorial of any
version of ASN.1. Instead, it addresses ASN.1 features that are used
in IETF security area specifications with focus on items that vary
with the ASN.1 version.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-asn1-translation-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-pkix-asn1-translation-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QCkijD027917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 05:46:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QCkio5027916; Tue, 26 May 2009 05:46:44 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QCkhZB027908 for ; Tue, 26 May 2009 05:46:44 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id A11073A70CC; Tue, 26 May 2009 05:45:01 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-ta-format-03.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Tue, 26 May 2009 05:45:01 -0700 (PDT)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

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.

Title : Trust Anchor Format
Author(s) : R. Housley, et al.
Filename : draft-ietf-pkix-ta-format-03.txt
Pages : 17
Date : 2009-05-26

This document describes a structure for representing trust anchor
information. A trust anchor is an authoritative entity represented
by a public key and associated data. The public key is used to
verify digital signatures and the associated data is used to
constrain the types of information or actions for which the trust
anchor is authoritative. The structures defined in this document are
intended to satisfy the format-related requirements defined in Trust
Anchor Management Requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-pkix-ta-format-03.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PK6tRO042171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 13:06:55 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4PK6t0p042170; Mon, 25 May 2009 13:06:55 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PK6g4X042141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 May 2009 13:06:54 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 41748 invoked from network); 25 May 2009 17:56:05 -0000
Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 25 May 2009 17:56:05 -0000
Received: (qmail 99041 invoked from network); 25 May 2009 17:55:58 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 May 2009 17:55:58 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Mon, 25 May 2009 19:55:53 +0200
Subject: Re: WGLCs, etc.
From: Stefan Santesson
To: Stephen Kent ,
Message-ID:
Thread-Topic: WGLCs, etc.
Thread-Index: AcndYgu5RwNjwy7mN0OIGKltvHP5VA==
In-Reply-To:
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Good summary Steve,

> Anythig else?

Yes,

I think we can conclude the WGLC also on the TAC document as well.

I think the authors have addressed the comments to a reasonable extent given
that this is an experimental document.

I think this document is ready for IESG review once the newly submitted
draft 04 is available.

I'm the cognizant WG co-chair for this document.

/Stefan

On 09-05-25 5:21 PM, "Stephen Kent" wrote:

>
> Folks,
>
> I have been on vacation and out of the country for most of the last 8
> weeks, so I have fallen behind on various WG administrative matters.
> I apologize for that. (In fact, I am out of the country again,
> attending the LACNIC meeting in Panama this week, and taking another
> week of vacation in Panama, but I'll try to make some progress while
> I'm here.)
>
> Here is where I think we are relative to various matters:
>
> Meeting minutes are final.
>
> Cert-image has been accepted as a new WG item.
>
>
> Concluded WGLCs:
>
> - Authority Clearance: done a while ago, and I am the
> cognizant WG co-chair for this document. One minor edit needs to be
> done, but it does not merit a second WGLC. I hope to send the writeup
> to the IESG this week.
>
> - PRQP: this WGLC closed a while ago, but max published
> version 3 afterwards, with some changes motivated by initial
> deployment experiences. Max sent a message on 4/24 asking for
> comments, and I saw no responses. So, I will consider the WGLC to
> still be valid, unless there are objections.
>
> - Trust anchor format: Carl will make a minor edit to the
> ASN.1 module and publish a new version. This version will be sent to
> the IESG for review. I am the cognizant WG co-chair for this document.
>
> - Other-certs: Stephe Farrell will make a minor edit in
> AUTH-48. Stefan is the cognizant WG co-chair for this document.
>
> - sha2-dsa-ecdsa: Several changes are needed to address
> comments that arose during WGLC. The authors need to publish a
> revised version of the document. Paul and Stefan, who provided
> critical comments will review the new version and indicate if they
> are satisfied. If so, we'll consider the WGLC to have completed
> successfully.
>
>
> The straw poll on the status of the new ASN.1 closed on 5/22. There
> were 9 votes for OBSOLETE, and 16 (including me) for UPDATE. This
> info will be provided to Tim as per his request.
>
>
> Anythig else?
>
> Steve
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PFMeW8008889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 08:22:40 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4PFMelk008888; Mon, 25 May 2009 08:22:40 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PFMbj7008877 for ; Mon, 25 May 2009 08:22:39 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[168.77.196.182]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M8c0a-00019T-F4 for [email-masked]; Mon, 25 May 2009 11:22:36 -0400
Mime-Version: 1.0
Message-Id:
Date: Mon, 25 May 2009 11:21:11 -0400
To: [email-masked]
From: Stephen Kent
Subject: WGLCs, etc.
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Folks,

I have been on vacation and out of the country for most of the last 8
weeks, so I have fallen behind on various WG administrative matters.
I apologize for that. (In fact, I am out of the country again,
attending the LACNIC meeting in Panama this week, and taking another
week of vacation in Panama, but I'll try to make some progress while
I'm here.)

Here is where I think we are relative to various matters:

Meeting minutes are final.

Cert-image has been accepted as a new WG item.

Concluded WGLCs:

- Authority Clearance: done a while ago, and I am the
cognizant WG co-chair for this document. One minor edit needs to be
done, but it does not merit a second WGLC. I hope to send the writeup
to the IESG this week.

- PRQP: this WGLC closed a while ago, but max published
version 3 afterwards, with some changes motivated by initial
deployment experiences. Max sent a message on 4/24 asking for
comments, and I saw no responses. So, I will consider the WGLC to
still be valid, unless there are objections.

- Trust anchor format: Carl will make a minor edit to the
ASN.1 module and publish a new version. This version will be sent to
the IESG for review. I am the cognizant WG co-chair for this document.

- Other-certs: Stephe Farrell will make a minor edit in
AUTH-48. Stefan is the cognizant WG co-chair for this document.

- sha2-dsa-ecdsa: Several changes are needed to address
comments that arose during WGLC. The authors need to publish a
revised version of the document. Paul and Stefan, who provided
critical comments will review the new version and indicate if they
are satisfied. If so, we'll consider the WGLC to have completed
successfully.

The straw poll on the status of the new ASN.1 closed on 5/22. There
were 9 votes for OBSOLETE, and 16 (including me) for UPDATE. This
info will be provided to Tim as per his request.

Anythig else?

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4NMZDQY029251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 15:35:13 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4NMZDt5029250; Sat, 23 May 2009 15:35:13 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4NMZ0gZ029234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 23 May 2009 15:35:11 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.3]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1M7zns-0007Hu-Cf; Sat, 23 May 2009 18:34:57 -0400
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Sat, 23 May 2009 10:37:45 -0400
To: Stephen Farrell
From: Stephen Kent
Subject: Re: WG Last Call on draft-ietf-pkix-tac-03
Cc: Stefan Santesson , [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

A
>...
>Well, I think there may be a few ways to go at it that differ
>from the current draft. My concern was more with the communications
>paths used rather than an objection to the use of the threshold
>scheme.

But, your suggestion of direct communication only between the BI and
the user causes the problems I noted, unless we add the encryption
mechanism suggested by David Cooper, which itself is an example of
added complexity :-)

>...
>
>I'm not sure I follow that - how does the scheme show the CA is taking
>precautions? The entities involved could still collude regardless of the
>scheme, or could honestly not collude even if no threshold scheme were
>used.

It is true that an honest TAC CA could do all of this even without
the AI/BI split. That's not the issue. The motivation for having the
AI/BI split is to make it easier to show to a third party (and to
convince prospective users) that IF the TAC CA operates as described,
then it is providing the conditional anonymity indicated. The details
here are ones that a TAC CA would cite in its CPS. The split signing
and threshold signature mechanism are ones that, if implemented
properly, provide reasonable assurance of the desired separation. An
auditor or evaluator of a TAC CA can verify that these mechanisms are
being used, as part of an assessment.

The value of a document like this is that it provides those who
perform audits (assessments, evaluations, ...) a guideline against
which to measure a CA. This is analogous to what we did with RFC
3647, providing attorneys with a guideline for CP/CPS construction.

>Deference? In the IETF? That's optimistic. ;-)

yes, but it is also reasonable. we have accorded some level of
deference to folks who are more expert in a specific area that we
are, the CP/CPS document and its reliance on lawyers is a good
example.

>However, since this is aimed at experimental I'd be fine if some
>text were added that pointed out the alternatives and the differences
>between the various flows. That way, the issue could be revisited
>if/when the spec were put on the standards track.

I think my co-authors at KISA have made enough revisions at this
stage to satisfy comments. If someone wants to write another I-D that
proposes alternatives, they are free to do so. After all, as you
noted, this is a document declared to be experimental, so there is no
harm in having more that one approach. If we find that one or more
real CAs offer TAC services and choose to follow the model here, that
supports this as a viable model. If no CAs do so, or if they object
to the model and propose alternatives, that will support the
contention that other approaches are superior.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4N8bspd073523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 01:37:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4N8bsqO073522; Sat, 23 May 2009 01:37:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from google.com (p3059-ipngn1105marunouchi.tokyo.ocn.ne.jp [118.22.222.59]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4N8bg9R073508 for ; Sat, 23 May 2009 01:37:53 -0700 (MST) (envelope-from [email-masked])
Received: from [187.92.78.159] (HELO google.com) by flowery-sappoison.net; Sat, 23 May 2009 17:37:46 +0900
Message-ID: <00000005D219438266439455>
Reply-To: Tatyanna Ray <[email-masked]>
From: Tatyanna Ray
To:
Subject: =?windows-1251?B?U2xlZXAgTmF0dXJhbGx5IGFuZCBXYWtlIFVwIFJlZnJlc2hlZA==?=
Date: Sat, 23 May 2009 17:37:46 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1251"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

U3R1ZGllcyBoYXZlIHNob3duIHRoYXQgaW5zdWZmaWNpZW50IHNsZWVwIGlzIHRoZSBsZWFkaW5nIGNhdXNlIGZvciBzdHJlc3MgcmVsYXRlZCBkaXNlYXNlcy4gWW91ciA3LTkgaG91cnMgb2YgZG93bnRpbWUgZXZlcnkgbmlnaHQgYWN0dWFsbHkgaGVscCB5b3UgZWxpbWluYXRlIHN0cmVzcywgcmVnZW5lcmF0ZSB5b3VyIGVuZXJneSBsZXZlbHMsIHJlcGFpciBhbnkgZGFtYWdlcyBpbiB5b3VyIGJvZHkgYW5kIHJlY292ZXIgb3IgZmlnaHQgb2ZmIGRpc2Vhc2VzLiBTdHJlc3MgYW5kIGEgbGFjayBvZiBzbGVlcCBjYW4gY2F1c2UgYSB2YXJpZXR5IG9mIGhlYWx0aCByZWxhdGVkIHByb2JsZW1zLCBtYW55IG9mIHdoaWNoIGNhbiBiZSBzZXJpb3VzLg0KDQpNYW55IHBlb3BsZSBzdWZmZXIgZnJvbSBzbGVlcGluZyBkaXNvcmRlcnMgc3VjaCBhcyBkaWZmaWN1bHR5IGZhbGxpbmcgYXNsZWVwLCBzbGVlcGluZyB0aHJvdWdoIHRoZSBuaWdodCBhbmQgZXZlbiBtb3JlIGNvbW1vbmx5IGEgbGFjayBvZiBxdWFsaXR5IHNsZWVwLiBTbGVlcCBpcyBub3Qgb25seSBuZWNlc3NhcnkgaW4gcXVhbnRpdHksIGJ1dCBldmVuIG1vcmUgaW1wb3J0YW50bHkgcXVhbGl0eS4gRG8geW91IHNsZWVwIHRocm91Z2ggdGhlIG5pZ2h0IGJ1dCB3YWtlIHVwIGV4aGF1c3RlZD8gUGVyaGFwcyB5b3UgYXJlIGdldHRpbmcgdGhlIG51bWJlciBvZiBob3VycyB5b3UgbmVlZCwgYnV0IG5vdCB0aGUgZGVlcCBzbGVlcCB5b3UgbmVlZCBqdXN0IGFzIG11Y2ghIFdoYXQgcGVvcGxlIGRvbid0IGtub3cgdGhhdCB0aGlzIHByb2JsZW0gaXMgbm93IGVhc2lseSBzb2x2ZWQhDQoNCk1lbGF0cm9sIHdpbGwgaGVscCB5b3UgZmFsbCBhc2xlZXAgZmFzdGVyLCBkZWVwZXIgYW5kIHByb3ZpZGVzIHlvdSB3aXRoIGEgYmV0dGVyIHF1YWxpdHkgc2xlZXAgc28geW91IGNhbiBlbmpveSBhIHByb2R1Y3RpdmUgZGF5ISBUaGVyZSBpcyBubyBuZWVkIHRvIGRlcGVuZCBvbiBjYWZmZWluZSB0byBnZXQgeW91IGdvaW5nIGluIHRoZSBtb3JuaW5nOyB0aGVyZSBpcyBubyBuZWVkIHRvIHB1dCB1cCB3aXRoIG1vb2Qgc3dpbmdzIGFuZCBhbnhpZXR5IGR1ZSB0byBhIGxhY2sgb2Ygc2xlZXAhDQoNCkZvciBtb3JlIGRldGFpbHMgYW5kIGluZm9ybWF0aW9uLCBzZW5kIHVzIGEgcmVxdWVzdCBhdCBjaHJpc3RpbmUuYWJzYWxvbjE1MTg2QGdtYWlsLmNvbSBhbmQgd2Ugd2lsbCBnZXQgYmFjayB0byB5b3Ugc2hvcnRseS4NCg0KQmVzdCByZWdhcmRzLA0KU2xlZXAgU29sdXRpb25zIE1hcmtldGluZwoKCgoKCgoKCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpUaGlzIGVtYWlsIGhhcyBiZWVuIHdyaXR0ZW4gYW5kIHByb3ZlZCB0byBiZSBpbiBjb21wbGlhbmNlIHdpdGggdGhlIHJlY2VudGx5IGVzdGFibGlzaGVkIGNhbi1zcGFtIGFjdCBsYXcgaW4gVVMuIFdlIGFyZSBub3QgcHJvdm9raW5nIG9yIGZvcmNpbmcgYW55IHBlcnNvbiBpbiBhbnkgd2F5IHRvIHBhcnR!
pY2lwYXRlIGluIG91ciBwcm9ncmFtcy4gVG8gcGFydGljaXBhdGUgaXMgeW91ciBvd24gZGVjaXNpb24gYW5kIHlvdSBjYXJyeSB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGFraW5nIGZ1cnRoZXIgcGFydCBpbiB0aGlzIHByb21vdGlvbi4gQW55d2F5LCBpZiB5b3UgZG9uJ3Qgd2FudCB0byByZWNlaXZlIG1vcmUgZ29vZCBvZmZlcnMgZnJvbSB1cywgeW91IGNhbiBzaW1wbHkgVW5zdWJzY3JpYmUgYnkgc2VuZGluZyB1cyBhIG5vdGlmaWNhdGlvbiBlbWFpbCB0byBnZXQub3V0X29mX3RoZV9saXN0QHlhaG9vLmNvbSB3aXRoIGEgbWFpbC1zdWJqZWN0IGFuZCB0ZXh0ICJVbnN1YnNjcmliZSBtZSIsIGFuZCB3ZSB3aWxsIGdldCB5b3VyIGVtYWlsIG91dCBvZiBvdXIgbGlzdCB3aXRoaW4gMTAgZGF5cy4KClRoaXMgbWVzc2FnZSBpcyBTVFJJQ1RMWSBDT05GSURFTlRJQUwgYW5kIGlzIHNvbGVseSBmb3IgdGhlIGluZGl2aWR1YWwgb3Igb3JnYW5pc2F0aW9uIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBQUklWSUxFR0VEIGFuZCBDT05GSURFTlRJQUwgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgaXRzIGNvbnRlbnRzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgeW91IHNob3VsZCBub3QgcmVhZCwgY29weSwgZGlzdHJpYnV0ZSwgZGlzY2xvc2Ugb3Igb3RoZXJ3aXNlIHVzZSB0aGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlbWFpbC4gRW1haWwgbWF5IGJlIHN1c2NlcHRpYmxlIHRvIGRhdGEgY29ycnVwdGlvbiwgaW50ZXJjZXB0aW9uIGFuZCB1bmF1dGhvcmlzZWQgYW1lbmRtZW50LCBhbmQgd2UgZG8gbm90IGFjY2VwdCBsaWFiaWxpdHkgZm9yIGFueSBzdWNoIGNvcnJ1cHRpb24sIGludGVyY2VwdGlvbiBvciBhbWVuZG1lbnQgb3IgdGhlIGNvbnNlcXVlbmNlcyB0aGVyZW9mIG9yIHlvdXIgcmVsaWFuY2Ugb24gYW55IGluZm9ybWF0aW9uIGNvbnRhaW5lZCB0aGVyZWluIGlmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIElmIHlvdSBhcmUgbm90IGludGVyZXN0ZWQgaW4gdGhlIG9mZmVyZWQgcHJvbW90aW9ucywgcGxlYXNlIGp1c3QgZG9uJ3QgYW5zd2VyLiBJZiB5b3UgdGhpbmsgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGFuZCBpdHMgY29udGVudHMgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIGNvbXB1dGVyLCBvciBmb2xsb3cgdGhlIHVuc3Vic2NyaWJpbmcgcHJvY2VkdXJlIHNob3duIGFib3ZlLgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCQk=

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4MKVKlg033739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2009 13:31:20 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4MKVKqL033738; Fri, 22 May 2009 13:31:20 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4MKVJpa033731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 May 2009 13:31:20 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
Date: Fri, 22 May 2009 13:31:17 -0700
To: [email-masked]
From: Paul Hoffman
Subject: Fwd: Last Call: draft-ietf-sip-eku (Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates) to Proposed Standard
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

>To: IETF-Announce
>From: The IESG
>Subject: Last Call: draft-ietf-sip-eku (Using Extended Key Usage (EKU)
> for Session Initiation Protocol (SIP) X.509 Certificates) to
> Proposed Standard
>Date: Fri, 22 May 2009 11:11:51 -0700 (PDT)
>Cc: [email-masked]
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.1.9
>Reply-To: [email-masked]
>List-Id: "IETF announcement list. No discussions."
>Sender: [email-masked]
>
>The IESG has received a request from the Session Initiation Protocol WG
>(sip) to consider the following document:
>
>- 'Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP)
> X.509 Certificates '
> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2009-06-05. Exceptionally,
>comments may be sent to [email-masked] instead. In either case, please
>retain the beginning of the Subject line to allow automated sorting.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-05.txt
>
>
>IESG discussion can be tracked via
>https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16567&rfc_flag=0

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4JNXAuZ002136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 May 2009 16:33:10 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4JNXAuX002135; Tue, 19 May 2009 16:33:10 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4JNWwN2002106 for ; Tue, 19 May 2009 16:33:09 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.28.172.226]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M6Ynp-00086z-EJ; Tue, 19 May 2009 19:32:57 -0400
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Tue, 19 May 2009 19:32:48 -0400
To: "McCann Peter-A001034"
From: Stephen Kent
Subject: Re: Gen-ART Review of draft-ietf-pkix-3281update-05
Cc: , , , ,
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 3:00 PM -0400 5/19/09, McCann Peter-A001034 wrote:
>I have been selected as the General Area Review Team (Gen-ART) reviewer
>for this draft (for background on Gen-ART, please see
>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html
> ).
>
>Please wait for direction from your document shepherd or AD before
>posting a new version of the draft.
>
>Document: draft-ietf-pkix-3281update-05
>Reviewer: Pete McCann
>Review Date: 19 May 2009
>IESG Telechat date: 21 May 2009
>
>Summary: Ready, still 2 nits.
>
>Major issues: none
>Minor issues: none
>Nits/editorial comments:
>
>The acronym CA (Certificate Authority) should be spelled out
>in the Terminology section.
>
>Section 7.1, there is still a typo: s/withing/within

Peter,

I agree that acronyms should be expanded on first use, but the
acronym CA expands to certification (not certificate) authority.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4JMlUbk001204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 May 2009 15:47:30 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4JMlUSY001202; Tue, 19 May 2009 15:47:30 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4JMlMt2001187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 May 2009 15:47:28 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 17757 invoked from network); 19 May 2009 22:48:30 -0000
Received: from s34.loopia.se (HELO s60.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 19 May 2009 22:48:30 -0000
Received: (qmail 40902 invoked from network); 19 May 2009 22:48:21 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 May 2009 22:48:21 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Wed, 20 May 2009 00:48:20 +0200
Subject: Re: cert image I-D
From: Stefan Santesson
To: Phillip Hallam-Baker , Stephen Kent
CC:
Message-ID:
Thread-Topic: cert image I-D
Thread-Index: AcnY0+gSeLX1UYVy/U2hSwL4Y8Vv+Q==
In-Reply-To:
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Phil,

What you suggest is really interesting.

It is however substantially different to have the validation infrastructure
provide presentation images instead of the issuer (CA), but I can also the
the benefits as it would allow retroactive deployment for existing
certificates.

I would not make this a change of approach however, but list it as possible
complementary work that we should discuss as a possible follow up.

/Stefan

On 09-05-16 4:45 AM, "Phillip Hallam-Baker" wrote:

>=20
> I think this is usefull work to look at.
>=20
> One change of approach I would suggest is to allow any extensions to
> be expressed in either a cert itself or an OCSP response. That allows
> for considerably greater flexibility in deployment as we discovered
> was necessary during deployment of EV certs.
>=20
> Think about the problem of enabling EV on every single web site of a
> large bank at the same time, and the cost of customer service calls if
> you do it piecemeal.
>=20
> On Wed, May 13, 2009 at 1:56 PM, Stephen Kent wrote:
>>=20
>> Folks,
>>=20
>> I have reviewed the discussion on the list re Stefan's cert image propos=
al.
>> While there were comments for and against, the positive comments, especi=
ally
>> from folks who are in a position to make use of this feature, were
>> persuasive.
>>=20
>> We will proceed with this a a new PKIX WG work item. =A0This is not a
>> guarantee that the WG will approve a document, but rather that we will
>> explore approaches to achieving the goals described by Stefan and try to
>> come to consensus on a specific technical approach. We can decide later
>> whether this is standards track, experimental or even informational.
>>=20
>> Steve
>>=20
>>=20
>=20
>=20

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4G8DYfo015717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 May 2009 01:13:34 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4G8DYqg015716; Sat, 16 May 2009 01:13:34 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4G8DMvq015693 for ; Sat, 16 May 2009 01:13:33 -0700 (MST) (envelope-from [email-masked])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) (authenticated as u18116613) id 49CCDA070077ADAA; Sat, 16 May 2009 10:13:18 +0200
Message-ID:
From: "Anders Rundgren"
To: "Bajaj, Siddharth" , "Stefan Santesson" , "Trevor Freeman" , , "Stephen Kent"
References: <[email-masked]>
In-Reply-To:
Subject: Reference design. Re: cert image I-D
Date: Sat, 16 May 2009 10:14:25 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi Guys,

Siddharth wrote:
>However, we think that this is low-hanging fruit- where we can improve
>the experience of technology (X.509,PKI) that is already deployed
>without re-inventing a lot of the stack.

It is of course up to you to decide, but AFAICT there is no low-hanging
fruit when it comes to upgrading user-agents.

That is, if you want to see this running (ever) you should also consider
the adoption which IMHO should begin with enabling the functionality
in browsers. Contributing code to Mozilla would be a good start
because then you get a reference design which I think is badly needed.

I'm personally going to cater for the adoption of KeyGen2[*] by making
(if I have time...) the implementation available as Open Source for WebKit
which has some 50% of the smart phone market share. An advantage with
the mobile phone is that you avoid the unwieldy middleware situation in
PCs where the platform "competes" for the GUI with third-party middleware
which makes the user-experience quite horrible. The tremendous success
of the iPhone indicates that there is more room for GUI innovation in this
space than in PCs. As I have already said, the need for cert-images in
mobiles phones is also much bigger than on PCs because they can host
multiple credentials and also have limited screen real estate.

It will take 5 years or more to see who got it right :-)
The biggest hurdle is still status quo.

Anders

*] KeyGen2 is just one of the components of a completely revised
PKI client, loosly tailored after already established schemes in the EU.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4G2js7k001258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2009 19:45:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4G2jskW001257; Fri, 15 May 2009 19:45:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4G2jhPJ001248 for ; Fri, 15 May 2009 19:45:53 -0700 (MST) (envelope-from [email-masked])
Received: by gxk24 with SMTP id 24so6347121gxk.10 for ; Fri, 15 May 2009 19:45:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/AD28OA4rOBpHeL1hajfKagPp12/8WOVcvhlb9n3p3M=; b=QxPv4U7Pct6rqxZloaosWDiXPfnQFIbjCNWura9/PAtWnGK0pZnsFLo6V7Gpwc6Frc hQpOylEeApJKFsaIO+HmVuJwm1D+PhnCFTxx5bmIMjXmBE+Rz6aDiUpv1s0Gk5gw4RLF mZIBKglWLL0Ae6XO2LhQTs62gOchRj7PZyeUs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YqRnXTpFbTNnaRGCn5tgmApZoo4QUy7k07n/JqKwH16Ra7wXDs/UgsX6c+Aco2TfVa zKigXeNLMAP8ZzNyEfu9InbGkNuVtYl6to+TNzft5NV5FEB5eurTbgpuhIjsvIqgB9A/ lIu7gwrJY7RTY6P2n2BD9Bm/f4wYjfiLoC95Q=
MIME-Version: 1.0
Received: by 10.90.98.13 with SMTP id v13mr3413196agb.18.1242441942359; Fri, 15 May 2009 19:45:42 -0700 (PDT)
In-Reply-To:
References:
Date: Fri, 15 May 2009 22:45:42 -0400
Message-ID:
Subject: Re: cert image I-D
From: Phillip Hallam-Baker
To: Stephen Kent
Cc: [email-masked]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I think this is usefull work to look at.

One change of approach I would suggest is to allow any extensions to
be expressed in either a cert itself or an OCSP response. That allows
for considerably greater flexibility in deployment as we discovered
was necessary during deployment of EV certs.

Think about the problem of enabling EV on every single web site of a
large bank at the same time, and the cost of customer service calls if
you do it piecemeal.

On Wed, May 13, 2009 at 1:56 PM, Stephen Kent wrote:
>
> Folks,
>
> I have reviewed the discussion on the list re Stefan's cert image proposa=
l.
> While there were comments for and against, the positive comments, especia=
lly
> from folks who are in a position to make use of this feature, were
> persuasive.
>
> We will proceed with this a a new PKIX WG work item. =A0This is not a
> guarantee that the WG will approve a document, but rather that we will
> explore approaches to achieving the goals described by Stefan and try to
> come to consensus on a specific technical approach. We can decide later
> whether this is standards track, experimental or even informational.
>
> Steve
>
>

--=20
--=20
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4FMxF2R089628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2009 15:59:15 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4FMxFah089627; Fri, 15 May 2009 15:59:15 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4FMx2Iw089615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 15 May 2009 15:59:13 -0700 (MST) (envelope-from [email-masked])
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n4FMUu2r019413; Fri, 15 May 2009 15:30:56 -0700
Received: from MOU1WNEXMB03.vcorp.ad.vrsn.com ([10.25.13.156]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 May 2009 15:58:34 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: cert image I-D
Date: Fri, 15 May 2009 15:58:40 -0700
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: cert image I-D
Thread-Index: AQHJ0/eNIWsS/XiFnkad5cfkOyeN+ZAU40+A//+onjCAABR3bYABVkqQ
References: <[email-masked]>
From: "Bajaj, Siddharth"
To: "Stefan Santesson" , "Trevor Freeman" , "Anders Rundgren" , , "Stephen Kent"
X-OriginalArrivalTime: 15 May 2009 22:58:34.0624 (UTC) FILETIME=[ACC3C000:01C9D5B0]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi Anders/Trevor,

Thanks for emails and thoughts -=20

Most likely multiple identity/authentication technologies will co-exist
in the=20
Foreseeable future - X.509 certificates, Information Cards, and whatever
else.

What we are trying to do is to provide a building-block that user-agents
can leverage=20
to provide a better user experience around X.509 certs.

I understand that the Information Cards are not using TLS/SSL auth - the
analogy
that I was trying to drive in my earlier email was that - the credential
selector=20
UI for Information Cards already has the capability to display card
images.=20
this extension will enable client platforms to use a similar user
interface=20
paradigm for certificate selection, if they choose to implement it. This
will=20
enable the client to provide comsistent/similar visual abstraction to
the user=20
irrespective of the underlying technology.=20

I want to acknowledge that this is not something that will solve all the
usability issues with PKI today,
However, we think that this is low-hanging fruit- where we can improve
the experience of=20
technology (X.509,PKI) that is already deployed without re-inventing a
lot of the stack.

Last but not the least, it is very likely that something like the
KeyGen2 proposal may get=20
momentum in the future and want to point out that this work can co-exist
with the new
stack that comes out of that effort.=20

Thanks,

Siddharth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Wednesday, May 13, 2009 4:40 PM
To: Trevor Freeman; Anders Rundgren; [email-masked]; Stephen Kent
Subject: Re: cert image I-D

Trevor,

Agreeing with many things I would like to add one thing.

Having spent considerable time with the information cards concept and
having been through long discussions with the information card team at
Microsoft, I can see no conflict.

Even if information card is used to provide a UI for client
certificates, this UI still need to come up with an image to represent
that certificate.

Information card has previously been a candidate for consuming RFC 3709
images and that is by no means less true if we add another more useful
image.

/Stefan

On 09-05-14 1:26 AM, "Trevor Freeman"
wrote:

>=20
> Hi Anders,
>=20
> I agree that this work faces a number of technical challenges, however

> the authors are a bunch of bright people and they will rise to meet
the challenge.
>=20
> On one point we do agree and that is the 80%+ case for web based=20
> authentication using client certificates will be via information=20
> cards. The fat lady has sung on that point. The reason that will be=20
> the case is that the authorization to access the data needs a richer=20
> set of information than that contained within the X.509 certificate=20
> alone so they need to present a set of claims e.g. a SAML token not=20
> just a certificate. As you point out, information cards already handle
the case of presenting a graphical image to the user.
>=20
> Another reason why information cards are the 80% case is that the web=20
> 2.0 standard also addresses in more detail the question of what is=20
> needed to do to access the site because the site publishes access=20
> policy via WS-Policy. The information card client knows in much=20
> greater detail what is required and therefore would not require the
user to make a choice they did not comprehend.
>=20
> That said there are other scenarios where you have the potential for=20
> client certificate authentication which are not web 2.0 based e.g.=20
> IMAP where this work may be useful.
>=20
> Trevor
>=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Anders Rundgren
> Sent: Wednesday, May 13, 2009 1:40 PM
> To: [email-masked]; Stephen Kent
> Subject: Re: cert image I-D
>=20
>=20
> I believe this effort suffers from more technical hurdles than the=20
> authors are aware of. Just defining exactly how and where in a=20
> browser's TLS client-cert-auth the image is supposed to be introduced=20
> is not trivial because there is a battle going on between the=20
> browser/OS and the vendors of card middleware for the GUI. Currently=20
> the latter often does a better job than the rather complacent browser
vendors.
>=20
> The sample given by Siddharth probably utilized some kind of=20
> application-level thingy which BTW points to another issue:
> Quite a bunch of current PKI implementations actually do not use TLS-=20
> client-cert-auth but rather use proprietary app-level authentication
schemes.
> One the few non-internal PKIs used by the USG, namely the USPTO's=20
> filing system is apparently one of these systems.
>=20
> It is also worth noting that Information Cards do not use TLS-client=20
> cert-auth even when the primary authentication is based on PKI.
> Probably MSFT drew the same conclusion as many others have before=20
> them: TLS-client-cert-auth is an ugly beast on the web, app-level=20
> authentication works better; it is at least much prettier :-)
>=20
> Although providing an "upgrade path" sounds like a good solution it=20
> often works in the opposite way by "the least common denominator
rule".
> 60% of enterprises use IE6 despite been EOLed since 5 years back!
>=20
> Time will tell, but personally I do not believe you get very far=20
> unless you take on the entire=20
> browser/keystore/provisioning/authentication space otherwise the
incentive for changing (anything) will simply be too small.
>=20
> Which is thus exactly what my counter-proposal does........
>=20
> Anders
>=20
> ----- Original Message -----
> From: "Stephen Kent"
> To:
> Sent: Wednesday, May 13, 2009 19:56
> Subject: cert image I-D
>=20
>=20
>=20
> Folks,
>=20
> I have reviewed the discussion on the list re Stefan's cert image=20
> proposal. While there were comments for and against, the positive=20
> comments, especially from folks who are in a position to make use of=20
> this feature, were persuasive.
>=20
> We will proceed with this a a new PKIX WG work item. This is not a=20
> guarantee that the WG will approve a document, but rather that we will

> explore approaches to achieving the goals described by Stefan and try=20
> to come to consensus on a specific technical approach. We can decide=20
> later whether this is standards track, experimental or even=20
> informational.
>=20
> Steve
>=20

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4FL1akL083425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2009 14:01:36 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4FL1a91083424; Fri, 15 May 2009 14:01:36 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4FL1Ziq083418 for ; Fri, 15 May 2009 14:01:36 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id 2800428C0FB; Fri, 15 May 2009 14:00:00 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-certimage-00.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Fri, 15 May 2009 14:00:01 -0700 (PDT)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

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.

Title : Internet X.509 Public Key Infrastructure: Certificate Image
Author(s) : S. Santesson, R. Housley, S. Bajaj, L. Rosenthol
Filename : draft-ietf-pkix-certimage-00.txt
Pages : 10
Date : 2009-5-14

This document specifies a method to bind a visual representation of a
certificate in the form of a certificate image to a [RFC5280] public
key certificate by defining a new otherLogos image type according to
[RFC3709].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certimage-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-pkix-certimage-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4FKOAu0081414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2009 13:24:10 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4FKOALx081413; Fri, 15 May 2009 13:24:10 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4FKNxGc081393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 May 2009 13:24:09 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.1.103] (dslstat-77-ppp-73.fastq.com [65.39.77.73] (may be forged)) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id n4FKNvja019660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 15 May 2009 13:23:58 -0700
Message-Id: <[email-masked]>
From: Michael Myers
To: [email-masked]
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: ASN.1 straw poll, take 2
Date: Fri, 15 May 2009 06:23:57 -0700
References: <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

UPDATE

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4FHM19S069181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2009 10:22:02 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4FHM1bc069179; Fri, 15 May 2009 10:22:01 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailrelay.tugraz.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4FHLmWc068791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 15 May 2009 10:22:01 -0700 (MST) (envelope-from [email-masked])
Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) by mailrelay2.tugraz.at (8.14.3/8.14.3) with ESMTP id n4FHLkln025747 for ; Fri, 15 May 2009 19:21:46 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.7.2 mailrelay2.tugraz.at n4FHLkln025747
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tugraz.at; s=mailrelay; t=1242408107; bh=sAmIKvRfHfeTwCaxRYd5Ezulg1pMwNavSgIh+ 3fFPvw=; h=Message-ID:Date:From:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=UfbZ72Ivndyc3q0M30PLTMVZ 2+UY5oU/Tyk3KQWHwhEE/DIU3CqPqMOym5uqfokl4doeeYZgZYHLFAYqaHPneDK952u dbOL3tjNjbzyZasHRspIW1cPmL35JYnMQTKB0DPr0ZWQjVByUsGdiwmh/ivGJZWR0Ci lWNk01rx2tdq0=
Received: from [129.27.152.216] (unknown [129.27.152.216]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 81B5A1067B3B6 for ; Fri, 15 May 2009 19:21:46 +0200 (CEST)
Message-ID: <[email-masked]>
Date: Fri, 15 May 2009 19:22:24 +0200
From: Kurt Dietrich
User-Agent: Thunderbird 2.0.0.21 (X11/20090310)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: ASN.1 straw poll, take 2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.94.2/9363/Fri May 15 12:51:55 2009 on thor.iaik.tugraz.at
X-Virus-Status: Clean
X-TUG-Backscatter-control: pIqwPa9cGzJgLzKpYVmAYQ
X-Spam-Scanner: SpamAssassin 3.002005
X-Spam-Score-relay: 0.0
X-Scanned-By: MIMEDefang 2.65 on 129.27.10.19
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

UPDATE

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4FGNJ97064148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2009 09:23:19 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4FGNJGN064147; Fri, 15 May 2009 09:23:19 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4FGN7Qe064112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 15 May 2009 09:23:18 -0700 (MST) (envelope-from [email-masked])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4FGIqLD026551 for ; Fri, 15 May 2009 12:18:52 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4FGN6MP181600 for ; Fri, 15 May 2009 12:23:06 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4FGL7Ur002834 for ; Fri, 15 May 2009 12:21:07 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n4FGL7MH002757; Fri, 15 May 2009 12:21:07 -0400
In-Reply-To:
To: Stephen Kent
Cc: [email-masked], [email-masked]
MIME-Version: 1.0
Subject: Re: ASN.1 straw poll, take 2
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin
Message-ID:
Date: Fri, 15 May 2009 12:23:02 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 05/15/2009 12:23:06, Serialize complete at 05/15/2009 12:23:06
Content-Type: text/plain; charset="US-ASCII"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

UPDATE

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4FDo4Kb049995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2009 06:50:04 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4FDo4JO049994; Fri, 15 May 2009 06:50:04 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4FDnrxr049969 for ; Fri, 15 May 2009 06:50:04 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id A3C399A4728; Fri, 15 May 2009 09:50:08 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id xKBW6pIyX5ik; Fri, 15 May 2009 09:49:52 -0400 (EDT)
Received: from THINKPADR52.vigilsec.com (pool-71-191-197-15.washdc.fios.verizon.net [71.191.197.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E3C199A4738; Fri, 15 May 2009 09:50:07 -0400 (EDT)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 15 May 2009 09:49:49 -0400
To: Stephen Kent , [email-masked]
From: Russ Housley
Subject: Re: ASN.1 straw poll, take 2
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

>To assist Tim in his task of deciding how to treat the new ASN.1
>documents that Jim and Paul have developed, and to separate this
>issue from the WGLC on these documents, please reply to the
>following straw poll (which will still close on 5/22):
>
> - the new ASN.1 will OBSOLETE (i.e. replace as normative)
> the OLD ASN.1 in PKIX documents
>
> - the new ASN.1 will UPDATE (i.e., coexist as a peer with)
> the OLD ASN.1 in PKIX documents
>
>Responses should just say OBSOLETE or UPDATE.

UPDATE

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4FDlmue049804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2009 06:47:48 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4FDlmn7049803; Fri, 15 May 2009 06:47:48 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4FDlaKU049793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 May 2009 06:47:47 -0700 (MST) (envelope-from [email-masked])
Received: from mailgate3.nec.co.jp ([10.7.69.160]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id n4FDlZlr016994 for ; Fri, 15 May 2009 22:47:35 +0900 (JST)
Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id n4FDlZT29349 for [email-masked]; Fri, 15 May 2009 22:47:35 +0900 (JST)
Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id n4FDlYPC004510 for ; Fri, 15 May 2009 22:47:34 +0900 (JST)
Received: from kuichi.jp.nec.com ([10.26.220.17] [10.26.220.17]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-339091; Fri, 15 May 2009 22:47:02 +0900
Received: from 08H07791 ([10.58.81.211] [10.58.81.211]) by mail.jp.nec.com with ESMTP; Fri, 15 May 2009 22:47:01 +0900
From: "Kozo FUJINO"
To:
Subject: RFC4055 : RSASSA-PSS-params
Date: Fri, 15 May 2009 22:47:01 +0900
MIME-Version: 1.0
Message-ID: <[email-masked]>
X-Mailer: Microsoft Office Outlook 11
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_02A7_01C9D5AF.0FA3B5B0"
Thread-Index: AcnVY5+3ynakdSXCRUWQeSIfXCpu8A==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------=_NextPart_000_02A7_01C9D5AF.0FA3B5B0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear members,

I have a question on RSASSA-PSS-params of RFC4055.

If all the fields of RSASSA-PSS-params take default values,
RSASSA-PSS-params would be encoded as {0x30, 0x00},
I suppose. (null SEQUENCE)

Could you please tell me if my understanding was correct?

I'm confused with the definition of rSASSA-PSS-Default-Params.
If the fields take default values, implementations MUST omit them, I suppose.
But there's the definition of rSASSA-PSS-Default-Params in the RFC.

RSASSA-PSS-params ::= SEQUENCE {
hashAlgorithm [0] HashAlgorithm DEFAULT
sha1Identifier,
maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT
mgf1SHA1Identifier,
saltLength [2] INTEGER DEFAULT 20,
trailerField [3] INTEGER DEFAULT 1 }

rSASSA-PSS-Default-Params RSASSA-PSS-Params ::= {
sha1Identifier, mgf1SHA1Identifier, 20, 1}

Best regards,
kozo
--------------------------------------------------------
Kozo FUJINO (TEL: +81-82-849-2633 FAX: +81-82-849-2643)
NEC System Technologies, Ltd.
Hiroshima, Japan

------=_NextPart_000_02A7_01C9D5AF.0FA3B5B0
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOmjCCAwMw
ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl
cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ
bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl
cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ
bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma
/MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY
8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ
KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV
9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ
W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggMoMIICkaADAgECAhA+qlTerNRoazsbOUVJ
TBomMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl
ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wNTEwMDQwMDAw
MDBaFw0xNTEwMDMyMzU5NTlaMGgxHDAaBgNVBAoTE1ZlcmlTaWduIEphcGFuIEsuSy4xHzAdBgNV
BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxJzAlBgNVBAMTHlZlcmlTaWduIEphcGFuIENsYXNz
IDIgQ0EgLSBHMjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA5JsvD0+KUQS2rzJlTe4hmbmF
LWy9FpXMdbmd0UL4Lgjcx6XJ3eFBD/ikQDECGQy2s0LVLeJIqTXIl5exip9Gfuts2flFuYwQH+nz
6bYyHMeVa3tV1i6unJt5LvvjWaloa45XFRPDRKoOce7PXeSo7w10krfxv3SuL4zXWZYG5gkCAwEA
AaN5MHcwDAYDVR0TBAUwAwEB/zA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9wY2EyLWcyLmNybDALBgNVHQ8EBAMCAQYwJAYDVR0RBB0wG6QZMBcxFTATBgNVBAMTDEFm
ZlNDQzItMS0yMTANBgkqhkiG9w0BAQUFAAOBgQA9mTgsTNkcwdPj6gStaj5dN++dVdOJ9eTx2JL5
k7UO2JXRo4W4MpDaDlPQLK2PKlD7rwN8u1MMRJqBLGDYS2q90w21EahEqks2vM4wwcngkI2JOo29
Xl3YX1fs9yUJoFQgK/eEsukQUfzqFm0uNS0dB3dTGoL6kfB0m1G3xgQRTzCCBAkwggNyoAMCAQIC
EC3oz0Aci2KA6fbSWP7SPlwwDQYJKoZIhvcNAQEFBQAwaDEcMBoGA1UEChMTVmVyaVNpZ24gSmFw
YW4gSy5LLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEnMCUGA1UEAxMeVmVyaVNp
Z24gSmFwYW4gQ2xhc3MgMiBDQSAtIEcyMB4XDTA3MTExOTAwMDAwMFoXDTEyMTExODIzNTk1OVow
geYxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE9MDsGA1UECxM0VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvLmpw
L3JwYSAoYykwNzE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNj
cmliZXIgQ0ExMzAxBgNVBAMTKk5FQyBHcm91cCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBTTUlN
RSBHMjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvfQ0r1UA+dar8d1+/5HcgHtAt8A9gTTG
Cw13bryEGY7R4gI97HtaY4U+DamaLSbrWeUOYfyR8Y8ysWnAY7yck3Krjh9o5kvUllGtwE0X5cqa
zBdsLSDAlGHsWqa+HE6luhPLa3vtev2iBz2l6IfprnxFtSSfhpeGc6bQRSht9qsCAwEAAaOCATMw
ggEvMBIGA1UdEwEB/wQIMAYBAf8CAQAwdAYDVR0gBG0wazBpBgtghkgBhvhFAQcXAjBaMCoGCCsG
AQUFBwIBFh5odHRwczovL3d3dy52ZXJpc2lnbi5jby5qcC9jcHMwLAYIKwYBBQUHAgIwIBoeaHR0
cHM6Ly93d3cudmVyaXNpZ24uY28uanAvcnBhMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9jcmwu
dmVyaXNpZ24uY28uanAvVlNKX0MyQ0FfRzJfQ1JMLmNybDAOBgNVHQ8BAf8EBAMCAQYwEQYJYIZI
AYb4QgEBBAQDAgEGMCEGA1UdEQQaMBikFjAUMRIwEAYDVQQDEwlDMUMyLTEtNDEwHQYDVR0OBBYE
FPsxd4D2b3RLvmLzv2oQ4Y5LmXuzMA0GCSqGSIb3DQEBBQUAA4GBAFr6givYdv5XMhtJoI5drUY5
xfwRm3x1Cwxz1PtisrgICNgr/L3H/x8cnHeIi+Yoe+xAsxEIJluJ4Cmp36XVoTL1eBPKITGPHANp
Sb/xP1npqhwzRewmYMAjmS//gfmibwgigHXeoi6qe+rExcoURsx85x/C3CE8nj0i6tra5xuXMIIE
VjCCA7+gAwIBAgIQaiarkLuOGgB7DOwVbJ0poDANBgkqhkiG9w0BAQUFADCB5jEYMBYGA1UEChMP
TkVDIENvcnBvcmF0aW9uMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMT0wOwYDVQQL
EzRUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY28uanAvcnBhIChjKTA3MTUw
MwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEzMDEG
A1UEAxMqTkVDIEdyb3VwIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFNNSU1FIEcyMB4XDTA4MTIw
MTAwMDAwMFoXDTEwMTIwMTIzNTk1OVowgesxGDAWBgNVBAoUD05FQyBDb3Jwb3JhdGlvbjEzMDEG
A1UECxQqTkVDIEdyb3VwIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFNNSU1FIEcyMTUwMwYDVQQL
EyxUZXJtcyBvZiB1c2UgYXQgd3d3LnZlcmlzaWduLmNvLmpwL3JwYSAoYykwNzE4MDYGA1UEAxMv
S296byBGdWppbm8gKDA4MTIwMSBmdWppbm8ta3hhLm5lY3N0Lm5lYy5jby5qcCkxKTAnBgkqhkiG
9w0BCQEWGmZ1amluby1reGFAbmVjc3QubmVjLmNvLmpwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQDdxU6RYkL1icXAXadLhL2ms3B76GYMy2ugbhvVprhjoqZu9Wk9Jgah1Hqs5E6KyQvHiRo2
++w+RFnQur/ABh1u5D4SHxigx0nH62ndbz9HEzR3Mg6SNXcT3X2AZGPC75HtiAD1zHQBumflYjAd
EuN1Af//DwgJWCaxhBVcIJNcUQIDAQABo4H9MIH6MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgWgMHIG
A1UdHwRrMGkwZ6BloGOGYWh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY28uanAvTkVDQ29ycG9y
YXRpb25ORUNHcm91cENlcnRpZmljYXRpb25BdXRob3JpdHlTTUlNRUcyL0xhdGVzdENSTC5jcmww
RgYDVR0gBD8wPTA7BgtghkgBhvhFAQcXAjAsMCoGCCsGAQUFBwIBFh5odHRwczovL3d3dy52ZXJp
c2lnbi5jby5qcC9ycGEwEQYJYIZIAYb4QgEBBAQDAgUgMBEGCmCGSAGG+EUBBgkEAwEB/zANBgkq
hkiG9w0BAQUFAAOBgQCRHsenhsKWNGbeZY0rYrJGlDNB83J5bNm43xEWPibj9MHMZvpBuoxHPNo2
TpK0de/5zFM/+5J96+wLT9JoMksIeNghvLiAaia+JwdLBR2AhClHRESDk3AnhTYmoVx5BGZ13sgP
wz+lz/BAwtpBhe9keIUk0mVV4t2uhKMW+IYsdTGCBI4wggSKAgEBMIH7MIHmMRgwFgYDVQQKEw9O
RUMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxPTA7BgNVBAsT
NFRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jby5qcC9ycGEgKGMpMDcxNTAz
BgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTMwMQYD
VQQDEypORUMgR3JvdXAgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgU01JTUUgRzICEGomq5C7jhoA
ewzsFWydKaAwCQYFKw4DAhoFAKCCAugwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDkwNTE1MTM0NzAxWjAjBgkqhkiG9w0BCQQxFgQU/EmuIU76ooXIWXjGDSnZ6pWV
8PwwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN
AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwggEMBgkr
BgEEAYI3EAQxgf4wgfswgeYxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazE9MDsGA1UECxM0VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3
LnZlcmlzaWduLmNvLmpwL3JwYSAoYykwNzE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMzAxBgNVBAMTKk5FQyBHcm91cCBDZXJ0aWZpY2F0aW9u
IEF1dGhvcml0eSBTTUlNRSBHMgIQaiarkLuOGgB7DOwVbJ0poDCCAQ4GCyqGSIb3DQEJEAILMYH+
oIH7MIHmMRgwFgYDVQQKEw9ORUMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxPTA7BgNVBAsTNFRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j
by5qcC9ycGEgKGMpMDcxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBT
dWJzY3JpYmVyIENBMTMwMQYDVQQDEypORUMgR3JvdXAgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
U01JTUUgRzICEGomq5C7jhoAewzsFWydKaAwDQYJKoZIhvcNAQEBBQAEgYDAP4e6pQ4VBR9k6bvK
lxCsaI9UDsHyjXtF6D7xpLaATtPCNhKGiML0adH9y04Xux/01xWCHupYrFnZDbWGkzhkANdeS12j
QKjAkub3TbTfqNC1vnM53jbNIUTuFkedfyM1ZZyfaF4Rf1L/DN3Fm0rwOAwtd/YF70up361PgJn3
VwAAAAAAAA==

------=_NextPart_000_02A7_01C9D5AF.0FA3B5B0--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4F8o8Fj024321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2009 01:50:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4F8o8VN024320; Fri, 15 May 2009 01:50:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailrelay.tugraz.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4F8ntjv024293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 15 May 2009 01:50:07 -0700 (MST) (envelope-from [email-masked])
Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) by mailrelay2.tugraz.at (8.14.3/8.14.3) with ESMTP id n4F8nqvq013210 for ; Fri, 15 May 2009 10:49:52 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.7.2 mailrelay2.tugraz.at n4F8nqvq013210
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tugraz.at; s=mailrelay; t=1242377393; bh=sAmIKvRfHfeTwCaxRYd5Ezulg1pMwNavSgIh+ 3fFPvw=; h=Subject:From:To:In-Reply-To:References:Content-Type:Date: Message-Id:Mime-Version:Content-Transfer-Encoding; b=rQy6UTBI81LKS s1dw5fY7eyCGNCB91iCDaxbWP+vTHbHYCzf4m85zyVydTg2nCbMS0vBxkRELFYrOL2S G+m2l1Law+ZN2g3k8GtjjeG2m+f7X3jO1ZIBK8gq5tgv7gUxYEJhzgchwIe7xoJpqC6 DFKPdSYhYLzEjCLTH5vgi6QA=
Received: from [129.27.152.89] (unknown [129.27.152.89]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 213FD1067B3B7 for ; Fri, 15 May 2009 10:49:53 +0200 (CEST)
Subject: Re: ASN.1 straw poll, take 2
From: Peter Lipp
To: [email-masked]
In-Reply-To:
References:
Content-Type: text/plain
Organization: IAIK, TU Graz
Date: Fri, 15 May 2009 10:49:45 +0200
Message-Id: <1242377385.6281.3.camel@linux-709y>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.1.1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.94.2/9360/Fri May 15 00:31:31 2009 on thor.iaik.tugraz.at
X-Virus-Status: Clean
X-TUG-Backscatter-control: vGe401nmNWfDyC8KKwXTHA
X-Spam-Scanner: SpamAssassin 3.002005
X-Spam-Score-relay: 0.0
X-Scanned-By: MIMEDefang 2.65 on 129.27.10.19
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

UPDATE

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4ENJijd091303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 16:19:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4ENJixO091302; Thu, 14 May 2009 16:19:44 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4ENJW8H091289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 16:19:33 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Thu, 14 May 2009 16:19:31 -0700
To: Stephen Kent , [email-masked]
From: Paul Hoffman
Subject: Re: ASN.1 straw poll, take 2
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

OBSOLETE

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EMfiFn089443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 15:41:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4EMfime089442; Thu, 14 May 2009 15:41:44 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from eb2bcom.com (165.203.232.72.static.reverse.ltdomains.com [72.232.203.165]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EMfXQ1089431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 May 2009 15:41:44 -0700 (MST) (envelope-from [email-masked])
Received: from [202.164.192.219] (helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.69) (envelope-from ) id 1M4jcL-0001Nj-FR; Fri, 15 May 2009 08:41:33 +1000
Message-ID: <[email-masked]>
Date: Fri, 15 May 2009 08:41:28 +1000
From: Steven Legg
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Stephen Kent
CC: [email-masked]
Subject: Re: ASN.1 straw poll, take 2
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 - host.eb2bcom.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source:
X-Source-Args:
X-Source-Dir:
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

OBSOLETE

Stephen Kent wrote:
>
> To assist Tim in his task of deciding how to treat the new ASN.1
> documents that Jim and Paul have developed, and to separate this issue
> from the WGLC on these documents, please reply to the following straw
> poll (which will still close on 5/22):
>
> - the new ASN.1 will OBSOLETE (i.e. replace as normative) the OLD
> ASN.1 in PKIX documents
>
> - the new ASN.1 will UPDATE (i.e., coexist as a peer with) the OLD
> ASN.1 in PKIX documents
>
>
>
> Responses should just say OBSOLETE or UPDATE.
>
> Thanks,
>
> Steve
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EL5XnK083927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 14:05:33 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4EL5W5l083926; Thu, 14 May 2009 14:05:32 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EL5LS2083911 for ; Thu, 14 May 2009 14:05:32 -0700 (MST) (envelope-from [email-masked])
Received: from [172.16.2.195] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 14 May 2009 22:05:19 +0100
Cc: [email-masked]
Message-Id:
From: Kurt Zeilenga
To: Stephen Kent
In-Reply-To: <[email-masked]>
Subject: Re: ASN.1 straw poll, take 2
Date: Thu, 14 May 2009 14:05:16 -0700
References: <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I do not buy into the argument that obsoleting the old ASN.1 would
imply or necessitate a requirement for implementations to directly use
the new ASN.1. As with any (or at least nearly all) use of formal
language in IETF specifications, the formal language is used only to
express how data is to be encoded. Implementations are free to use
alternative expressions in encoding data so long as what the encodings
they produce are consistent with encoding that would be produced if
the definitive expression had been used.

Having two normatively referenced ASN.1 statements leads to confusion
over which is definitive if they are subsequently found to be
different. It would be best to have one and only one referenced
normatively and hence for this one to be definitive.

I generally favor use of modern ASN.1 as it allows encoding
requirements to be far more clearly expressed than old ASN.1 and, in
this case, do find the new ASN.1 module is more clear than the old ASN.
1 module.

Hence, I am in favor of OBSOLETE.

I note that the LDAP community went through a similar debate when it
updated LDAP technical specification. In the end, the LDAP technical
specification was updated to modern ASN.1, the specification was more
precise (as allowed by the more modern ASN.1), did not cause any
implementation to update ASN.1 modules just for update sake, but did
lead to improvements in interoperability (because the resulting ASN.1
module was clearer and more precise).

-- Kurt

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EIwTpj074281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 11:58:29 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4EIwTpC074280; Thu, 14 May 2009 11:58:29 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EIwHwJ074268 for ; Thu, 14 May 2009 11:58:28 -0700 (MST) (envelope-from [email-masked])
Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 67FC5B35BD for ; Thu, 14 May 2009 14:58:17 -0400 (EDT)
Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id F2DF5B35BC for ; Thu, 14 May 2009 14:58:16 -0400 (EDT)
Message-ID: <[email-masked]>
Date: Thu, 14 May 2009 11:57:58 -0700
From: "Michael D'Errico"
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: ASN.1 straw poll, take 2
References: <155801c9d42c$b7da5b00$278f1100$@com> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 2F44DA0A-40B9-11DE-84A3-CABC03BA4B0C-38729857!a-sasl-fastnet.pobox.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

UPDATE

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EItotD074079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 11:55:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4EItoVC074078; Thu, 14 May 2009 11:55:50 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EItcRS074046 for ; Thu, 14 May 2009 11:55:49 -0700 (MST) (envelope-from [email-masked])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) (authenticated as u18116613) id 49CCDA0700746AD2; Thu, 14 May 2009 20:55:35 +0200
Message-ID: <72D3A38B651642CFB586C6AD829BA297@AndersPC>
From: "Anders Rundgren"
To: "Trevor Freeman" ,
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: Re: cert image I-D
Date: Thu, 14 May 2009 20:56:38 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi Trevor,
I also consider the authors a bunch of bright people.

However writing an I-D describing how a image URL can be
fitted to a certificate, without actually publishing a mockup on how
this I-D could be mapped to the existing browser GUI's is begging
for problems.

It is also worth noting that at least one of the external parties mentioned
as input also have web-based signatures as one of their core offerings.
But this requirement (which is much bigger than cert-images), has to date
been *ignored* by MSFT. In fact, government and banks in the EU
spend at least $100M annually on developing browser-client-PKI SW
since they [rightfully] experience the current state of things as "miserable".

That MSFT (according to W3C/WHATWG...) intends to support the
HTML5 tag is yet another indication that the people who work with
browsers at MSFT (and Apple, Nokia, Google, Mozilla, Opera etc), do not
have sufficient information what the requirement are on browser-PKI.
: on-line key-provisioning without even supporting PIN-codes!

Subsequently the very same governments and banks quite often also develop
their own provisioning stuff; what else could they possibly do?

I'm sure a cert-image RFC will pass with flying colors but that's about
the only action there will be.

Anders
puzzled

----- Original Message -----
From: "Trevor Freeman"
To: "Anders Rundgren" ; ; "Stephen Kent"

Sent: Thursday, May 14, 2009 01:26
Subject: RE: cert image I-D

Hi Anders,

I agree that this work faces a number of technical challenges, however the authors are a bunch of
bright people and they will rise to meet the challenge.

On one point we do agree and that is the 80%+ case for web based authentication using client
certificates will be via information cards. The fat lady has sung on that point. The reason that
will be the case is that the authorization to access the data needs a richer set of information than
that contained within the X.509 certificate alone so they need to present a set of claims e.g. a
SAML token not just a certificate. As you point out, information cards already handle the case of
presenting a graphical image to the user.

Another reason why information cards are the 80% case is that the web 2.0 standard also addresses in
more detail the question of what is needed to do to access the site because the site publishes
access policy via WS-Policy. The information card client knows in much greater detail what is
required and therefore would not require the user to make a choice they did not comprehend.

That said there are other scenarios where you have the potential for client certificate
authentication which are not web 2.0 based e.g. IMAP where this work may be useful.

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Anders
Rundgren
Sent: Wednesday, May 13, 2009 1:40 PM
To: [email-masked]; Stephen Kent
Subject: Re: cert image I-D

I believe this effort suffers from more technical hurdles than the authors
are aware of. Just defining exactly how and where in a browser's TLS
client-cert-auth the image is supposed to be introduced is not trivial
because there is a battle going on between the browser/OS and the
vendors of card middleware for the GUI. Currently the latter often
does a better job than the rather complacent browser vendors.

The sample given by Siddharth probably utilized some kind
of application-level thingy which BTW points to another issue:
Quite a bunch of current PKI implementations actually do not use TLS-
client-cert-auth but rather use proprietary app-level authentication schemes.
One the few non-internal PKIs used by the USG, namely the
USPTO's filing system is apparently one of these systems.

It is also worth noting that Information Cards do not use TLS-client
cert-auth even when the primary authentication is based on PKI.
Probably MSFT drew the same conclusion as many others have
before them: TLS-client-cert-auth is an ugly beast on the web,
app-level authentication works better; it is at least much prettier :-)

Although providing an "upgrade path" sounds like a good solution
it often works in the opposite way by "the least common denominator rule".
60% of enterprises use IE6 despite been EOLed since 5 years back!

Time will tell, but personally I do not believe you get very far unless you
take on the entire browser/keystore/provisioning/authentication space
otherwise the incentive for changing (anything) will simply be too small.

Which is thus exactly what my counter-proposal does........

Anders

----- Original Message -----
From: "Stephen Kent"
To:
Sent: Wednesday, May 13, 2009 19:56
Subject: cert image I-D

Folks,

I have reviewed the discussion on the list re Stefan's cert image
proposal. While there were comments for and against, the positive
comments, especially from folks who are in a position to make use of
this feature, were persuasive.

We will proceed with this a a new PKIX WG work item. This is not a
guarantee that the WG will approve a document, but rather that we
will explore approaches to achieving the goals described by Stefan
and try to come to consensus on a specific technical approach. We can
decide later whether this is standards track, experimental or even
informational.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EHbONh067033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 10:37:25 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4EHbO0b067032; Thu, 14 May 2009 10:37:24 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EHbDxm066995 for ; Thu, 14 May 2009 10:37:24 -0700 (MST) (envelope-from [email-masked])
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
Subject: RE: ASN.1 straw poll, take 2
Date: Thu, 14 May 2009 13:37:13 -0400
Message-ID: <[email-masked]>
In-Reply-To: <155801c9d42c$b7da5b00$278f1100$@com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: ASN.1 straw poll, take 2
Thread-Index: AcnUHQY0k3ob1u2FST222J42kHqRzwAD64dgACNzFdA=
References: <155801c9d42c$b7da5b00$278f1100$@com>
From: "Kemp, David P."
To:
X-OriginalArrivalTime: 14 May 2009 17:31:13.0328 (UTC) FILETIME=[C73A1300:01C9D4B9]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

OBSOLETE

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jim Schaad
Sent: Wednesday, May 13, 2009 8:41 PM
To: 'Stephen Kent'; [email-masked]
Subject: RE: ASN.1 straw poll, take 2

OBSOLETE

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stephen Kent
> Sent: Wednesday, May 13, 2009 3:41 PM
> To: [email-masked]
> Subject: ASN.1 straw poll, take 2
>=20
>=20
> To assist Tim in his task of deciding how to treat the new ASN.1
> documents that Jim and Paul have developed, and to separate this
> issue from the WGLC on these documents, please reply to the following
> straw poll (which will still close on 5/22):
>=20
> - the new ASN.1 will OBSOLETE (i.e. replace as normative) the
> OLD ASN.1 in PKIX documents
>=20
> - the new ASN.1 will UPDATE (i.e., coexist as a peer with)
> the OLD ASN.1 in PKIX documents
>=20
>=20
>=20
> Responses should just say OBSOLETE or UPDATE.
>=20
> Thanks,
>=20
> Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EGnEw0063083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 09:49:14 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4EGnEsm063082; Thu, 14 May 2009 09:49:14 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhub1.dartmouth.edu (mailhub1.dartmouth.edu [129.170.16.122]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EGn2YF063066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 May 2009 09:49:13 -0700 (MST) (envelope-from [email-masked])
Received: from newblitzen.Dartmouth.EDU (newblitzen.dartmouth.edu [129.170.208.36]) by mailhub1.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id n4EG0Z5Q019735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 May 2009 12:48:04 -0400
X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system.
Received: from mm.cs.dartmouth.edu [129.170.214.89] by newblitzen.Dartmouth.EDU (Mac) via SMTP for [email-masked] id <148410302>; 14 May 2009 12:48:03 -0400
Message-ID: <[email-masked]>
Date: Thu, 14 May 2009 12:52:41 -0400
From: Massimiliano Pala
Organization: Dartmouth College - Computer Science Department
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: pkix
Subject: Re: ASN.1 straw poll, take 2
References:
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080905080803000704070400"
X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU
X-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a cryptographically signed message in MIME format.

--------------ms080905080803000704070400
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

OBSOLETE

--------------ms080905080803000704070400
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC
BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy
MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm
iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv
bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh
bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk
dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB
muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL
UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA
AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB
mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs
ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3
dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R
BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH
p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j
b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht
wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z
3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7
PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA
Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA
Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ
KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh
cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD
VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw
NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk
AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN
AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0
FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP
LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/
BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB
MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo
IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr
aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u
UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G
CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu
ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO
P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB
uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra
q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb
CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv
Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX
BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF
AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNTE0
MTY1MjQxWjAjBgkqhkiG9w0BCQQxFgQUtSj0E4b2LOCB6rflgGSJijjeKDMwUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk
ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV
BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa
UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ
k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s
bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE
gYB7feJBeSk+94yRett4BltxzsaMO2QlgoxONmALA/GgvxQmrT5r6lLBc3OGgtmpQe5sOXan
tysxxPOYp1aGf4TR/4ZILfsvpHXvvmf3JcakHjbeHhqjTF6B34qSG1wLFEIdnl05TNdiL/fA
+5i3Qb/teiEQWZxTVA1tZxWC3jBz7QAAAAAAAA==
--------------ms080905080803000704070400--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EDm3J0047817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 06:48:03 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4EDm37f047816; Thu, 14 May 2009 06:48:03 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EDlp5w047801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 May 2009 06:48:02 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=gardiner-xp.bbn.com) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1M4bHr-0005by-9u; Thu, 14 May 2009 09:47:51 -0400
Message-Id: <[email-masked]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 14 May 2009 09:48:01 -0400
To: Stephen Kent , [email-masked]
From: "Charles W. Gardiner"
Subject: Re: ASN.1 straw poll, take 2
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

UPDATE

At 06:40 PM 5/13/2009, Stephen Kent wrote:

>To assist Tim in his task of deciding how to treat the new ASN.1 documents
>that Jim and Paul have developed, and to separate this issue from the WGLC
>on these documents, please reply to the following straw poll (which will
>still close on 5/22):
>
> - the new ASN.1 will OBSOLETE (i.e. replace as normative) the OLD
> ASN.1 in PKIX documents
>
> - the new ASN.1 will UPDATE (i.e., coexist as a peer with) the
> OLD ASN.1 in PKIX documents
>
>
>
>Responses should just say OBSOLETE or UPDATE.
>
>Thanks,
>
>Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EDd45F046787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 06:39:04 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4EDd4QL046786; Thu, 14 May 2009 06:39:04 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n4EDcrEl046765 for ; Thu, 14 May 2009 06:39:03 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 19568 invoked from network); 14 May 2009 13:38:52 -0000
Received: from unknown (HELO thunderfish.local) ([email-masked] with plain) by smtp100.biz.mail.re2.yahoo.com with SMTP; 14 May 2009 13:38:52 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Thu, 14 May 2009 09:38:53 -0400
From: Sean Turner
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Stephen Kent , [email-masked]
Subject: Re: ASN.1 straw poll, take 2
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

OBSOLETE

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EBtRMw036466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 04:55:27 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4EBtQEE036465; Thu, 14 May 2009 04:55:26 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from p03c11o142.symantecmail.net (p03c11o142.symantecmail.net [208.65.144.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EBtCZB036454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 May 2009 04:55:22 -0700 (MST) (envelope-from [email-masked])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id ba60c0a4.2492369840.365394.00-022.p03c11o142.symantecmail.net (envelope-from ); Thu, 14 May 2009 05:55:23 -0600 (MDT)
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
Subject: RE: ASN.1 straw poll, take 2
Date: Thu, 14 May 2009 07:55:11 -0400
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: ASN.1 straw poll, take 2
Thread-Index: AcnUHhD8vYe2c4klQBa7ZGTo1FCSkgAbEGlg
References:
From: "Carl Wallace"
To:
X-Spam: [F=0.2000000000; S=0.200(2009020301)]
X-MAIL-FROM:
X-SOURCE-IP: [65.242.48.5]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

OBSOLETE

(However, I'd vote for UPDATE if it also results standards track
documents for the new modules)

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stephen Kent
> Sent: Wednesday, May 13, 2009 6:41 PM
> To: [email-masked]
> Subject: ASN.1 straw poll, take 2
>=20
>=20
> To assist Tim in his task of deciding how to treat the new ASN.1
> documents that Jim and Paul have developed, and to separate this
> issue from the WGLC on these documents, please reply to the following
> straw poll (which will still close on 5/22):
>=20
> - the new ASN.1 will OBSOLETE (i.e. replace as normative) the
> OLD ASN.1 in PKIX documents
>=20
> - the new ASN.1 will UPDATE (i.e., coexist as a peer with)
> the OLD ASN.1 in PKIX documents
>=20
>=20
>=20
> Responses should just say OBSOLETE or UPDATE.
>=20
> Thanks,
>=20
> Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EAppVX030999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 03:51:51 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4EAppKr030998; Thu, 14 May 2009 03:51:51 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4EApe9p030990 for ; Thu, 14 May 2009 03:51:51 -0700 (MST) (envelope-from [email-masked])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 782646D; Thu, 14 May 2009 12:51:39 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2009051412513785:476823 ; Thu, 14 May 2009 12:51:37 +0200
Message-ID: <[email-masked]>
Date: Thu, 14 May 2009 12:51:38 +0200
From: Peter Sylvester
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Stephen Kent
Cc: [email-masked]
Subject: Re: ASN.1 straw poll, take 2
References:
In-Reply-To:
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 05/14/2009 12:51:37 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 05/14/2009 12:51:39 PM, Serialize complete at 05/14/2009 12:51:39 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

UPDATE

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4E9Qdct024253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 02:26:39 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4E9QdGX024252; Thu, 14 May 2009 02:26:39 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4E9QaW3024245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 May 2009 02:26:38 -0700 (MST) (envelope-from [email-masked])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4E9QSQC001138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 May 2009 11:26:30 +0200
From: Simon Josefsson
To: Stephen Kent
Cc: [email-masked]
Subject: Re: ASN.1 straw poll, take 2
References:
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090514:[email-masked]::4RxEvBClMuku9Gut:9/Ph
X-Hashcash: 1:22:090514:[email-masked]::Key/w6cwf9MZTAvM:UG4y
Date: Thu, 14 May 2009 11:26:28 +0200
In-Reply-To: (Stephen Kent's message of "Wed\, 13 May 2009 18\:40\:39 -0400")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stephen Kent writes:

> To assist Tim in his task of deciding how to treat the new ASN.1
> documents that Jim and Paul have developed, and to separate this issue
> from the WGLC on these documents, please reply to the following straw
> poll (which will still close on 5/22):
>
> - the new ASN.1 will OBSOLETE (i.e. replace as normative) the
> OLD ASN.1 in PKIX documents
>
> - the new ASN.1 will UPDATE (i.e., coexist as a peer with) the
> OLD ASN.1 in PKIX documents
>
>
>
> Responses should just say OBSOLETE or UPDATE.

UPDATE

/Simon

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4E0ifS8095454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 17:44:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4E0ieaw095453; Wed, 13 May 2009 17:44:40 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4E0iNoP095439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 13 May 2009 17:44:40 -0700 (MST) (envelope-from [email-masked])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp2.pacifier.net (Postfix) with ESMTP id B0FA17531B; Wed, 13 May 2009 17:41:53 -0700 (PDT)
From: "Jim Schaad"
To: "'Stephen Kent'" ,
References:
In-Reply-To:
Subject: RE: ASN.1 straw poll, take 2
Date: Wed, 13 May 2009 17:41:27 -0700
Message-ID: <155801c9d42c$b7da5b00$278f1100$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcnUHQY0k3ob1u2FST222J42kHqRzwAD64dg
Content-Language: en-us
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

OBSOLETE

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stephen Kent
> Sent: Wednesday, May 13, 2009 3:41 PM
> To: [email-masked]
> Subject: ASN.1 straw poll, take 2
>
>
> To assist Tim in his task of deciding how to treat the new ASN.1
> documents that Jim and Paul have developed, and to separate this
> issue from the WGLC on these documents, please reply to the following
> straw poll (which will still close on 5/22):
>
> - the new ASN.1 will OBSOLETE (i.e. replace as normative) the
> OLD ASN.1 in PKIX documents
>
> - the new ASN.1 will UPDATE (i.e., coexist as a peer with)
> the OLD ASN.1 in PKIX documents
>
>
>
> Responses should just say OBSOLETE or UPDATE.
>
> Thanks,
>
> Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4E0CHTo094048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 17:12:17 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4E0CHOQ094047; Wed, 13 May 2009 17:12:17 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4E0C5vR094019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 May 2009 17:12:16 -0700 (MST) (envelope-from [email-masked])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4E07pZq003166 for ; Wed, 13 May 2009 20:07:51 -0400
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4E0C4g3256692 for ; Wed, 13 May 2009 20:12:04 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4E0C36l022707 for ; Wed, 13 May 2009 20:12:04 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n4E0C3dL022697; Wed, 13 May 2009 20:12:03 -0400
In-Reply-To:
To: Stephen Kent
Cc: [email-masked], [email-masked]
MIME-Version: 1.0
Subject: Re: straw poll
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin
Message-ID:
Date: Wed, 13 May 2009 20:12:02 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 05/13/2009 20:12:03, Serialize complete at 05/13/2009 20:12:03
Content-Type: text/plain; charset="US-ASCII"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I'm for "updates", and against "obsoletes" or "supersedes". I
know "supersedes" isn't the official term here, but it means the same
thing as "obsoletes".

Tom Gindin

Stephen Kent
Sent by: [email-masked]
05/13/2009 02:00 PM

To
[email-masked]
cc

Subject
straw poll

At the SF meeting Tim Polk asked us to conduct a straw poll on
whether the new ASN.1 for PKIX standards should replace the old ASN.1
or be considered as an equal alternative to it.

Please indicate your support for
- new supercedes old
- new is a peer of old

The straw poll will close on 5/22.

Thanks,

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DNkjPU092388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 16:46:45 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DNkjjZ092387; Wed, 13 May 2009 16:46:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DNkZFq092369 for ; Wed, 13 May 2009 16:46:45 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id E25C528C1FF; Wed, 13 May 2009 16:45:01 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-prqp-03.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Wed, 13 May 2009 16:45:01 -0700 (PDT)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

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.

Title : PKI Resource Query Protocol (PRQP)
Author(s) : M. Pala
Filename : draft-ietf-pkix-prqp-03.txt
Pages : 37
Date : 2009-05-13

One of the most strategic problems still open in PKIX is locating
public data and services associated with a Certification Authority
(CA). This issue impacts interoperability and usability in PKIX.

This draft describes the PKI Resource Query Protocol (PRQP), its
design, definition, and its impact in already deployed PKIX
protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-pkix-prqp-03.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DNeuT5092122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 16:40:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DNeuAx092121; Wed, 13 May 2009 16:40:56 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DNesMu092113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 May 2009 16:40:55 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 31295 invoked from network); 13 May 2009 23:41:03 -0000
Received: from s34.loopia.se (HELO s60.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 13 May 2009 23:41:03 -0000
Received: (qmail 23112 invoked from network); 13 May 2009 23:40:53 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 13 May 2009 23:40:53 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Thu, 14 May 2009 01:40:52 +0200
Subject: Re: ASN.1 straw poll, take 2
From: Stefan Santesson
To: Stephen Kent ,
Message-ID:
Thread-Topic: ASN.1 straw poll, take 2
Thread-Index: AcnUJEBV62fvFyiOqUu37VG6db2zJQ==
In-Reply-To:
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

UPDATE

On 09-05-14 12:40 AM, "Stephen Kent" wrote:

>
> To assist Tim in his task of deciding how to treat the new ASN.1
> documents that Jim and Paul have developed, and to separate this
> issue from the WGLC on these documents, please reply to the following
> straw poll (which will still close on 5/22):
>
> - the new ASN.1 will OBSOLETE (i.e. replace as normative) the
> OLD ASN.1 in PKIX documents
>
> - the new ASN.1 will UPDATE (i.e., coexist as a peer with)
> the OLD ASN.1 in PKIX documents
>
>
>
> Responses should just say OBSOLETE or UPDATE.
>
> Thanks,
>
> Steve
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DNeUE3092078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 16:40:35 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DNeTAr092077; Wed, 13 May 2009 16:40:30 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DNeG0N092067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 May 2009 16:40:28 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 31184 invoked from network); 13 May 2009 23:40:25 -0000
Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 13 May 2009 23:40:25 -0000
Received: (qmail 605 invoked from network); 13 May 2009 23:40:15 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 13 May 2009 23:40:15 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Thu, 14 May 2009 01:40:14 +0200
Subject: Re: cert image I-D
From: Stefan Santesson
To: Trevor Freeman , Anders Rundgren , "[email-masked]" , Stephen Kent
Message-ID:
Thread-Topic: cert image I-D
Thread-Index: AQHJ0/eNIWsS/XiFnkad5cfkOyeN+ZAU40+A//+onjCAABR3bQ==
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Trevor,

Agreeing with many things I would like to add one thing.

Having spent considerable time with the information cards concept and having
been through long discussions with the information card team at Microsoft, I
can see no conflict.

Even if information card is used to provide a UI for client certificates,
this UI still need to come up with an image to represent that certificate.

Information card has previously been a candidate for consuming RFC 3709
images and that is by no means less true if we add another more useful
image.

/Stefan

On 09-05-14 1:26 AM, "Trevor Freeman"
wrote:

>
> Hi Anders,
>
> I agree that this work faces a number of technical challenges, however the
> authors are a bunch of bright people and they will rise to meet the challenge.
>
> On one point we do agree and that is the 80%+ case for web based
> authentication using client certificates will be via information cards. The
> fat lady has sung on that point. The reason that will be the case is that the
> authorization to access the data needs a richer set of information than that
> contained within the X.509 certificate alone so they need to present a set of
> claims e.g. a SAML token not just a certificate. As you point out, information
> cards already handle the case of presenting a graphical image to the user.
>
> Another reason why information cards are the 80% case is that the web 2.0
> standard also addresses in more detail the question of what is needed to do to
> access the site because the site publishes access policy via WS-Policy. The
> information card client knows in much greater detail what is required and
> therefore would not require the user to make a choice they did not comprehend.
>
> That said there are other scenarios where you have the potential for client
> certificate authentication which are not web 2.0 based e.g. IMAP where this
> work may be useful.
>
> Trevor
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Anders Rundgren
> Sent: Wednesday, May 13, 2009 1:40 PM
> To: [email-masked]; Stephen Kent
> Subject: Re: cert image I-D
>
>
> I believe this effort suffers from more technical hurdles than the authors
> are aware of. Just defining exactly how and where in a browser's TLS
> client-cert-auth the image is supposed to be introduced is not trivial
> because there is a battle going on between the browser/OS and the
> vendors of card middleware for the GUI. Currently the latter often
> does a better job than the rather complacent browser vendors.
>
> The sample given by Siddharth probably utilized some kind
> of application-level thingy which BTW points to another issue:
> Quite a bunch of current PKI implementations actually do not use TLS-
> client-cert-auth but rather use proprietary app-level authentication schemes.
> One the few non-internal PKIs used by the USG, namely the
> USPTO's filing system is apparently one of these systems.
>
> It is also worth noting that Information Cards do not use TLS-client
> cert-auth even when the primary authentication is based on PKI.
> Probably MSFT drew the same conclusion as many others have
> before them: TLS-client-cert-auth is an ugly beast on the web,
> app-level authentication works better; it is at least much prettier :-)
>
> Although providing an "upgrade path" sounds like a good solution
> it often works in the opposite way by "the least common denominator rule".
> 60% of enterprises use IE6 despite been EOLed since 5 years back!
>
> Time will tell, but personally I do not believe you get very far unless you
> take on the entire browser/keystore/provisioning/authentication space
> otherwise the incentive for changing (anything) will simply be too small.
>
> Which is thus exactly what my counter-proposal does........
>
> Anders
>
> ----- Original Message -----
> From: "Stephen Kent"
> To:
> Sent: Wednesday, May 13, 2009 19:56
> Subject: cert image I-D
>
>
>
> Folks,
>
> I have reviewed the discussion on the list re Stefan's cert image
> proposal. While there were comments for and against, the positive
> comments, especially from folks who are in a position to make use of
> this feature, were persuasive.
>
> We will proceed with this a a new PKIX WG work item. This is not a
> guarantee that the WG will approve a document, but rather that we
> will explore approaches to achieving the goals described by Stefan
> and try to come to consensus on a specific technical approach. We can
> decide later whether this is standards track, experimental or even
> informational.
>
> Steve
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DNZ4Us091817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 16:35:04 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DNZ4Lr091816; Wed, 13 May 2009 16:35:04 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from claranet-outbound-smtp05.uk.clara.net (claranet-outbound-smtp05.uk.clara.net [195.8.89.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DNYrPc091802 for ; Wed, 13 May 2009 16:35:03 -0700 (MST) (envelope-from [email-masked])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:50260 helo=[192.168.7.8]) by relay05.mail.eu.clara.net (relay.clara.net [213.253.3.45]:1025) with esmtpa (authdaemon_plain:drh) id 1M4NyM-0006WV-IK (Exim 4.69) (return-path ); Thu, 14 May 2009 00:34:51 +0100
Message-ID: <[email-masked]>
Date: Thu, 14 May 2009 00:34:51 +0100
From: Dr Stephen Henson
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Stephen Kent
CC: [email-masked]
Subject: Re: ASN.1 straw poll, take 2
References:
In-Reply-To:
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stephen Kent wrote:
>
> To assist Tim in his task of deciding how to treat the new ASN.1
> documents that Jim and Paul have developed, and to separate this issue
> from the WGLC on these documents, please reply to the following straw
> poll (which will still close on 5/22):
>
> - the new ASN.1 will OBSOLETE (i.e. replace as normative) the OLD
> ASN.1 in PKIX documents
>
> - the new ASN.1 will UPDATE (i.e., coexist as a peer with) the OLD
> ASN.1 in PKIX documents
>
>
>
> Responses should just say OBSOLETE or UPDATE.
>

UPDATE

--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DNQhUk091441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 16:26:43 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DNQhlE091440; Wed, 13 May 2009 16:26:43 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DNQRTI091431 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 May 2009 16:26:42 -0700 (MST) (envelope-from [email-masked])
Received: from df-g14-02.exchange.corp.microsoft.com (157.54.94.58) by df-gwy-07.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server id 8.2.140.0; Wed, 13 May 2009 16:26:26 -0700
Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by df-g14-02.exchange.corp.microsoft.com (157.54.94.58) with Microsoft SMTP Server (TLS) id 14.0.582.2; Wed, 13 May 2009 16:26:27 -0700
Received: from DF-MBX-62.exchange.corp.microsoft.com ([169.254.2.56]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi; Wed, 13 May 2009 16:26:26 -0700
From: Trevor Freeman
To: Anders Rundgren , "[email-masked]" , Stephen Kent
Subject: RE: cert image I-D
Thread-Topic: cert image I-D
Thread-Index: AQHJ0/eNIWsS/XiFnkad5cfkOyeN+ZAU40+A//+onjA=
Date: Wed, 13 May 2009 23:26:25 +0000
Message-ID: <[email-masked]>
References:
In-Reply-To:
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi Anders,

I agree that this work faces a number of technical challenges, however the =
authors are a bunch of bright people and they will rise to meet the challen=
ge.

On one point we do agree and that is the 80%+ case for web based authentica=
tion using client certificates will be via information cards. The fat lady =
has sung on that point. The reason that will be the case is that the author=
ization to access the data needs a richer set of information than that cont=
ained within the X.509 certificate alone so they need to present a set of c=
laims e.g. a SAML token not just a certificate. As you point out, informati=
on cards already handle the case of presenting a graphical image to the use=
r.

Another reason why information cards are the 80% case is that the web 2.0 s=
tandard also addresses in more detail the question of what is needed to do =
to access the site because the site publishes access policy via WS-Policy. =
The information card client knows in much greater detail what is required a=
nd therefore would not require the user to make a choice they did not compr=
ehend.

That said there are other scenarios where you have the potential for client=
certificate authentication which are not web 2.0 based e.g. IMAP where thi=
s work may be useful.

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On=
Behalf Of Anders Rundgren
Sent: Wednesday, May 13, 2009 1:40 PM
To: [email-masked]; Stephen Kent
Subject: Re: cert image I-D

I believe this effort suffers from more technical hurdles than the authors
are aware of. Just defining exactly how and where in a browser's TLS
client-cert-auth the image is supposed to be introduced is not trivial
because there is a battle going on between the browser/OS and the
vendors of card middleware for the GUI. Currently the latter often
does a better job than the rather complacent browser vendors.

The sample given by Siddharth probably utilized some kind
of application-level thingy which BTW points to another issue:
Quite a bunch of current PKI implementations actually do not use TLS-
client-cert-auth but rather use proprietary app-level authentication scheme=
s.
One the few non-internal PKIs used by the USG, namely the
USPTO's filing system is apparently one of these systems.

It is also worth noting that Information Cards do not use TLS-client
cert-auth even when the primary authentication is based on PKI.
Probably MSFT drew the same conclusion as many others have
before them: TLS-client-cert-auth is an ugly beast on the web,
app-level authentication works better; it is at least much prettier :-)

Although providing an "upgrade path" sounds like a good solution
it often works in the opposite way by "the least common denominator rule".
60% of enterprises use IE6 despite been EOLed since 5 years back!

Time will tell, but personally I do not believe you get very far unless you
take on the entire browser/keystore/provisioning/authentication space
otherwise the incentive for changing (anything) will simply be too small.

Which is thus exactly what my counter-proposal does........

Anders

----- Original Message -----
From: "Stephen Kent"
To:
Sent: Wednesday, May 13, 2009 19:56
Subject: cert image I-D

Folks,

I have reviewed the discussion on the list re Stefan's cert image
proposal. While there were comments for and against, the positive
comments, especially from folks who are in a position to make use of
this feature, were persuasive.

We will proceed with this a a new PKIX WG work item. This is not a
guarantee that the WG will approve a document, but rather that we
will explore approaches to achieving the goals described by Stefan
and try to come to consensus on a specific technical approach. We can
decide later whether this is standards track, experimental or even
informational.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DNFoMM090965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 16:15:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DNFokV090964; Wed, 13 May 2009 16:15:50 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DNFc0G090953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 May 2009 16:15:49 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 03ABB1003F4A5; Thu, 14 May 2009 00:15:37 +0100 (IST)
X-Virus-Scanned: amavisd-new at newbay.com
Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+XyinpEzvbp; Thu, 14 May 2009 00:15:34 +0100 (IST)
Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id 7AC6F1003EB5C; Thu, 14 May 2009 00:15:34 +0100 (IST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id 5EB487C316; Thu, 14 May 2009 00:15:34 +0100 (IST)
X-Virus-Scanned: amavisd-new at newbay.com
Received: from mail01.newbay.com ([127.0.0.1]) by localhost (mail01.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrA5qTkjr9j8; Thu, 14 May 2009 00:15:29 +0100 (IST)
Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail01.newbay.com (Postfix) with ESMTP id A14EC7C2C4; Thu, 14 May 2009 00:15:29 +0100 (IST)
References:
Message-Id: <[email-masked]>
From: Stephen Farrell
To: Stephen Kent
In-Reply-To:
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
X-Mailer: iPhone Mail (5H11)
Mime-Version: 1.0 (iPhone Mail 5H11)
Subject: Re: ASN.1 straw poll, take 2
Date: Thu, 14 May 2009 00:11:57 +0100
Cc: "[email-masked]"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

UPDATE

On 13 May 2009, at 23:40, Stephen Kent wrote:

>
> To assist Tim in his task of deciding how to treat the new ASN.1
> documents that Jim and Paul have developed, and to separate this
> issue from the WGLC on these documents, please reply to the
> following straw poll (which will still close on 5/22):
>
> - the new ASN.1 will OBSOLETE (i.e. replace as normative) the OLD
> ASN.1 in PKIX documents
>
> - the new ASN.1 will UPDATE (i.e., coexist as a peer with) the
> OLD ASN.1 in PKIX documents
>
>
>
> Responses should just say OBSOLETE or UPDATE.
>
> Thanks,
>
> Steve
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DMhhNt089253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 15:43:43 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DMhhQA089252; Wed, 13 May 2009 15:43:43 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DMhMCQ089213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 May 2009 15:43:33 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-006.bbn.com ([128.89.89.6]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1M4NAX-00027a-C1; Wed, 13 May 2009 18:43:21 -0400
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Wed, 13 May 2009 18:40:42 -0400
To: Paul Hoffman
From: Stephen Kent
Subject: Re: straw poll
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 1:00 PM -0700 5/13/09, Paul Hoffman wrote:
>At 2:00 PM -0400 5/13/09, Stephen Kent wrote:
>>Please indicate your support for
>> - new supercedes old
>> - new is a peer of old
>
>"Supercedes" is not an IETF procedures verb, I believe. "Updates"
>and/or "obsoletes" are terms more commonly understood in the IETF,
>given that they appear at the top of RFCs.
>
>For a document such as the ASN.1 modules document, "updates" would
>mean "adds the new module into the previous specification", similar
>to a new protocol extension updating the existing protocol.
>"Obsoletes" would mean "the new module replaces the module in the
>previous specification".
>
>Do you maybe want to start the poll again (and, if so, might you
>make the subject line a bit more descriptive)?
>
>--Paul Hoffman, Director
>--VPN Consortium

Paul,

You are right the "supercedes" is not an IETF term. I used it
because, frankly, "obsoletes" has always struck me as marginal
English :-). But, I concede that we should, stick with the terms
that would appear in the RFCs.

So, I will try again.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DMhYgf089241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 15:43:34 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DMhYDr089238; Wed, 13 May 2009 15:43:34 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DMhMX7089215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 May 2009 15:43:33 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-006.bbn.com ([128.89.89.6]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1M4NAY-00027a-AN for [email-masked]; Wed, 13 May 2009 18:43:22 -0400
Mime-Version: 1.0
Message-Id:
Date: Wed, 13 May 2009 18:40:39 -0400
To: [email-masked]
From: Stephen Kent
Subject: ASN.1 straw poll, take 2
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

To assist Tim in his task of deciding how to treat the new ASN.1
documents that Jim and Paul have developed, and to separate this
issue from the WGLC on these documents, please reply to the following
straw poll (which will still close on 5/22):

- the new ASN.1 will OBSOLETE (i.e. replace as normative) the
OLD ASN.1 in PKIX documents

- the new ASN.1 will UPDATE (i.e., coexist as a peer with)
the OLD ASN.1 in PKIX documents

Responses should just say OBSOLETE or UPDATE.

Thanks,

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DLGVhI084395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 14:16:31 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DLGVcL084394; Wed, 13 May 2009 14:16:31 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay.imagine.ie (dns1.dns.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DLGSXM084385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 May 2009 14:16:30 -0700 (MST) (envelope-from [email-masked])
Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id 4E959326CB; Wed, 13 May 2009 22:16:28 +0100 (IST)
Received: from [10.87.48.9] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id n4DLGPdT014037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 May 2009 22:16:26 +0100
Message-ID: <[email-masked]>
Date: Wed, 13 May 2009 22:19:05 +0100
From: Stephen Farrell
User-Agent: Thunderbird 2.0.0.21 (X11/20090302)
MIME-Version: 1.0
To: Stephen Kent
CC: Stefan Santesson , [email-masked]
Subject: Re: WG Last Call on draft-ietf-pkix-tac-03
References:
In-Reply-To:
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0)
X-Spam-Score: 0.00 () [Hold at 8.00]
X-Canit-Stats-ID: 42365712 - 75a28ef18c7e (trained as not-spam)
X-CanItPRO-Stream: outgoing
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stephen Kent wrote:
>> *4) Conceptual question
>> *I have another conceptual question.
>>
>> Wouldn't it be possible to achieve the same anonymity assurance
>> without doing the blind signature (step 4-5).
>> This is also the question using Stephen's and David's altered model.

Well, I think there may be a few ways to go at it that differ
from the current draft. My concern was more with the communications
paths used rather than an objection to the use of the threshold
scheme.

>>
>> The AI already knows that the request is genuine because the user
>> provides a valid token.
>> The AI can now issue an anonymous certificate that is unknown to BI.
>> In case of problems, AI releases the token that can be sent to BI for
>> identification of the user.
>>
>> What extra level of assurance for anonymity is given to the user by
>> the threshold signature scheme?
>>
>> I can see that it prevents AI from issuing certificates on its own,
>> and thus is an assurance that there actually exist a BI record that
>> the BI will honor in case of problems, but if AI was trusted to only
>> issue valid certificates based on valid tokens, then what is the gain?
>> The follow up question is: If there as a reasonable mode where this
>> protocol can be used without deploying the threshold signature scheme,
>> then wouldn't it be valid to describe that as an optional scenario
>> within which the basic protocol can be used?
>
> The use of a split signature scheme contributes to the argument that the
> TAC CA is taking precautions to help preserve user anonymity in the
> issuance process.

I'm not sure I follow that - how does the scheme show the CA is taking
precautions? The entities involved could still collude regardless of the
scheme, or could honestly not collude even if no threshold scheme were
used.

> The use of this mechanism is not directly visible to
> the user, as you and others ave noted. However, in many contexts, a CA
> operating a TAC service may need to satisfy accreditors that it is
> providing this service in a trustworthy fashion. This is what motivated
> the KISA folks, who perform assessments of CAs in their country, to call
> for use of the split-signing approach. Thus the use of split-signing is
> not an arbitrary, academic proposal, but rather is motivated by the
> experience of a group of folks who perform CA evaluations and who want
> to have an RFC that they can cite as the basis for their evaluations of
> TAC CAs. I think we should defer to their experience as CA evaluators
> in this instance.

Deference? In the IETF? That's optimistic. ;-)

However, since this is aimed at experimental I'd be fine if some
text were added that pointed out the alternatives and the differences
between the various flows. That way, the issue could be revisited
if/when the spec were put on the standards track.

S.

> Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DKoga1082473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 13:50:42 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DKofSB082469; Wed, 13 May 2009 13:50:41 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DKoT6p082444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 May 2009 13:50:40 -0700 (MST) (envelope-from [email-masked])
Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id F19C732861; Wed, 13 May 2009 21:50:27 +0100 (IST)
Received: from [10.87.48.9] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id n4DKoPgg006448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 May 2009 21:50:26 +0100
Message-ID: <[email-masked]>
Date: Wed, 13 May 2009 21:53:04 +0100
From: Stephen Farrell
User-Agent: Thunderbird 2.0.0.21 (X11/20090302)
MIME-Version: 1.0
To: Paul Hoffman
CC: Stephen Kent , [email-masked]
Subject: Re: straw poll
References:
In-Reply-To:
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0)
X-Spam-Score: 0.00 () [Hold at 8.00]
X-Canit-Stats-ID: 42364578 - 1c8862ad63cd (trained as not-spam)
X-CanItPRO-Stream: outgoing
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul Hoffman wrote:
> At 2:00 PM -0400 5/13/09, Stephen Kent wrote:
>> Please indicate your support for
>> - new supercedes old
>> - new is a peer of old
>
> "Supercedes" is not an IETF procedures verb, I believe. "Updates" and/or "obsoletes" are terms more commonly understood in the IETF, given that they appear at the top of RFCs.
>
> For a document such as the ASN.1 modules document, "updates" would mean "adds the new module into the previous specification", similar to a new protocol extension updating the existing protocol. "Obsoletes" would mean "the new module replaces the module in the previous specification".
>
> Do you maybe want to start the poll again (and, if so, might you make the subject line a bit more descriptive)?

Yeah - gotta say that the original mail confused me too so maybe
starting over would be good. OTOH, I'll be for "updates" and against
"obsoletes" in any case - I don't think we should require the
new ASN.1.

S.

> --Paul Hoffman, Director
> --VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DKdpl0081562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 13:39:51 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DKdpPg081561; Wed, 13 May 2009 13:39:51 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DKdeG7081535 for ; Wed, 13 May 2009 13:39:50 -0700 (MST) (envelope-from [email-masked])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn1.fre.skanova.net (7.3.129) (authenticated as u18116613) id 49CCDA0D00718061; Wed, 13 May 2009 22:39:39 +0200
Message-ID:
From: "Anders Rundgren"
To: , "Stephen Kent"
References:
In-Reply-To:
Subject: Re: cert image I-D
Date: Wed, 13 May 2009 22:39:45 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I believe this effort suffers from more technical hurdles than the authors
are aware of. Just defining exactly how and where in a browser's TLS
client-cert-auth the image is supposed to be introduced is not trivial
because there is a battle going on between the browser/OS and the
vendors of card middleware for the GUI. Currently the latter often
does a better job than the rather complacent browser vendors.

The sample given by Siddharth probably utilized some kind
of application-level thingy which BTW points to another issue:
Quite a bunch of current PKI implementations actually do not use TLS-
client-cert-auth but rather use proprietary app-level authentication schemes.
One the few non-internal PKIs used by the USG, namely the
USPTO's filing system is apparently one of these systems.

It is also worth noting that Information Cards do not use TLS-client
cert-auth even when the primary authentication is based on PKI.
Probably MSFT drew the same conclusion as many others have
before them: TLS-client-cert-auth is an ugly beast on the web,
app-level authentication works better; it is at least much prettier :-)

Although providing an "upgrade path" sounds like a good solution
it often works in the opposite way by "the least common denominator rule".
60% of enterprises use IE6 despite been EOLed since 5 years back!

Time will tell, but personally I do not believe you get very far unless you
take on the entire browser/keystore/provisioning/authentication space
otherwise the incentive for changing (anything) will simply be too small.

Which is thus exactly what my counter-proposal does........

Anders

----- Original Message -----
From: "Stephen Kent"
To:
Sent: Wednesday, May 13, 2009 19:56
Subject: cert image I-D

Folks,

I have reviewed the discussion on the list re Stefan's cert image
proposal. While there were comments for and against, the positive
comments, especially from folks who are in a position to make use of
this feature, were persuasive.

We will proceed with this a a new PKIX WG work item. This is not a
guarantee that the WG will approve a document, but rather that we
will explore approaches to achieving the goals described by Stefan
and try to come to consensus on a specific technical approach. We can
decide later whether this is standards track, experimental or even
informational.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DK0eFu078051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 13:00:40 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DK0dKk078050; Wed, 13 May 2009 13:00:39 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DK0UpK078034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 13:00:31 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Wed, 13 May 2009 13:00:29 -0700
To: Stephen Kent , [email-masked]
From: Paul Hoffman
Subject: Re: straw poll
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 2:00 PM -0400 5/13/09, Stephen Kent wrote:
>Please indicate your support for
> - new supercedes old
> - new is a peer of old

"Supercedes" is not an IETF procedures verb, I believe. "Updates" and/or "obsoletes" are terms more commonly understood in the IETF, given that they appear at the top of RFCs.

For a document such as the ASN.1 modules document, "updates" would mean "adds the new module into the previous specification", similar to a new protocol extension updating the existing protocol. "Obsoletes" would mean "the new module replaces the module in the previous specification".

Do you maybe want to start the poll again (and, if so, might you make the subject line a bit more descriptive)?

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DJRRjn075650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 12:27:27 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DJRQfN075649; Wed, 13 May 2009 12:27:26 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DJRPMh075642 for ; Wed, 13 May 2009 12:27:26 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-006.bbn.com ([128.89.89.6]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M4K6s-0002XC-Dv; Wed, 13 May 2009 15:27:23 -0400
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Wed, 13 May 2009 15:27:18 -0400
To: Stefan Santesson
From: Stephen Kent
Subject: Re: WG Last Call on draft-ietf-pkix-tac-03
Cc: [email-masked]
Content-Type: multipart/alternative; boundary="============_-969879654==_ma============"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--============_-969879654==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Stefan,

Here are my responses to your (repeated) questions:

>Before closing this WGLC.
>
>I have not seen any reply to David Copper's comment as part of this WGLC.
>I think this model is a valid alternative.
>
>Does the authors intend to make a response?
>
>I would also like to add the following comments:
>
>1) The term "Anonymous Issuer".
>I believe that I proposed this term to be changed to "Anonymity
>Issuer" and that this proposal was accepted. "Anonymous Issuer" may
>fool the reader to believe that the issuer is anonymous which is not
>the case.

I think Jean-Marc's suggestion "Anonymizing Issuer" is even more
descriptive. I think we can make that change, if my co-authors do not
object.

>2) Short version flow description
>This is just a suggestion to the authors to increase the readability
>of the document.
>I would suggest that the document was rearranged slightly to first
>provide a short description if the certificate issuance and name
>recovery flows without any juicy technical details. Then I would
>provide the technical details of each step in a following section.
>This would make it a lot easier and faster to understand the basic
>architecture.

I agree that this would make the document more readable. We can add
such text as part of the intro.

>3) Nit from section 5.1 step 4
>The following text is a bit confusing
>"Token is the value of the certificate request"
>
>A reader may misunderstand this to mean that the certificate request
>IS the token.
>The token is carried in the certificate request, which is slightly different.

Good point, we can edit the text to avoid this confusing statement.

>4) Conceptual question
>I have another conceptual question.
>
>Wouldn't it be possible to achieve the same anonymity assurance
>without doing the blind signature (step 4-5).
>This is also the question using Stephen's and David's altered model.
>
>The AI already knows that the request is genuine because the user
>provides a valid token.
>The AI can now issue an anonymous certificate that is unknown to BI.
>In case of problems, AI releases the token that can be sent to BI
>for identification of the user.
>
>What extra level of assurance for anonymity is given to the user by
>the threshold signature scheme?
>
>I can see that it prevents AI from issuing certificates on its own,
>and thus is an assurance that there actually exist a BI record that
>the BI will honor in case of problems, but if AI was trusted to only
>issue valid certificates based on valid tokens, then what is the
>gain?
>
>The follow up question is: If there as a reasonable mode where this
>protocol can be used without deploying the threshold signature
>scheme, then wouldn't it be valid to describe that as an optional
>scenario within which the basic protocol can be used?

The use of a split signature scheme contributes to the argument that
the TAC CA is taking precautions to help preserve user anonymity in
the issuance process. The use of this mechanism is not directly
visible to the user, as you and others ave noted. However, in many
contexts, a CA operating a TAC service may need to satisfy
accreditors that it is providing this service in a trustworthy
fashion. This is what motivated the KISA folks, who perform
assessments of CAs in their country, to call for use of the
split-signing approach. Thus the use of split-signing is not an
arbitrary, academic proposal, but rather is motivated by the
experience of a group of folks who perform CA evaluations and who
want to have an RFC that they can cite as the basis for their
evaluations of TAC CAs. I think we should defer to their experience
as CA evaluators in this instance.

Steve
--============_-969879654==_ma============
Content-Type: text/html; charset="us-ascii"

Stefan,

Here are my responses to your (repeated) questions:

Before closing this
WGLC.

I have not seen any reply to David Copper's comment as part of this
WGLC.

I think this model is a valid alternative.

Does the authors intend to make a response?

I would also like to
add the following comments:

1) The term
"Anonymous Issuer".

I believe that I proposed this term to be changed to "Anonymity
Issuer" and that this proposal was accepted. "Anonymous Issuer"
may fool the reader to believe that the issuer is anonymous which is
not the case.

I think Jean-Marc's suggestion "Anonymizing Issuer" is
even more descriptive. I think we can make that change, if my
co-authors do not object.

2) Short version
flow description

This is just a suggestion to the authors to increase the
readability of the document.

I would suggest that the document was rearranged slightly to first
provide a short description if the certificate issuance and name
recovery flows without any juicy technical details. Then I would
provide the technical details of each step in a following section.
This would make it a lot easier and faster to understand the basic
architecture.

I agree that this would make the document more readable.  We
can add such text as part of the intro.

3) Nit from
section 5.1 step 4

The following text is a bit confusing

"Token is the value of the
certificate request"

A reader may misunderstand this to mean that the certificate request
IS the token.

The token is carried in the certificate request, which is slightly
different.

Good point, we can edit the text to avoid this confusing
statement.

4) Conceptual
question

I have another conceptual question.

Wouldn't it be possible to achieve the same anonymity assurance
without doing the blind signature (step 4-5).

This is also the question using Stephen's and David's altered
model.

The AI already knows that the request is genuine because the user
provides a valid token.

The AI can now issue an anonymous certificate that is unknown to BI.
In case of problems, AI releases the token that can be sent to BI for
identification of the user.

What extra level of assurance for anonymity is given to the user by
the threshold signature scheme?

I can see that it prevents AI from issuing certificates on its own,
and thus is an assurance that there actually exist a BI record that
the BI will honor in case of problems, but if AI was trusted to only
issue valid certificates based on valid tokens, then what is the
gain?

The follow up
question is: If there as a reasonable mode where this protocol can be
used without deploying the threshold signature scheme, then wouldn't
it be valid to describe that as an optional scenario within which the
basic protocol can be used?

The use of a split signature scheme contributes to the argument
that the TAC CA is taking precautions to help preserve user anonymity
in the issuance process. The use of this mechanism is not directly
visible to the user, as you and others ave noted. However, in many
contexts, a CA operating a TAC service may need to satisfy accreditors
that it is providing this service in a trustworthy fashion. This is
what motivated the KISA folks, who perform assessments of CAs in their
country, to call for use of the split-signing approach. Thus the use
of split-signing is not an arbitrary, academic proposal, but rather is
motivated by the experience of a group of folks who perform CA
evaluations and who want to have an RFC that they can cite as the
basis for their evaluations of TAC CAs.  I think we should defer
to their experience as CA evaluators in this instance.

Steve

--============_-969879654==_ma============--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DJRMAc075638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 12:27:22 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DJRMWm075637; Wed, 13 May 2009 12:27:22 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DJRM8S075631 for ; Wed, 13 May 2009 12:27:22 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-006.bbn.com ([128.89.89.6]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M4K6q-0002XC-G7; Wed, 13 May 2009 15:27:21 -0400
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Wed, 13 May 2009 15:20:40 -0400
To: "Carl Wallace"
From: Stephen Kent
Subject: RE: straw poll
Cc:
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 2:19 PM -0400 5/13/09, Carl Wallace wrote:
>Does this have any bearing on whether the draft proceeds as a standards
>track document or as informational?
>

Yes.

Tim asked us to conduct the straw poll and provide the results to him
as an input in his decision process, as described in the meeting
minutes.

He wanted this to be separate from the WGLC on the document.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DIJeZK070414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 11:19:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DIJe0j070413; Wed, 13 May 2009 11:19:40 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DIJT0B070398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 May 2009 11:19:40 -0700 (MST) (envelope-from [email-masked])
Received: from unknown [65.242.48.5] by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with SMTP id c3f0b0a4.2157575088.93441.00-005.p03c11o141.symantecmail.net (envelope-from ); Wed, 13 May 2009 12:19:40 -0600 (MDT)
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
Subject: RE: straw poll
Date: Wed, 13 May 2009 14:19:25 -0400
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: straw poll
Thread-Index: AcnT9rmmAL+PyuykRreGuIkUzVMVVwAACTJQ
References:
From: "Carl Wallace"
To: "Stephen Kent" ,
X-Spam: [F=0.2000000000; S=0.200(2009020301)]
X-MAIL-FROM:
X-SOURCE-IP: [65.242.48.5]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Does this have any bearing on whether the draft proceeds as a standards
track document or as informational?=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: Wednesday, May 13, 2009 2:00 PM
To: [email-masked]
Subject: straw poll

At the SF meeting Tim Polk asked us to conduct a straw poll on=20
whether the new ASN.1 for PKIX standards should replace the old ASN.1=20
or be considered as an equal alternative to it.

Please indicate your support for
- new supercedes old
- new is a peer of old

The straw poll will close on 5/22.

Thanks,

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DI0M6r068921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 11:00:23 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DI0MiJ068917; Wed, 13 May 2009 11:00:22 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DI0BuI068901 for ; Wed, 13 May 2009 11:00:21 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-006.bbn.com ([128.89.89.6]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M4IkV-0001Md-Df for [email-masked]; Wed, 13 May 2009 14:00:11 -0400
Mime-Version: 1.0
Message-Id:
Date: Wed, 13 May 2009 14:00:08 -0400
To: [email-masked]
From: Stephen Kent
Subject: straw poll
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At the SF meeting Tim Polk asked us to conduct a straw poll on
whether the new ASN.1 for PKIX standards should replace the old ASN.1
or be considered as an equal alternative to it.

Please indicate your support for
- new supercedes old
- new is a peer of old

The straw poll will close on 5/22.

Thanks,

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DI0M54068922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 11:00:23 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DI0MHx068920; Wed, 13 May 2009 11:00:22 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DI0Bw8068900 for ; Wed, 13 May 2009 11:00:21 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-006.bbn.com ([128.89.89.6]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M4IkU-0001Md-FH for [email-masked]; Wed, 13 May 2009 14:00:10 -0400
Mime-Version: 1.0
Message-Id:
Date: Wed, 13 May 2009 13:56:17 -0400
To: [email-masked]
From: Stephen Kent
Subject: cert image I-D
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Folks,

I have reviewed the discussion on the list re Stefan's cert image
proposal. While there were comments for and against, the positive
comments, especially from folks who are in a position to make use of
this feature, were persuasive.

We will proceed with this a a new PKIX WG work item. This is not a
guarantee that the WG will approve a document, but rather that we
will explore approaches to achieving the goals described by Stefan
and try to come to consensus on a specific technical approach. We can
decide later whether this is standards track, experimental or even
informational.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DHjDjE067192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 10:45:13 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DHjDlP067191; Wed, 13 May 2009 10:45:13 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DHiwkH067161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 May 2009 10:45:11 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 8396 invoked from network); 13 May 2009 17:45:03 -0000
Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 13 May 2009 17:45:03 -0000
Received: (qmail 86350 invoked from network); 13 May 2009 17:44:56 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 13 May 2009 17:44:56 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Wed, 13 May 2009 19:44:55 +0200
Subject: Re: WG Last Call on draft-ietf-pkix-tac-03
From: Stefan Santesson
To: Stefan Santesson , "David A. Cooper" , ??? , pkix , Stephen Farrell
Message-ID:
Thread-Topic: WG Last Call on draft-ietf-pkix-tac-03
Thread-Index: AcnMrfPk9vFJDCfoOU+tNpdm9rQSLAHRJKuX
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3325088696_74711075"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> 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_3325088696_74711075
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

We had some traffic on this draft, but I could see no reply to my questions
below.

On 09-05-04 1:46 PM, "Stefan Santesson" wrote:

> Before closing this WGLC.
>=20
> I have not seen any reply to David Copper=B9s comment as part of this WGLC.
> I think this model is a valid alternative.
>=20
> Does the authors intend to make a response?
>=20
> I would also like to add the following comments:
>=20
> 1) The term =B3Anonymous Issuer=B2.
> I believe that I proposed this term to be changed to =B3Anonymity Issuer=B2 a=
nd
> that this proposal was accepted. =B3Anonymous Issuer=B2 may fool the reader t=
o
> believe that the issuer is anonymous which is not the case.
>=20
> 2) Short version flow description
> This is just a suggestion to the authors to increase the readability of t=
he
> document.
> I would suggest that the document was rearranged slightly to first provid=
e a
> short description if the certificate issuance and name recovery flows wit=
hout
> any juicy technical details. Then I would provide the technical details o=
f
> each step in a following section. This would make it a lot easier and fas=
ter
> to understand the basic architecture.
>=20
> 3) Nit from section 5.1 step 4
> The following text is a bit confusing
> "Token is the value of the certificate request"
>=20
> A reader may misunderstand this to mean that the certificate request IS t=
he
> token.
> The token is carried in the certificate request, which is slightly differ=
ent.
>=20
> 4) Conceptual question
> I have another conceptual question.
>=20
> Wouldn=B9t it be possible to achieve the same anonymity assurance without d=
oing
> the blind signature (step 4-5).
> This is also the question using Stephen=B9s and David=B9s altered model.
>=20
> The AI already knows that the request is genuine because the user provide=
s a
> valid token.=20
> The AI can now issue an anonymous certificate that is unknown to BI. In c=
ase
> of problems, AI releases the token that can be sent to BI for identificat=
ion
> of the user.
>=20
> What extra level of assurance for anonymity is given to the user by the
> threshold signature scheme?
>=20
> I can see that it prevents AI from issuing certificates on its own, and t=
hus
> is an assurance that there actually exist a BI record that the BI will ho=
nor
> in case of problems, but if AI was trusted to only issue valid certificat=
es
> based on valid tokens, then what is the gain?
>=20
> The follow up question is: If there as a reasonable mode where this proto=
col
> can be used without deploying the threshold signature scheme, then wouldn=
=B9t it
> be valid to describe that as an optional scenario within which the basic
> protocol can be used?
>=20
> /Stefan
>=20
>=20
>=20
> On 09-04-03 4:27 PM, "David A. Cooper" wrote:
>=20
>> I think that Stephen makes a great point.=A0 Stephen's point is that in ma=
ny
>> cases it is possible to learn someone's true identity even if one is onl=
y
>> provided the IP address from which the person was communicating.=A0 So, it
>> would not matter that the TAC protocol does not provide the AI with any
>> identity information.
>>=20
>> I also do not agree that the TAC cannot be sent directly from the BI to =
the
>> user.=A0 The protocol could be reworked to address Stephen's concern.=A0 The
>> basic idea for the protocol would be as follows:
>>=20
>> step 1: The user creates a certificate request message and encrypts it w=
ith a
>> session key, which is in turn encrypted using the AI's public key.
>>=20
>> step 2: The user authenticates to the BI and provides the BI with the
>> encrypted certificate request message.
>>=20
>> step 3: The BI creates a Token for the user and sends the Token and the
>> encrypted certificate request message to the AI over a channel that is
>> protected using two-way authenticated TLS.
>>=20
>> step 4: The AI decrypts the certificate request message and creates the
>> TBSCertificate.
>>=20
>> (If it is considered necessary): steps 5 and 6:=A0 The AI and the BI joint=
ly
>> sign the TBSCertificate using the blinded, split signature scheme.
>>=20
>> step 7: The AI encrypts the signed certificate (TAC) using the session k=
ey
>> that was created by the user in step 1 and sends the encrypted TAC and t=
he
>> Token to the BI.
>>=20
>> step 8: The BI sends the encrypted TAC to the user.
>>=20
>> [Note that to maximize privacy, the encrypted certificate request messag=
e and
>> the encrypted TAC could both be padded to a fixed length to ensure that =
the
>> BI could not learn anything from the lengths of these messages.]
>>=20
>> I wrote out this protocol fairly quickly, so I may not have gotten all o=
f the
>> details correct, but I think the basic idea is correct.=A0 It seems to ret=
ain
>> all of the properties of the current protocol while also helping to addr=
ess
>> the flaw that Stephen identified.
>>=20
>> Dave
>>=20
>> SangHwan Park wrote:
>>> =20
>>> =20
>>>=20
>>> Dear Stephen,
>>> =20
>>> =A0
>>> =20
>>> Thank you for the comments.
>>> =20
>>> =A0
>>> =20
>>> I=B9ve included my responses inline below.
>>> =20
>>> =A0
>>> =20
>>>> > A couple of comments:
>>> =20
>>> =A0
>>> =20
>>>> >#1: Top of p7:
>>> =20
>>>> >=A0 "To effect issuance of the TAC, the AI interacts with
>>> =20
>>>> >=A0=A0 the BI, over a secure channel, to jointly create the signature on
>>> =20
>>>> >=A0=A0 the TAC, and sends the signed TAC to the user.
>>> =20
>>>> >=A0
>>> =20
>>>> >=A0=A0 The AI does this without learning the user's real identity
>>> =20
>>>> >=A0=A0 (either from the user or from the BI)."
>>> =20
>>>> >=A0
>>> =20
>>>> >If the AI sends the TAC to the user, then it will know some
>>> =20
>>>> >form of identity for that user, even if that's only an IP
>>> =20
>>>> >address. (And with the likes of SAVI, that could well be
>>> =20
>>>> >enough to establish a real identity.)
>>> =20
>>>> >=A0
>>> =20
>>>> >I'd have thought it'd be much better to return the TAC
>>> =20
>>>> >via the BI and not require any user<->AI direct connections?
>>> =20
>>> =A0
>>> =20
>>> According to the concept of separation of CA authorities in this docume=
nt,
>>> BI only identify user=B9s real identity and AI only issue TAC with the he=
lp of
>>> BI without disclosing user=B9s real identity. As you suggested if we allo=
w BI
>>> to send TAC to users not from AI, BI can trace user=B9s real identity
>>> unilaterally. It means it is against our concept. And AI can=B9t trace th=
eir
>>> real identity with IP address alone, collected in the issuance process
>>> because AI does not have any identity information for users. For this
>>> reason, it makes sense to require AI to send TAC to users.
>>> =20
>>> =A0
>>> =20
>>=20
>>=20
>=20

--B_3325088696_74711075
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: WG Last Call on draft-ietf-pkix-tac-03

We had some traffic on this draft, but I could see no reply to my question=
s below.

On 09-05-04 1:46 PM, "Stefan Santesson" <[email-masked]> wrote:

<=
SPAN STYLE=3D'font-size:11pt'>Before closing this WGLC.

I have not seen any reply to David Copper’s comment as part of this W=
GLC.

I think this model is a valid alternative.

Does the authors intend to make a response?

I would also like to add the following comments:

1) The term “Anonymous Issuer”.

I believe that I proposed this term to be changed to “Anonymity I=
ssuer” and that this proposal was accepted. “Anonymous Issuer=
221; may fool the reader to believe that the issuer is anonymous which is no=
t the case.

2) Short version flow description

This is just a suggestion to the authors to increase the readability of=
the document.

I would suggest that the document was rearranged slightly to first provide =
a short description if the certificate issuance and name recovery flows with=
out any juicy technical details. Then I would provide the technical details =
of each step in a following section. This would make it a lot easier and fas=
ter to understand the basic architecture.

3) Nit from section 5.1 step 4

The following text is a bit confusing

"Token is the value of the certificate request"

A reader may misunderstand this to mean that the certificate request IS the=
token.

The token is carried in the certificate request, which is slightly differen=
t.

4) Conceptual question

I have another conceptual question.

Wouldn’t it be possible to achieve the same anonymity assurance witho=
ut doing the blind signature (step 4-5).

This is also the question using Stephen’s and David’s altered m=
odel.

The AI already knows that the request is genuine because the user provides =
a valid token.

The AI can now issue an anonymous certificate that is unknown to BI. In cas=
e of problems, AI releases the token that can be sent to BI for identificati=
on of the user.

What extra level of assurance for anonymity is given to the user by the thr=
eshold signature scheme?

I can see that it prevents AI from issuing certificates on its own, and thu=
s is an assurance that there actually exist a BI record that the BI will hon=
or in case of problems, but if AI was trusted to only issue valid certificat=
es based on valid tokens, then what is the gain?

The follow up question is: If there as a reasonable mode where this protoco=
l can be used without deploying the threshold signature scheme, then wouldn&=
#8217;t it be valid to describe that as an optional scenario within which th=
e basic protocol can be used?

/Stefan

On 09-04-03 4:27 PM, "David A. Cooper" <[email-masked]> wrote:

<=
SPAN STYLE=3D'font-size:11pt'>I think that Stephen makes a great point.=A0 Steph=
en's point is that in many cases it is possible to learn someone's true iden=
tity even if one is only provided the IP address from which the person was c=
ommunicating.=A0 So, it would not matter that the TAC protocol does not provid=
e the AI with any identity information.

I also do not agree that the TAC cannot be sent directly from the BI to the=
user.=A0 The protocol could be reworked to address Stephen's concern.=A0 The ba=
sic idea for the protocol would be as follows:

step 1: The user creates a certificate request message and encrypts it with=
a session key, which is in turn encrypted using the AI's public key.

step 2: The user authenticates to the BI and provides the BI with the encry=
pted certificate request message.

step 3: The BI creates a Token for the user and sends the Token and the enc=
rypted certificate request message to the AI over a channel that is protecte=
d using two-way authenticated TLS.

step 4: The AI decrypts the certificate request message and creates the TBS=
Certificate.

(If it is considered necessary): steps 5 and 6:=A0 The AI and the BI jointly =
sign the TBSCertificate using the blinded, split signature scheme.

step 7: The AI encrypts the signed certificate (TAC) using the session key =
that was created by the user in step 1 and sends the encrypted TAC and the T=
oken to the BI.

step 8: The BI sends the encrypted TAC to the user.

[Note that to maximize privacy, the encrypted certificate request message a=
nd the encrypted TAC could both be padded to a fixed length to ensure that t=
he BI could not learn anything from the lengths of these messages.]

I wrote out this protocol fairly quickly, so I may not have gotten all of t=
he details correct, but I think the basic idea is correct.=A0 It seems to reta=
in all of the properties of the current protocol while also helping to addre=
ss the flaw that Stephen identified.

Dave

SangHwan Park wrote:

<=
SPAN STYLE=3D'font-size:11pt'>

Dear Stephen,

=A0

Thank you for the commen=
ts.

=A0

I’<=
FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">ve included my responses inli=
ne below.

=A0

> A couple of comment=
s:

=A0

>#1: Top of p7:

>=A0 "To effect is=
suance of the TAC, the AI interacts with

>=A0=A0 the BI, over a se=
cure channel, to jointly create the signature on

>=A0=A0 the TAC, and send=
s the signed TAC to the user.

>=A0

>=A0=A0 The AI does this =
without learning the user's real identity

>=A0=A0 (either from the =
user or from the BI)."

>=A0

>If the AI sends the =
TAC to the user, then it will know some

>form of identity for=
that user, even if that's only an IP

>address. (And with t=
he likes of SAVI, that could well be

>enough to establish =
a real identity.)

>=A0

>I'd have thought it'=
d be much better to return the TAC

>via the BI and not r=
equire any user<->AI direct connections?

=A0

Ac=
cording to the concept of separation of CA authorities in this document, BI =
only identify user’s real identity and AI only issue T=
AC with the help of BI without disclosing userR=
17;s real identity. A=
s you suggested if we allow BI to send TAC to users not from AI, BI can trac=
e user’s real identity unilaterally. It means it is against our c=
oncept. And AI can’t trace their real identity with IP address al=
one, collected in the issuance process because AI does not have any identity=
information for users. For this reason, it makes sense to require AI to sen=
d TAC to users.

=A0

=

=

--B_3325088696_74711075--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DFaleU056673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 08:36:47 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DFal56056672; Wed, 13 May 2009 08:36:47 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DFahc1056660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 08:36:44 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Wed, 13 May 2009 08:36:42 -0700
To: Jean-Marc Desperrier , IETF-pkix
From: Paul Hoffman
Subject: Re: Remark on paragraphs 7.3/7.2 : IDN rules in DN versus IDN rules in General Names
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 1:48 PM +0200 5/13/09, Jean-Marc Desperrier wrote:
>But why is UseSTD3ASCIIRules not set ?

Probably an oversight.

>If it were not for this point, it would be possible in paragraph 7.3 to say something like : Just do the same as in paragraph 7.2, considering that changing label separators to U+002E is not applicable as there will not be label separator inside an individual label.

That seems like a reasonable change for RFC 7280.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DBmLXB036575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 04:48:22 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4DBmLaD036573; Wed, 13 May 2009 04:48:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-ft2.fr.colt.net (smtp-ft2.fr.colt.net [213.41.78.204]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4DBm96j036561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 May 2009 04:48:21 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-ex1.fr.colt.net (smtp-ex1.fr.colt.net [213.41.78.194]) by smtp-ft2.fr.colt.net (8.13.8/8.13.8/Debian-3) with ESMTP id n4DBm2Ee009612 for ; Wed, 13 May 2009 13:48:02 +0200
Received: from host.104.92.68.195.rev.coltfrance.com ([195.68.92.104] helo=[172.30.24.37]) by smtp-ex1.fr.colt.net with esmtp (Exim) (envelope-from ) id 1M4CwR-0006LO-1s for ; Wed, 13 May 2009 13:48:07 +0200
Message-ID: <[email-masked]>
Date: Wed, 13 May 2009 13:48:06 +0200
From: Jean-Marc Desperrier
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090510 SeaMonkey/2.0b1pre
MIME-Version: 1.0
To: IETF-pkix
Subject: Remark on paragraphs 7.3/7.2 : IDN rules in DN versus IDN rules in General Names
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ACL-Warn: 1/1 recipients OK.
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi,

I'm currently comparing paragraph 7.3 and 7.2 of RFC5280 and checking
what the difference in the handling of Internationalized Domain Names
inside DN (domainComponent attribute) and inside General Names consists
of exactly.

AFAICT the only difference is between
- the rule given in paragraph 7.3 to include a label inside a
domainComponent attribute and
- the rule given in paragraph 7.2 to include an IDN inside a dNSName
field
and seems to be the following :
* set the UseSTD3ASCIIRules flag for the IDN, don't set it for the
label
* change all label separators to U+002E (full stop) for the IDN,
don't do that for the label

The second step is not applicable for the label, as there will not be a
label separator inside an individual label.

But why is UseSTD3ASCIIRules not set ?

In RFC3490, the consequence of setting UseSTD3ASCIIRules seems to be to
activate the following checks (paragraph 4.1 "ToASCII" ):

[...]

3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
(a) Verify the absence of non-LDH ASCII code points; that is, the
absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
(b) Verify the absence of leading and trailing hyphen-minus; that
is, the absence of U+002D at the beginning and end of the
sequence.

I may be missing something but I don't see why you'd want to check that
for the dNSName field, but not when it's a domainComponent attribute.

For context, I'll precise that the ToASCII operation description starts
with this :

The ToASCII operation takes a sequence of Unicode code points that
make up one label and transforms it into a sequence of code points in
the ASCII range (0..7F). If ToASCII succeeds, the original sequence
and the resulting sequence are equivalent labels.

So as ToASCII is applied to labels individually, there's really no
difference between the case of processing a full IDN and an individual
label.

If it were not for this point, it would be possible in paragraph 7.3 to
say something like : Just do the same as in paragraph 7.2, considering
that changing label separators to U+002E is not applicable as there will
not be label separator inside an individual label.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4CIuWgo074793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2009 11:56:32 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4CIuW1p074790; Tue, 12 May 2009 11:56:32 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4CIuK78074765 for ; Tue, 12 May 2009 11:56:31 -0700 (MST) (envelope-from [email-masked])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn1.fre.skanova.net (7.3.129) id 49CCDA0D006E671E; Tue, 12 May 2009 20:56:18 +0200
Message-ID:
From: "Anders Rundgren"
To: "Bajaj, Siddharth" ,
References:
In-Reply-To:
Subject: Re: draft-santesson-pkix-certimage-00.txt: any example to date?
Date: Tue, 12 May 2009 20:57:17 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Siddharth,

For the record:

There is an entirely different way of achieving the functionality you and others [rightfully]
request:
http://webpki.org/papers/web/multiple-credentials-in-the-enterprise.pdf

This scheme has (like all methods) certain pros and cons:

Pros
- No privacy issues (no "publishing")
- Perfect match with the device GUI through a negotiating protocol
- Does not require CAs keeping myriads of logotypes on-line
- Also supports thumbprint images for usage in menus
- Covers the entire spectrum of 2FA (Two Factor Authentication) credentials

Cons
- Requires adoption of KeyGen2

Is the latter a problem? Of course it is, but it is anyway needed in mobile
phones unless the following is what PKIX [de-facto] prescribe:
http://www.trustdigital.com/downloads/TD_EMM_CAC_Pack_101008.pdf

KeyGen2 + a 50 cent built-in TPM securely emulates $200+ worth of highly
inconvenient c**p, requiring the kind of proprietary middleware which everybody
who has ever toyed with smart cards, know is a real PITA. Unlike the
card solution, The KeyGen2+TPM combo supports multiple issuers making
the cert-image even more interesting. cert-images can hardly be very important
in a situation where you just have a single credential.

Anders

----- Original Message -----
From: Bajaj, Siddharth
To: [email-masked]
Sent: Tuesday, May 12, 2009 00:50
Subject: Re: draft-santesson-pkix-certimage-00.txt: any example to date?

PKIX-folks,

I would like to offer my support for Stefan's draft. I've worked for a large CA for the last 10
years
and see this work as an important 'building block' in addressing the usabillity issues with
client certificates.

At VeriSign, we worked on an ActiveX control/Java plug-in called the Personal Trust Agent (PTA)
over 10 years ago. Among other things it tried to provide a visual representation of a certificate
that tried to mimic the physical forms of identity that the user is familiar with - driver's
license,
credit cards, etc. This solution was used in large deployments by many financial institutions,
mainly outside the US.

More recently, we have seen the emergence of the 'Infocard' paradigm that also tries to provide
a visual representation of a digital identity that mimics the physical identity cards that the user
is
familiar with, through Card Image.

Stefan's proposal is powerful because it can provide a standardized and user-friendly metaphor
for representing certificates in various UI contexts.

This draft will also serve to bring the different underlying technologies such as Cardspace and
X.509 certificates closer together in terms of the user experience - by using the similar visual
metaphors to represent the user's credential/identity.

Thanks,

Siddharth
Principal, Innovation,
VeriSign, Inc.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4BMp1Dk097295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 May 2009 15:51:02 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4BMp1Mr097294; Mon, 11 May 2009 15:51:01 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4BMoo2L097274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 May 2009 15:51:01 -0700 (MST) (envelope-from [email-masked])
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n4BMoo6G003955 for ; Mon, 11 May 2009 15:50:50 -0700
Received: from MOU1WNEXMB03.vcorp.ad.vrsn.com ([10.25.13.156]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 May 2009 15:50:50 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C9D28A.EE34CB05"
Subject: Re: draft-santesson-pkix-certimage-00.txt: any example to date?
Date: Mon, 11 May 2009 15:50:53 -0700
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Re: draft-santesson-pkix-certimage-00.txt: any example to date?
Thread-Index: AcnSivBoUvbHMir3RJK1wrYhdFCu1Q==
From: "Bajaj, Siddharth"
To:
X-OriginalArrivalTime: 11 May 2009 22:50:50.0022 (UTC) FILETIME=[EE301C60:01C9D28A]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9D28A.EE34CB05
Content-Type: multipart/alternative;
boundary="----_=_NextPart_002_01C9D28A.EE34CB05"

------_=_NextPart_002_01C9D28A.EE34CB05
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
PKIX-folks,=20
=20
I would like to offer my support for Stefan's draft. I've worked for a
large CA for the last 10 years
and see this work as an important 'building block' in addressing the
usabillity issues with=20
client certificates.=20
=20
At VeriSign, we worked on an ActiveX control/Java plug-in called the
Personal Trust Agent (PTA)
over 10 years ago. Among other things it tried to provide a visual
representation of a certificate
that tried to mimic the physical forms of identity that the user is
familiar with - driver's license,=20
credit cards, etc. This solution was used in large deployments by many
financial institutions,=20
mainly outside the US.=20
=20
=20
=20
=20
More recently, we have seen the emergence of the 'Infocard' paradigm
that also tries to provide
a visual representation of a digital identity that mimics the physical
identity cards that the user is
familiar with, through Card Image.=20
=20
Stefan's proposal is powerful because it can provide a standardized and
user-friendly metaphor=20
for representing certificates in various UI contexts.=20
=20
This draft will also serve to bring the different underlying
technologies such as Cardspace and=20
X.509 certificates closer together in terms of the user experience - by
using the similar visual=20
metaphors to represent the user's credential/identity.=20
=20
Thanks,
=20
Siddharth
Principal, Innovation,
VeriSign, Inc.=20
=20

------_=_NextPart_002_01C9D28A.EE34CB05
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

PKIX-folks,=20

I =
would like to=20
offer my support for Stefan's draft. I've worked for a large CA for the =
last 10=20
years

and =
see this work as=20
an important 'building block' in addressing the usabillity issues =
with=20

client =
certificates.=20

At =
VeriSign, we=20
worked on an ActiveX control/Java plug-in called the Personal Trust =
Agent=20
(PTA)

over =
10 years ago.=20
Among other=20
things it tried to provide a visual representation of a=20
certificate

that =
tried to mimic=20
the physical forms of identity that the user is familiar with - driver's =

license,

credit =
cards, etc.=20
This solution was used in large deployments by many financial =
institutions,=20

mainly =
outside the=20
US.

More =
recently, we=20
have seen the emergence of the 'Infocard' paradigm that also tries to=20
provide

a =
visual=20
representation of a digital identity that mimics the physical identity =
cards=20
that the user is

familiar with,=20
through Card Image.

Stefan's proposal is=20
powerful because it can provide a standardized and user-friendly =
metaphor=20

for =
representing=20
certificates in various UI contexts.

This =
draft will also=20
serve to bring the different underlying technologies such as Cardspace =
and=20

X.509 =
certificates=20
closer together in terms of the user experience - by using the =
similar=20
visual

metaphors to=20
represent the user's credential/identity.

Thanks,

Siddharth

Principal,=20
Innovation,

VeriSign, Inc.=20

------_=_NextPart_002_01C9D28A.EE34CB05--

------_=_NextPart_001_01C9D28A.EE34CB05
Content-Type: image/jpeg;
name="Outlook.jpg"
Content-Transfer-Encoding: base64
Content-ID: <593262522@11052009-2FBD>
Content-Description: Outlook.jpg
Content-Location: Outlook.jpg

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcU
FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgo
KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCADZANQDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1/wCM
fjHXvCn9mr4a02DUrq5SeR4ZZdh2RIZGKDI3HaCdoyTjgV45d/tCeNLS4MM3he08weUCEeR8GRQy
KSpOGIYfL1B4IBBFehftHab4ju5/C154St/OvrC4klIMiIu0qAVYMwDKwJUr3BIPBrx/T7L4pWUr
Sr4esJJDqX9p5eaIYfzIJPLG2UYjzbRDZ0AXjGAR7uCpYZ0U6nK35uz39exnJu+h0knx78axWKXc
3h3S4oHkESeZd7Wd9sbbVUvuYgTRk4HAbnGDiFf2g/G7EBPCUb5zgoszA4OCQR1Ge4rl00P4lpbS
QDw7abHSzRgbtSv+jLCsTbPO2hsQDLAbsO4BAOB0F0PiMmn3H2Dw/HHqV8sSXk63EcQ8uNYVEagT
nIIgVWPAKlgVy2R0ulg10h/4F/wSbyNLQvjt45122efSvDWmTxqXXH2vYzFIzIwVWcFiEVjwD0qg
37RfjFSobwtAC2zaCswzvJC4+pBA9cGuP/4Rf4ox6XqdhaWElnbalcvc3S21/HH5u9SrRtiXDJgn
5Tmuivj8VbyeOV/DenxlLsXpWK6CK0mbgsCBP91vtUm5RgNxnq26nRwSeig1/i/4IXkX4v2ifGcw
jMXhSJxIWCFVmO4rwceuMc1Z074+eOdRSd7TwraMkNvNcu7ySIvlxAmQgsQCVAPAyeOlZck/xZe3
uo/+EesFkuLZ7V5/tQMu0/aMHcZydy/a5cN1+6TnHLLj/hZstrrMMfg3QbdtX883csBjSSQyi4BY
nzuSBcuATnAVeuDmXSwfSMP/AAL/AIIXkaw+P/jR9Ms7+Lw5ps1vdyvBB5NyZHd0VWceWrFhhXUn
I/iFVF/aP8XMHK+GbYhAzOR53yhQCxPPAAZSfTI9a5Tw34W+I/h9NPWz8PWjixkvJY/NuIjk3MCQ
SZxKOAqAjGMHOcjittIfidHZtbw+FtOi3xTpJLHeFXkeaOONpSRcYDhYUA2gD73B3HNOjgU9FB/9
vevn6BeR0Vj8cvH99q+p6Xa+EbWTUNNilnu4PMcNEkX3yct24GBySQBnIqhF+0T4zmWJofCkUizA
mMqsxDgdcetczaaH8TbPXtS1i10CxS/1DUI9RlcyQOBIkjSYUNIQAXYN/eG0YIGQd1bTx1aaSLey
8J2Uk8yQR3AmljEYSFIFjVR9oYkj7Onz5U8dMnITpYJPaD/7e+/qF5F2L9oPxtLbS3CeFITBFAbp
nxMB5QZVLjnlcunI/vCs7/hp/wAQ/wDQE07/AL+Sf41Q1ax+KeraVf6fqGhWs1td2sNowe7QmNIh
Ft2Zm+X5oVc9izMcc4rh/wDhUnjf/oCf+TcH/wAXWtOhl7Xv8q/7e/4Im59D0f8A4af8Q/8AQE07
/v5J/jR/w0/4h/6Amnf9/JP8a84/4VJ43/6An/k3B/8AF0f8Kk8b/wDQE/8AJuD/AOLrT6vlneP/
AIF/wRXmej/8NP8AiH/oCad/38k/xo/4af8AEP8A0BNO/wC/kn+Necf8Kk8b/wDQE/8AJuD/AOLo
/wCFSeN/+gJ/5Nwf/F0fV8s7x/8AAv8AgheZ6P8A8NP+If8AoCad/wB/JP8AGj/hp/xD/wBATTv+
/kn+Necf8Kk8b/8AQE/8m4P/AIuj/hUnjf8A6An/AJNwf/F0fV8s7x/8C/4IXmej/wDDT/iH/oCa
d/38k/xo/wCGn/EP/QE07/v5J/jXnH/CpPG//QE/8m4P/i6P+FSeN/8AoCf+TcH/AMXR9XyzvH/w
L/gheZ6P/wANP+If+gJp3/fyT/Gj/hp/xD/0BNO/7+Sf415x/wAKk8b/APQE/wDJuD/4uj/hUnjf
/oCf+TcH/wAXR9XyzvH/AMC/4IXme8fDn4z+JfGsmphLXSbGOwhE0jv50mQTjgKc9q1PEXxU1nSx
pRguNE1KG/1CLT2ez8392XXO4MWwSBg4HqK8t+F3h3xl4KOrmXwzNcm/hWENFf28bR4JO4Esefwr
S1XQ9evRoNraeE7jS9PsNVi1CQyalFOqKM7yo3buclj1ycnqTnxcXCjHEWpcvJp1Xz6msW7an0p8
Mrme8+G3hO6vJpZ7mfSbSSWWVyzyO0KEsxPJJJJJNFRfCf8A5JZ4N/7Atl/6ISivJLG+OP8AW2n+
639K4+e9tYPtHn3MEf2eITzb5AvlRndh2z0X5G5PHyn0Ndh44/1tp/ut/SvKvFWgajqNxqQ09rTy
NXsE026eeRla3RWl+eNQpDsRO/BKjKrzycAHW0VwWqeHPE851L7HqpiD3UU0AN/KC8YmLvHkJiEb
CF4EmcDOBxWxoWkarYTtPd3r3Lrp0NvHHLdSOonDStIzcANndEu/buIU8DoQDft7q3uWmW2nimMM
hilEbhvLcAEq2OhwQcH1FJ9stvtIt/tEP2gnAi3jd0z069Dn6V58PA+taUqz6BqaC7nlivL8TSmJ
bi4SUOwyiZ2OrShsg9EGDyRSh+HmuwyzXQ1VG1GWxQfaftUyut2LTyNxOMsu9Q+48ndgr8oyAeq1
G08SzCJpUEpxhCwyc5I4/wCAt+R9K4HUvC/ie6OqLFrMsSzSsYHXUJV+RrpJMbVQGMrErRgqzZ3H
oDxNa+FNch1e1vP7VwxhSG5k+0SMxCJdKvB4fmeJsEjmMnknNAHeVHHPFIxWOVGYZ4VgTwcH8iCP
rXnd94b8XzaWEtb2K1vPKkiOzWLlhuMcYSYu0Zzhlc+WFUfNndnOXN4U8SwxSrY38UK/bGuhCt/M
qzBrrzmRmC5jyrMmVBzjJ+8QAD0aiuN0zQNeg1jSbu61VpIbeGKO4i+1SsrkJc7/AJSMP80lvhmw
SIyeOh7KgAooooAKKKKAPMtdPhyHx7rFx4newwLa1igS8J2/M+ZHA7lUU8dfm4rntQ8M+FRJoUb3
MpfUWtEiWG4SAiKVwZZtrREuql3UZbpGckYGcj41/wDI8y/9cI/5Vu3nj/w7dailpPZrcaRbyWtp
aPPYI7QwQWkg8w8bmBndSVJOVUjHzGvo+WtTpU6lNyd0tF0sjzLwlOUZJaPqUPB48DtHexXN3ZC2
kuTbLc6i2XKLCQZUVQCFaRxjqQE5NZmp2nga3uX+zX91PEbdGAW4UbZPs80rg4Rs4ZIUAB+855xi
tc+NfD6313OkJnuRY2OnR3sumxDzn8/dc3JixtUiPCrxngU3SvG3h+61OGXWdPhSP7RqdxCyafHt
szI0YtsooXzAoVyQSTlge1JVcRzX9/Vdh8lO1tDG8d2ek3Uy3PhGNriwsbaOK+miTbHE67Y9x4/j
YFt5PzbgMDGTxleuw+PfD8d5cTrcJHA17bTXUUWigDUIoIj8mxywRnkdgWyDhc8dKqSeLPB9tpGj
aXbWr3Fub6zuLtprFTJBGpaS4VX6MWbagAH3SeT26sPjqlOPLKnJ+du5lUw8ZO6kkeaWVpcX1ytv
ZwyTTsCVRBkkAEnj2AJ/CkS2mezkuljY20bqjSY+UMc4GfU4P5V6BonjnSo7W3vdasEuNRi0y7j8
i2tkt1M1xMV2bowOEhLc+rnmq9x4k0CO8mmSJLo21xqF3aBtNjVDiFY7KHbtwFBZ2b3XnOa1eY1e
lJ/0yFho/wA6OBr0/wCBn/H7rf8A16D+ZrpdL8TeFLkDUri+03TY7IWsd1JPaWnmalHDAGljETMG
XfI2C0aHOABjHHMfAiWW4vNcnucedLa+Y4VQoBLE4AHQDOK58VjfrFCrTcGmkt/VGlKh7OpCV73P
p74T/wDJLPBv/YFsv/RCUUfCf/klng3/ALAtl/6ISivlj1hvjj/W2n+639K5euo8cf620/3W/pXn
vizUL3TdPt5NNW1a4lu4IMXDqoKu4DbcsoZ8E4XcMn16UAbVFecax8TLaHTCNLU3N6q2bedJAUgf
zjEeAX3Z2S7gOcdycVpaf8R9Jv2iWG3u0MiLL++aGILG3k4dt0gwD9ojwDyewPGQDtaK4i48WXze
HNC1KJbS2N/p8l9N56l1TbAJMDDDA56ntVV/ibYW32iO7s79biK5W1dFhXETsI8A5cFhmTrgHg8D
uAeg0V58fiTaxaHDdXVvMlzczzwQBY9yfJM0UbPhsqGIA+ue3NP17xhqVlcaFDax2edQFnvaSNm2
maVUbADDoDxQB31FZnhnUJNW0GxvpkRXnjD/ACfdb0Zf9kjkcngjk9a06ACiiigAooooAKKKKAMy
/wBGtr24M00cLOQBlogx/Oq3/CN2X/PG3/78LW5RVc8l1FZGH/wjdl/zxt/+/C0f8I3Zf88bf/vw
tblFHPLuHKuxh/8ACN2X/PG3/wC/C0f8I3Zf88bf/vwtblFHPLuHKuxh/wDCN2X/ADxt/wDvwtH/
AAjdl/zxt/8AvwtblFHPLuHKuxhN4ZsGxut7U46Zt14qxBpcGnwXLwJEpaMg7Iwvb2rVqK7/AOPW
b/cb+VLmfcLI6/4T/wDJLPBv/YFsv/RCUUfCf/klng3/ALAtl/6ISikMb44/1tp/ut/SvP8AxRfx
2Onxmey+2xzSiMxeU8ueC2diI7N93sp9eAK9A8cf620/3W/pXKsiOyMyqxQ7lJGdpwRkenBI/GgD
mLbXNLuEjbULKG3uzASYpNmUVZGCoS2MfNGcZwAQASCRkj1vQD5JjtYwGZbiM+Si9QD5gzyW+7wP
mPBAIINb0um2MzEzWVtISCCWiU5y249vUk/XmmJpGmoFCafZqF24AgUYwMDHHYdKAMe71awiuZrX
UdPijFtIBAsqbd5OTuRnVY+gySrnGQDhiBWfFqfhvXdTCnT1u7+1uH2Q7B/rRg7trbRu2bH3MPYE
suB1cmm2MrSNLZWztIcuWiUl/rxzTDpGmkuTp9mS/wB4+Qvzc5549aAMW4vLNrdLiPR7Z0QXM5Ey
hGUROqEgbT8xwDg46AHFR3niHR5pLq2ayW6e1M0LqY12hoU8wxjd32lD/d+brkEV0T6dZSLGr2ds
wiJZAYlOwk5JHHGTzVUaFYf2nJfPbxPK6smDEmAGxu6Lk5xzknqfWgCq3iK2SS7gto1c2lvLOVWR
cYTAAG3IGcnrgjHI5FTWGsmazluLuBYFjtUu/kkMn7tgxHYc/KeP1q7HptjG0rR2VsjSqUkKxKC4
PUHjkGmPpVp9intYIUtopxtk8hFTcO46dxx+PFAFJPEtg0UUuJhDMjyROV4kCKS+BnI24xyBk9Mj
mkuPE+nQ315ZeYxurUusiY6FYVl/La459QR2q9NpGmzBxNp9nIH+8GgU7uMc8c8VYmtbeZi00EUh
I2kugORgjH5Mw/4EfWgDNsdegvNQS2SGdBJEsiSOhUEkyDbg98RMfp1xkZSw8QW13YC7MU0UZt2u
BuAOQuN4GD1UnBzjPbI5rRhsrWDZ5NtBHs+7sjA2/e6Y6feb/vo+ppsWnWUQkEVnbIJF2OFiUblx
jB45GO1AGNN4y0mEEyPMv+kSWq5jwGkjaQOATxx5TkE43YIXLAgX9Q1u1sbv7NIHkuCqsscWGZt0
ixgYzkfM6cnAwc54OJE0TSkj8tNMsVjyW2i3QDJJJOMerE/ifWrD2Vq9z9oe2ga4wF80xgtgEEDP
XqoP1A9KAMrTvE1nqK3M1msklpGEEcwGPOcyPEVVTgjDoVy2B36c1DceKYoZr6IWdw8ttEJtgGDt
KK2WB+7gsAepHU8A1rxaXp8KSpDY2sazALIFhUBwM4B45xk9fU02TSNNkYNJp9mxAC5aBTwBgDp2
AAoALbUUuJrVYo28u4heZHY4+VSgBx7hwfUdxnpnP4psxazTrDcFIVVpCQAEDgGMnnOGyOmSO4Fa
smnWUpUyWds5Vi4LRKcMTknp1JHWqc/h7TZpIibWBYkO7ykhjCseOSduew6EZxg5FAFjR9Th1a0F
xbJKiHbgSrtbDKrg47ZVlODyM4IB4q9UcEEUC7YIkjXjhFAHAAHT2AH0AqSgAooooAKiu/8Aj1m/
3G/lUtRXf/HrN/uN/KgDr/hP/wAks8G/9gWy/wDRCUUfCf8A5JZ4N/7Atl/6ISigBvjj/W2n+639
K5euo8cf620/3W/pXL0AWdN00ahbre31/wD2XphZkjl3xrJM4OON4KhOG9z1GAPm0P7H0D/oaX/8
CLb/AOIrzz9oBQvwP8KKowBPaAD/ALdpK5b4ceCtKfwfoV7q+j6ZqN5rWotGgvdTNmY7ZflJQA5k
bcDwBn5hXo08HT+rrEVJNa2sl/wUc0q0vaezij2z+x9A/wChpf8A8CLb/wCIo/sfQP8AoaX/APAi
2/8AiK+Z9Q0fTdOtPGFxFDDb6autx6JZzajbyNLDlmLOoBB+VQeoJwPWruq/DDTrDVPDWn/8JZA9
1rswSCJrJ45EQqcSMjEMAWCqMgZ3cdK1jgsK3rVa+Xlch16q+z+J9F/2PoH/AENL/wDgRbf/ABFH
9j6B/wBDS/8A4EW3/wARXzp4U+GElzrWhxatcCP7dqslrHZtGQ89vBkzS5z8q/KVHuw9a0fiX4c0
KHwhFf6RodtZ3kutf2fatpl+9+ksJB+aUjKo2ACFBz+tKWEwqqKmqrd+y/4P5DVaq4uTjb5nvX9j
6B/0NL/+BFt/8RR/Y+gf9DS//gRbf/EV82+J/hj/AGPo1pf22qTzm41CPTlhutMms3aRwdpQScsO
PQVW8VeALDRdF1i9svE9rqdxpV9Hp9zbRW0iFZXYqF3HgsCDkDPQ81osBhHa1bfyJeIrL7H4n03/
AGPoH/Q0v/4EW3/xFKujaEzBV8TyFicAC4tiSf8Avivnf4weEbTw8XuHhTSbOzht9PtI0hLS6rc7
N80o5GEXcAW6ZU1574b/AORi0v8A6+ov/QxV4fK6OIg506j08v8Agk1MXOnLllH8T7a/4Qu3/wCg
pqX/AJB/+N0f8IXb/wDQU1L/AMg//G66qub8beKYvC0WkNNEkh1K/SwRpZhFHGzI77nbBwP3ZHTu
K8M7yH/hC7f/AKCmpf8AkH/43R/whdv/ANBTUv8AyD/8bqDQviBpWpaGdUuN9nAkImlR1Z3jXzJo
97BVIEZMDlXzyOoXjMus+O9HsdKW7tLq3u2edLdU83ywCbqO2dnYg7Qkkq7sjscA0AO/4Qu3/wCg
pqX/AJB/+N0f8IXb/wDQU1L/AMg//G6qaL8SNCvbRZL+5isJWvbiyQO+9JWil8oujgYMZYjDHHX2
qPVvih4bsVsZIb6G6hnv1sZZFfaLfcsx8xs9VzbyLkd1I7GgC/8A8IXb/wDQU1L/AMg//G6P+ELt
/wDoKal/5B/+N1c1jXbi11ex03T7AXd1d2dxeqJJvJG2FoVK8qfmJnXAOBwckVRg+IHh57C1vZdQ
hhgu4I7mBG3GUo8JmyUAyMRgseoABJxQA7/hC7f/AKCmpf8AkH/43R/whdv/ANBTUv8AyD/8bol8
d6JDq7WMtx8q2810biNWaKOOOOB28w4+VitzGQBkEEcgsFNjQ/GGl69q32PSJlu4vs7TmdDwpWTy
2Qg8hgR0NAFf/hC7f/oKal/5B/8AjdZWv+HJ9Hspr+0ubm9t4I3lnhlUNIFUZzEI0BY4DfKck8Yx
0LtN+IqX2lJqiaayactvY3M7NN+8jW6VWBC7cMED5bkHAOATgHvaAPKY3SWNZI2V0YBlZTkEHoQa
Zd/8es3+438q474PylvCUtsAFis7+6toQM8RrKxUc+mcD2Arsbv/AI9Zv9xv5UAdf8J/+SWeDf8A
sC2X/ohKKPhP/wAks8G/9gWy/wDRCUUAN8cf620/3W/pXL11Hjj/AFtp/ut/SuXoA5b9oL/kiPhX
/r4tP/SaSvHR8SNTFloVsdG8Nz/2JHssJrm0lkkiPykv/rgpYlVOdvUV9bWmjx614I0O2llaJVto
JMqM9Isf1qp/wgFr/wA/s3/fIr0qOOpwoqjUp81nfdr8jlnQk5ucZW+Vz5JtPHmqxLZi7tNJ1Ewa
jPq0hvLd2+0XcoI8xwrgYUHhQABVm38Uxa/8RNO1/wASR6dpRjuBdXV3p1tM0sxUqy5DyPnGwKAM
AZ74Ar6t/wCEAtf+f2b/AL5FH/CAWv8Az+zf98itFmGHTvGjZ/4n2t2sT9XqPRzv8j5eufixrknx
GvfFlrBZsVjks9OtruJiltbFuPlRlO84yTnufQYoab8RNX0ufSv7KsNC06y066N4llZ2bLFLL5Zj
DSFnZmwrHHzDHB7DH1h/wgFr/wA/s3/fIo/4QC1/5/Zv++RUQxmGiknRvb+8/wDIp0arbfP+B8mL
4+1JbnT5I9L0OKKz1V9ZEMcMxE10V2h5C0pZsdRyKzYfFOopYraSpZyxtrI1y4Z423TzjJCt83+r
yxOOvPWvsX/hALX/AJ/Zv++RR/wgFr/z+zf98irjj8NFWVD/AMmfl5eRLw9V71PwPj/XvGWta9p9
5aarJbXAutTbVDIyOWhdl2mOLL/LHtwNp3fdFZ/hv/kYtL/6+ov/AEMV9of8IBa/8/s3/fIp8HgS
2imjkF5MSjBsbR2Nb0s4p0YOFOlZev8AwCJYKU3zSnf5HY1j+I/D9rr4003Uk8Uun3a31tJCwBSV
UdAeQQRh24IrYorwjvOLt/hvodpbRw2LXtsFa3kJSbcXeGea4RmDAg/vp3fGMZ24AAApLf4e6ct7
rd5PJtudTu4LvNqnlLA0MiyqUViwDNKm9yAA56jPJ7WigDiv+Fb6KsNysUt9FJdvLJdSrIpadpJv
OYtlSB8/I2hfSqz/AAl8KS28EE9rcSwwzLOqNOfvLJcyA5HPDXkxyMEfLj7orvqKAMW98PR3V1YX
Yvr6G9s7WW0S4jZN7xyGMvu3KRkmFDkAEYOOtczr/wAL9KvbaAaPK2l3VvEILeZQ0ohiFs9vtVSw
/wCWb4ySTxxzzXoFFAHGj4daKVYyG5M0kRikkEmNwMVvGeMYH/Hpbt9U9CQbvhnwZpnh3Uby+snu
ZLq7eWSV5nBy0snmOcAADL5PtnHSulooA5Kz8A6TZ2aWUEl2LAQ2tu9sZFKypbqqxBjt3cBRnBGe
/WutoooA+cfg7/yLupf9ha8/9Gmu1u/+PWb/AHG/lXFfB3/kXdS/7C15/wCjTXa3f/HrN/uN/KgD
r/hP/wAks8G/9gWy/wDRCUUfCf8A5JZ4N/7Atl/6ISigBvjj/W2n+639K5euo8cf620/3W/pXL0A
d/4T/wCRV0b/AK8of/QBWrWV4T/5FXRv+vKH/wBAFatABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA
BRRRQAUUUUAFFFFABRRRQB84/B3/AJF3Uv8AsLXn/o012t3/AMes3+438q4r4O/8i7qX/YWvP/Rp
rtbv/j1m/wBxv5UAdf8ACf8A5JZ4N/7Atl/6ISij4T/8ks8G/wDYFsv/AEQlFADfHH+ttP8Adb+l
cvXUeOP9baf7rf0rl6AO/wDCf/Iq6N/15Q/+gCtWsrwn/wAiro3/AF5Q/wDoArVoAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPnH4O/8i7qX/YWvP8A0aa7W7/49Zv9xv5V
xXwd/wCRd1L/ALC15/6NNdrd/wDHrN/uN/KgDr/hP/ySzwb/ANgWy/8ARCUUfCf/AJJZ4N/7Atl/
6ISigBvjj/W2n+639K5euo8cf620/wB1v6Vy9AHf+E/+RV0b/ryh/wDQBWrWV4T/AORV0b/ryh/9
AFatABRRVDVxflbcaaUDNKqyl8YWMn5mGQckAHA9TzQBformk/4ST7H5cojF0be6HmIyFBKSphPI
BwAWXoenOeDWcsHjIeGbxZLnOpm+tmgaMQ+YLYNB9oXlfL3HFztyPusmSDnAB21Fcbd2njGa3dUv
4IJTPY7GtxGSIldBdZDoR8ymQrj0Xpzl2lQeLE1S4bUb1prQ38phjWCGIJbF/kBfLs+E/wBlWJOD
j7wAOwooooAKKKKACiiigAooooAKKKKACiiigAooooA+cfg7/wAi7qX/AGFrz/0aa7W7/wCPWb/c
b+VcV8Hf+Rd1L/sLXn/o012t3/x6zf7jfyoA6/4T/wDJLPBv/YFsv/RCUUfCf/klng3/ALAtl/6I
SigBvjj/AFtp/ut/SuXrqPHH+ttP91v6Vy9AHf8AhP8A5FXRv+vKH/0AVq1leE/+RV0b/ryh/wDQ
BWrQBxHxntvEl38PdSg8G3DW2qMufNiLiYKATti2DO9mCpkkABmbIxWtA2q6jqzz3kU2naVZhhHE
j7pL1mQZkO3lUXLBVOGLckLtGaXxR8SJ4a8I31zHfiz1NoJv7P3ICs9ysbOkPIIJYrgLwzcheawd
X8Xa7ZePRo0MKOv26ygt7ZkG+7tJEzcXWf8Apm2RxwNuCMuuACnd/wBvHwT4U8n+3v7Stdatmvce
f5jWyz7pPM7yL5eODnPQZORXR+KIPE2oaL4lnshLYzxafeW2l2kEwMs8xUiOd2HCnKjYoPAbLHcQ
sflU3xf1IeE9f1Cw1zT7i9sYbB4FlktyjyS3ksUoOzkKIkjbnDLkseCK9m+HOq3et+C9M1HUC/2q
4VmcSIqsPnYAELwCAAOPSgDnbFdYtk8KSXP9sEJrmovOCZpCbFvtYg80c5HzWuA/zDg8bWx6BeNc
pCTZxQyzZ+7LKY1x9QrfyrzVvHLQ32vWU+sRnUrOHUZ2hhMDxWsULN5TuM+bGQnl5Mg2FiccFa4b
Q/i7rN98JtZ8Q6rqumWGrW2tW9jDHFJC8ZifydwzzuO15nyDx5Z7KwoA+hLVp2gU3ccUUxzuSKQu
o54wxVSePYV5n4SPjq11/wAZrf24umutSj/s+SaeT7JawGIksoYAsF2hSqAF3P8AAp3jYvNSv/8A
hYmi6Za+IYfsN/YzXwh8qJmdYntlChupDiSZsj044U1jfB7xzL4t1XUreXVoL5beygmAjeBvnea4
Vz+75ACxwnDYI35PDLQB0kNtfWPjXQITc6nd2kekXMN1PJvMcs/mW5jdwP3Ychbg5AGM44BUGh4e
n8QL4c+wWdtfG9m1K+QXuoFsWds1xM0MhEh3y4iMYVBnnAYqAcd7RQB5dfWXii0+JmnPbPrFzoFv
CRcYuCVlhFrIoyNwUyGbZ0w2eeF5rqfh9DeR6TczX8l35lzceatrctM5tF8uNREHm+Zx8pYt0LO2
K6iigAooooAKKKKACiiigAooooA+cfg7/wAi7qX/AGFrz/0aa7W7/wCPWb/cb+VcV8Hf+Rd1L/sL
Xn/o012t3/x6zf7jfyoA6/4T/wDJLPBv/YFsv/RCUUfCf/klng3/ALAtl/6ISigBvjj/AFtp/ut/
SuXrqPHH+ttP91v6Vy9AHeeDZFl8JaMykZFpEjDPKsqgMp9CCCCOxBFbFeQ3F54g0mKabwlNp4uZ
Mb7XUEY28h3DL5TDK+3IyMg8Ag4BGe3j/wCJwYgeFPDzAHqL98H9KAPbqK8Q/wCFgfE7/oU/D/8A
4MG/wo/4WB8Tv+hT8P8A/gwb/CgD2+ivEP8AhYHxO/6FPw//AODBv8KP+FgfE7/oU/D/AP4MG/wo
A9vorxD/AIWB8Tv+hT8P/wDgwb/Cj/hYHxO/6FPw/wD+DBv8KAPb6K8Q/wCFgfE7/oU/D/8A4MG/
wo/4WB8Tv+hT8P8A/gwb/CgD2+ivEP8AhYHxO/6FPw//AODBv8KP+FgfE7/oU/D/AP4MG/woA9vo
rxD/AIWB8Tv+hT8P/wDgwb/Cj/hYHxO/6FPw/wD+DBv8KAPb6K8Q/wCFgfE7/oU/D/8A4MG/wo/4
WB8Tv+hT8P8A/gwb/CgD2+ivEP8AhYHxO/6FPw//AODBv8KP+FgfE7/oU/D/AP4MG/woA9vorxD/
AIWB8Tv+hT8P/wDgwb/Cj/hYHxO/6FPw/wD+DBv8KAPb6juJ4ra3lnuZUhgiUvJJIwVUUDJJJ4AA
714p/wALA+J3/Qp+H/8AwYN/hWPrknxC8ewy6Z4nudM0Dw5KNtxbaWWkubpflOxpGyFU4blcHGVI
IOaAKfwQkN14H+37Nkd9fXVzGpOSFMrDB98g13V3/wAes3+438qLW3itLWG2t0EcEKCONB0VQMAf
lRd/8es3+438qAOv+E//ACSzwb/2BbL/ANEJRR8J/wDklng3/sC2X/ohKKAIvHiu0tn5cqxHDctF
vz0/2lrlfKn/AOfyL/wEP/x2ut8cf620/wB1v6Vy9AEXlT/8/kX/AICH/wCO0eVP/wA/kX/gIf8A
47XneseKZPE3ir/hF/Dd0VWL57y5jzgICyugYA45AH8JyRg85HolrClpaQwIT5cSLGpOM4AwKBh5
U/8Az+Rf+Ah/+O0eVP8A8/kX/gIf/jtS5GcZ5o69KBEXlT/8/kX/AICH/wCO0eVP/wA/kX/gIf8A
47UtFAEXlT/8/kX/AICH/wCO0eVP/wA/kX/gIf8A47UtWnht4yokml3FVY7YgQMgH+970AUPKn/5
/Iv/AAEP/wAdo8qf/n8i/wDAQ/8Ax2rDzaclxHA94yzyAlIyihmx1wN+TUuy1/57T/8Afkf/ABVA
FLyp/wDn8i/8BD/8do8qf/n8i/8AAQ//AB2riizZQyzzFSMgiIYP/j1ZvijUrbQ/Dmp6qvnXDWVt
JOIigTeVUnbuycZx1wfpQBN5U/8Az+Rf+Ah/+O0eVP8A8/kX/gIf/jtRzSXMM80LraGSE7XCvK2D
xxkRc9RUSXkz7gq2+VGSCZweuOhhoAs+VP8A8/kX/gIf/jtHlT/8/kX/AICH/wCO1VF7JxkWykkq
oYzqWI7AGHnoTx2BPSnJdTurERwYHXPnjvjvDzQBY8qf/n8i/wDAQ/8Ax2jyp/8An8i/8BD/APHa
zLTWjP4gfS2hQFbX7T5iO3HzldpVkUjpnPoRXQRRRGDzJZHUFtoCoG7fUUAUvKn/AOfyL/wEP/x2
jyp/+fyL/wABD/8AHas3ElhbQtLcXbxRL1d41UDt1LVJstf+e0//AH5H/wAVQBS8qf8A5/Iv/AQ/
/HaPKn/5/Iv/AAEP/wAdq4ws1Us08wUDJJiGB/49SS/ZY4nfzZztUnHlD/4qgCp5U/8Az+Rf+Ah/
+O1FdRTC2lLXcbDYcgWpGePXzDj8qdp1z9s0+2udmzzolk25ztyAcZ/Gn3f/AB6zf7jfyoA6/wCE
/wDySzwb/wBgWy/9EJRR8J/+SWeDf+wLZf8AohKKAIfH4kKwCBlWUxuEZhkA8YJFfMniz4uajaeG
tQ0WW3Nn4yhnFm/lLuRgc5lj+oAwP9oEZr6f8cf620/3W/pXleseBNK1XxtpniW5UG6slI8vYCsr
DOxm91JyPoPSgDhvhHHcaDprQadoEt3Ot2bG9uzKoZnVjuYHoEVmYY5JHPsdnXfEU+oeCrDWdU0S
ymsJbi3ZIftj70l84KG4QAgHBxkdOeuK7SDw3ptve3N1bRzQPcy+fMkU7ojy/wB8qDjd6nv1PIqK
Xwlo0uhQ6NJbSnTYZFkji+0y8Mp3D5t27g84zigDnb6MaXqclxrdms9tPfrNb6jbsC8Z3gpHJnna
MAccfjitCx137NpX+iWUMEVvbSXLRvKdpVZGXarY65Gcn1HHNbp0SxZVR45HhD+YInlZk3ZznBPr
z6Z5rC1Tw6gvI1tm1G2toYSYWtJN7GQsSwbfnHYjp1OT0pHoKrSqpRn/AMD7rl9tY1Dz3gFpbJKt
oLvLTMRjJG37oweKueGxM+mLcz3ctyLs/aYxIqgxI4BEYwOQPWm2OlK1vFNqO+TUXtVguJFlYBuO
QADgc56YrRs7aKztYra3UrDEoRFLFsAcAZPNM5ajha0VqS0uuRSzRPHbymGZoI9jjsdi/p+vpg80
lZs+g6PPM8s+lWEsrnczvbIzMfUkjmgxMrXdKuL65kQQ3DRvBBsKSpsWaN2dGckh8K2xvl64OQel
Pj0nWEnmKao6JJcAnfJ5oEG5iVVdo2tt2rnc2OT163/+Eb0P/oDab/4Cp/hR/wAI3of/AEBtN/8A
AVP8KAMqz03xFBHL5l5BLI8DRZa4fAck4kHycYG0bRweT1qHxvFcQ/C3xBHeuHnWwuMsHLZG1sck
DJxjsPpW3/wjeh/9AbTf/AVP8KR/DOgujK+iaYysMEG0jII/KgCXVNYsLLXNRjkFwHkumO6O2kkV
jtHO5VIHC45PUY9BWFcar5vjGxs47a6az1CWytnuU8yPb+9LMCQOMq+3ORycdeKvf8IV4V/6FnRP
/ACL/wCJpU8GeGY5I5IfD+lQzRusiSw2iRujKQQQygEEEDoaAMfxlbalo3i3TLGPxCk9t53nSNAz
vK9tswqPGgbYwyG3narlsjHCDbttctbW1s4byW4luTGiu8drM4LbMkkhOO/XHPHXiq58G6HLd7rv
RtLubdIxFAk1qknlICSEQEfKoLOeOPmAAUL80n/CFeFf+hZ0T/wAi/8AiaAM7TJYZviVeywKwV9N
jYkqV3HcOcEDtgfh+A7k/wDHgv8A11P8hWLpWg6PpEkkmk6VYWLyDa7W1ukRYehKgZqe+0yw1Aob
+ytbopkKZolfbn0yOKAKmu2Fxd3OkXNp5RewuzcFJGKhwYJYsZAOP9bnp2rFsLDxDLqF+8z/AGG1
ERW1hSUeWHBIjwoBKqFCbhnkg8AErW3/AMI3of8A0BtN/wDAVP8ACj/hG9D/AOgNpv8A4Cp/hQBj
z6JrNxbeVLeEZgaMgXbFWdlIZmBjOQf7vG3nB546i7/49Zv9xv5Vn/8ACN6H/wBAbTf/AAFT/Cj/
AIRvQ/8AoDab/wCAqf4UAS+Hv+QBpn/XrF/6AKt3f/HrN/uN/KnxokUaxxqqIoCqqjAAHQAUy7/4
9Zv9xv5UAdf8J/8Aklng3/sC2X/ohKKPhP8A8ks8G/8AYFsv/RCUUAR+M/Duu63fQSaTrlhp1tHH
tMU+mtcsz5OW3CZMDG0Yx2PPOBz3/CBeLf8AobtI/wDBE/8A8k16fRQB5h/wgXi3/obtI/8ABE//
AMk0f8IF4t/6G7SP/BE//wAk16fRQB5h/wAIF4t/6G7SP/BE/wD8k0f8IF4t/wChu0j/AMET/wDy
TXp9FAHmH/CBeLf+hu0j/wAET/8AyTR/wgXi3/obtI/8ET//ACTXp9FAHmH/AAgXi3/obtI/8ET/
APyTR/wgXi3/AKG7SP8AwRP/APJNen0UAeYf8IF4t/6G7SP/AARP/wDJNH/CBeLf+hu0j/wRP/8A
JNen0UAeYf8ACBeLf+hu0j/wRP8A/JNH/CBeLf8AobtI/wDBE/8A8k16fRQB5h/wgXi3/obtI/8A
BE//AMk0f8IF4t/6G7SP/BE//wAk16fRQB5h/wAIF4t/6G7SP/BE/wD8k0f8IF4t/wChu0j/AMET
/wDyTXp9FAHmH/CBeLf+hu0j/wAET/8AyTR/wgXi3/obtI/8ET//ACTXp9FAHmH/AAgXi3/obtI/
8ET/APyTR/wgXi3/AKG7SP8AwRP/APJNen0UAeYf8IF4t/6G7SP/AARP/wDJNH/CBeLf+hu0j/wR
P/8AJNen0UAeYf8ACBeLf+hu0j/wRP8A/JNNf4f+LHRkbxdpGGGD/wASJ/8A5Jr1GigDK8J6R/wj
/hXRtG8/7R/Z1lDZ+ds2eZ5aBN23JxnGcZOPWitWigD/2Q==

------_=_NextPart_001_01C9D28A.EE34CB05--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4BDxjdu064479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 May 2009 06:59:45 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4BDxjp4064478; Mon, 11 May 2009 06:59:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from outbound-mail-305.bluehost.com (outbound-mail-305.bluehost.com [67.222.53.251]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n4BDxWOm064455 for ; Mon, 11 May 2009 06:59:43 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 24807 invoked by uid 0); 11 May 2009 13:59:30 -0000
Received: from unknown (HELO box251.bluehost.com) (69.89.31.51) by outboundproxy6.bluehost.com with SMTP; 11 May 2009 13:59:30 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=hardjono.net; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=be9/4qGnMHL6aowJMP9S82cDO8GQvJX/9xv8dsrCXDXpVisPz8CfxD3oLs2yEH1U7z04jJw/8wZjCJN/eQ+bKvoozIFxWC11k08KIrAMPv+qAtQVYJwTE1hvIAFXuX+5;
Received: from dhcp-18-111-56-67.dyn.mit.edu ([18.111.56.67] helo=thomasvnf1ekrv) by box251.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1M3W2T-0000mu-Rb; Mon, 11 May 2009 07:59:30 -0600
From: "Thomas Hardjono"
To: "'Stefan Santesson'" , "'Santoni Adriano'"
Cc: , , ,
References:
In-Reply-To:
Subject: RE: draft-santesson-pkix-certimage-00.txt: any example to date?
Date: Mon, 11 May 2009 09:59:21 -0400
Message-ID: <001501c9d240$b450e4b0$1cf2ae10$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcnO/QfRDn7rlWhvrkSFDq6yPhwBpgACu5sAAAC/yKcAzRpZcA==
Content-Language: en-us
X-Identified-User: {727:box251.bluehost.com:hardjono:hardjono.net} {sentby:smtp auth 18.111.56.67 authed with ietf+hardjono.net}
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stefan, PKIX-folks,

I'd like to voice my support for this draft. Having worked for a large =
CA
for over 5 years and seeing such a low adoption rate for client-side =
certs,
I think anything to help the cause of cert adoption is worth pursuing. =
If
RFC3709/logotypes has had thin adoption, then perhaps its time to try =
this
approach.

/thomas/

> -----Original Message-----
> From: [email-masked] =
[mailto:[email-masked]]
> On Behalf Of Stefan Santesson
> Sent: Thursday, May 07, 2009 7:57 AM
> To: Santoni Adriano
> Cc: [email-masked]
> Subject: Re: draft-santesson-pkix-certimage-00.txt: any example to =
date?
>=20
>=20
> The draft was published a few weeks ago so I don't know of any real
> world
> implementations.
>=20
> The certificate image may contain any mix of text and graphics.
> It may for example look very similar to the ID in your wallet.
>=20
> /Stefan
>=20
>=20
> On 09-05-07 1:37 PM, "Santoni Adriano"
> wrote:
>=20
> >
> > Stefan,
> >
> > are you aware, to date, of any real world "certificate image" to =
look
> at as a
> > good example of how a cert image should look?
> >
> > Adriano
> >
> >
> > -----Messaggio originale-----
> > Da: [email-masked] =
[mailto:[email-masked]]
> Per
> > conto di Stefan Santesson
> > Inviato: gioved=EC 7 maggio 2009 12.18
> > A: Roberto Opazo
> > Cc: Paul Hoffman; Russ Housley; [email-masked]
> > Oggetto: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
> >
> >
> >
> > Roberto,
> >
> > I agree with what you say but would like to add one thing regarding
> > application support.
> >
> > It used to be that the browsers were the critical application for
> showing
> > logotypes or a certificate image. However that has changed slightly.
> >
> > EU member states continue to invest considerable resources to =
provide
> services
> > in electronic form, supported by national endorsed ID certificates,
> supported
> > by EU commission activities. The services directive, the action plan
> for
> > harmonizing e-signatuires and e-identification, the STORK project, =
the
> PEPPOL
> > project are some significant examples.
> >
> > It is very common for these national infrastructures to provide a
> small client
> > software which provides the UI for authentication and signing.
> >
> > This makes it possible to use a certificate image to support these
> services
> > regardless of browser support.
> >
> > I have also talked to several providers of services and CAs in
> addition to
> > representatives from the EU commission and EU projects who are
> seriously
> > interested in using this feature regardless of the browsers.
> >
> > I wouldn't be surprised to see browsers follow once they see the =
value
> in
> > local UI deployments.
> >
> > /Stefan
> >
> >
> >
> >
> > On 09-05-06 5:59 PM, "Roberto Opazo" wrote:
> >
> >>
> >> Stefan
> >>
> >> I also suport the idea of specifying a method to bind a visual
> >> representation of a certificate in the form of a certificate image
> to
> >> a [RFC5280] public key certificate by defining a new otherLogos =
image
> >> type according to [RFC3709].
> >>
> >> I see two points here:
> >>
> >> * RFC 3709 is already done, so we should choose between completing =
it
> >> with support for a whole certificate image or revoking it. It=B9s =
easer
> >> and consistent to complete the job.
> >>
> >> * As a certificate provider, I think it=B9s very obvious the reason =
why
> >> RFC 3709 has not been adopted, but that=B9s not the point jet. The
> >> standard needs some browser support before any CA start using it.
> >>
> >> Best regards,
> >>
> >> Roberto Opazo
> >>
> >> 2009/5/5 Anders Rundgren :
> >>>
> >>> The *motive* is definitely good and worth pursuing.
> >>>
> >>> What's less suitable is the idea of *publishing* an end-user's
> >>> credential selection images. =A0I would like to see some samples
> >>> applied to eID or VISA certificates.
> >>>
> >>> Anders
> >>>
> >>> ----- Original Message -----
> >>> From: "Russ Housley"
> >>> To: "Paul Hoffman"
> >>> Cc:
> >>> Sent: Tuesday, May 05, 2009 15:03
> >>> Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
> >>>
> >>>
> >>>
> >>> Paul:
> >>>
> >>> We clearly disagree. =A0I still believe that logotypes are needed =
to
> >>> make useful user interfaces. =A0We have not seen logotypes take =
off in
> >>> the marketplece, and I am hoping that the use of a single image
> >>> instead of multiple images will remove an impediment.
> >>>
> >>> Russ
> >>>
> >>> At 07:01 PM 4/30/2009, Paul Hoffman wrote:
> >>>
> >>>> At 12:31 AM +0200 5/1/09, Stefan Santesson wrote:
> >>>>> On 09-04-30 7:42 PM, "Paul Hoffman" =
wrote:
> >>>>>> - Note that only one person has supported the idea, even
> >>>> obliquely, since the
> >>>>>> request was posted.
> >>>>>>
> >>>>>
> >>>>> First of all that is a premature assessment. Very little time =
has
> >>>>> passed so far.
> >>>>
> >>>> That is for the co-chairs to decide. Hopefully, you have recused
> >>>> yourself from this decision.
> >>>>
> >>>>> Secondly you are wrong. This draft is supported also by the
> >>>>> editors. That makes it five. Only one person so far has voiced
> against.
> >>>>
> >>>> There is a reasonable assumption in the IETF that all the co-
> authors
> >>>> on a draft support it. The question for WG adoption is whether
> >>>> *others* support the inclusion in the WG.
> >>>>
> >>>>>> - Given the extremely thin adoption of RFC 3709, it is
> >>>> inappropriate for the
> >>>>>> WG to take on a major extension to that RFC.
> >>>>>>
> >>>>>
> >>>>> Thin adoption of RFC 3709 is not a problem at all.
> >>>>
> >>>> We disagree, strongly.
> >>>>
> >>>>> One of the problems with
> >>>>> just providing logotypes with 3709 is that the solution is
> >>>>> incomplete. The certificate image offers a complete solution.
> >>>>
> >>>> Which implementers have said "oh, if you only included =
Postscript,
> >>>> then we would have done 3709"?
> >>>>
> >>>>> The problem is important and need a solution. Building on RFC =
3709
> >>>>> offers an easy solution.
> >>>>
> >>>> We disagree, strongly.
> >>>>
> >>>>>> As an individual submission:
> >>>>>>
> >>>>>> - This proposes that compliant PKIX validators need to include
> >>>> at least one
> >>>>>> complex image-display mechanism. =A0These mechanisms have been
> >>>> error-prone in
> >>>>>> the past, sometimes leading to the execution of arbitrary code =
on
> >>>>>> the host system. Forcing, or even suggesting, this be deployed =
as
> >>>>>> part of
> >>>> PKIX seems
> >>>>>> needlessly dangerous for very little value.
> >>>>>>
> >>>>>
> >>>>> I don't understand the problem.
> >>>>
> >>>> Clearly.
> >>>>
> >>>>> We are talking about having the option to display a signed image
> >>>>> from a trusted source. As if that would be a lot more dangerous
> >>>>> than displaying images in your browser from untrusted sources.
> >>>>
> >>>> To date, the CAs in the root pile have been trusted to issue
> >>>> certificates that reflect a proper binding between an end entity
> and
> >>>> a public key. There was some risk of them creating certificates
> with
> >>>> malicious formatting, but that was considered easy to detect. You
> >>>> are now proposing that those hundred of CAs be automatically
> trusted
> >>>> to format the art portions of their certificates correctly. That =
is
> >>>> a very different level of trust.
> >>>>
> >>>> Even if a CA formats the certificate in a way they think is
> correct,
> >>>> there is a chance that the named party will have given them
> >>>> information that will cause the display mechanism to crash and
> >>>> possibly execute arbitrary code. That isn't possible today with =
any
> >>>> sensible ASN.1 parser.
> >>>>
> >>>>>> - The rationale from the introduction of the document for
> >>>> showing pictures
> >>>>>> instead of words is wrong. If you want to fix the words the =
user
> >>>> sees, fix the
> >>>>>> words, don't pretend that a picture it is sorta-kinda based on
> the
> >>>>>> current words but not really will lead to better security.
> >>>>>>
> >>>>>
> >>>>> I don't have to pretend. We have at least 3 image formats that =
is
> >>>>> very well suited to display a mix of text and graphics. The
> feature
> >>>>> achieved is usability more than security. To the extent security
> >>>>> can benefit from a more user friendly UI, this is also providing
> >>>>> better security.
> >>>>
> >>>> This does not explain why you don't try to just fix the problems
> >>>> that you claim are the base for this extension. No one *needs*
> >>>> pictures; they need accurate information about the identified
> party.
> >>>> That can be done in text, yes?
> >>>>
> >>>>>> - "The previous RFC failed so now we want to extend it to make =
it
> >>>>>> more complicated" just sounds silly for a standard. The fact =
that
> >>>>>> it
> >>>> has been done
> >>>>>> in the IETF before doesn't mean we should make the same mistake
> again.
> >>>>>>
> >>>>>
> >>>>> Not at all. It is the total opposite. Just adding logotypes =
didn't
> >>>>> make the task to provide a understandable UI easy enough. So we
> >>>>> need to make the solution easier and complete.
> >>>>>
> >>>>> A UI just using RFC 3709 would have to:
> >>>>> - Decide where to place the logotypes on the screen relative to
> the
> >>>>> text
> >>>>> - Decide how to scale the images relative to each other and to =
the
> >>>>> text
> >>>>> - Come up with display text describing the content of each
> >>>>> attribute
> >>>>> - Decide which naming attributes and other names to display
> >>>>> - Figure out how to serve the users language preferences with
> >>>>> respect to display text.
> >>>>>
> >>>>> A UI using the certificate image in this new draft, can instead =
do
> >>>>> the following
> >>>>> - Display the certificate Image
> >>>>>
> >>>>> I would call that easier, not more complicated.
> >>>>
> >>>> You come from the assumption that logotypes are actually useful,
> not
> >>>> just (to use your terms) "user friendly" and based on "usability
> >>>> more than security".
> >>>>
> >>>>> I would understand your violent disagreement more Paul, if you
> >>>>> could offer an alternative solution.
> >>>>
> >>>> I already did that in the last message, but let me try again. If
> the
> >>>> problem is that the names in certificates are not right, fix =
them.
> >>>> Specify "display text describing the content of each attribute",
> >>>> "decide which naming attributes and other names to display", and
> >>>> "figure out how to serve the users language preferences with
> respect
> >>>> to display text". None of that takes graphics, much less more
> >>>> complicated graphics than has already failed.
> >>>>
> >>>> --Paul Hoffman, Director
> >>>> --VPN Consortium
> >>>
> >>>
> >>
> >
> >

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4ALPOpK010251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 May 2009 14:25:24 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4ALPO4c010250; Sun, 10 May 2009 14:25:24 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4ALPB4l010229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 10 May 2009 14:25:23 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 2853 invoked from network); 10 May 2009 21:25:18 -0000
Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 May 2009 21:25:18 -0000
Received: (qmail 36203 invoked from network); 10 May 2009 21:25:09 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 May 2009 21:25:09 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Sun, 10 May 2009 23:25:09 +0200
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
From: Stefan Santesson
To: Paul Hoffman ,
Message-ID:
Thread-Topic: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Thread-Index: AcnRtct8R1WQq5OI8EGAs/LLBb4xaA==
In-Reply-To:
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul,

I can live with your text.

/Stefan

On 09-05-10 9:28 PM, "Paul Hoffman" wrote:

>
> At 7:25 PM +0200 5/10/09, Stefan Santesson wrote:
>> I think it is OK to make it shorter, maybe even down to your suggestion.
>> I just thought some information you left out could be relevant. For example:
>>
>> FIPS 186-3 fully specifies the DSA digital
>> signature algorithm and defines security
>> requirements for the DSA and ECDSA digital
>> signature algorithms; details can be found in
>> [FIPS 186-3]. ECDSA is fully specified in [X9.62].
>
> These are not security considerations
>
>> [FIPS 186-3] also specifies three types of
>> elliptic curves for use in conjunction with one of
>> the described hash functions: curves over prime
>> fields, curves over binary fields, and Koblitz
>> curves (anomalous binary curves).
>
> Nor are these.
>
>> FIPS 186-3
>> provides a table listing the uses and time periods
>> for each algorithm and key size combinations for
>> various applications.
>
> That is a security consideration, but not a useful one, because FIPS 186-3
> just points to SP 800-57, which I already put in there.
>
>> Your security considerations section does not mention FIPS 183-3 or X9.62 at
>> all.
>
> Correct. If you see some security considerations in either of those two
> documentst that aren't in SP 800-57, I'm fine with mentioning them in the
> Security Considerations section; I didn't see them.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4AJSg2E003202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 May 2009 12:28:43 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4AJSglI003201; Sun, 10 May 2009 12:28:42 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4AJSZpf003195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 May 2009 12:28:37 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Sun, 10 May 2009 12:28:34 -0700
To: Stefan Santesson ,
From: Paul Hoffman
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 7:25 PM +0200 5/10/09, Stefan Santesson wrote:
>I think it is OK to make it shorter, maybe even down to your suggestion.
>I just thought some information you left out could be relevant. For example:
>
> FIPS 186-3 fully specifies the DSA digital
> signature algorithm and defines security
> requirements for the DSA and ECDSA digital
> signature algorithms; details can be found in
> [FIPS 186-3]. ECDSA is fully specified in [X9.62].

These are not security considerations

> [FIPS 186-3] also specifies three types of
> elliptic curves for use in conjunction with one of
> the described hash functions: curves over prime
> fields, curves over binary fields, and Koblitz
> curves (anomalous binary curves).

Nor are these.

> FIPS 186-3
> provides a table listing the uses and time periods
> for each algorithm and key size combinations for
> various applications.

That is a security consideration, but not a useful one, because FIPS 186-3 just points to SP 800-57, which I already put in there.

>Your security considerations section does not mention FIPS 183-3 or X9.62 at
>all.

Correct. If you see some security considerations in either of those two documentst that aren't in SP 800-57, I'm fine with mentioning them in the Security Considerations section; I didn't see them.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4AHQ4K3096110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 May 2009 10:26:04 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4AHQ4fN096109; Sun, 10 May 2009 10:26:04 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4AHPpkp096085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 10 May 2009 10:26:02 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 98331 invoked from network); 10 May 2009 17:25:57 -0000
Received: from s34.loopia.se (HELO s60.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 May 2009 17:25:57 -0000
Received: (qmail 81203 invoked from network); 10 May 2009 17:25:50 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 May 2009 17:25:50 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Sun, 10 May 2009 19:25:49 +0200
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
From: Stefan Santesson
To: Paul Hoffman ,
Message-ID:
Thread-Topic: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Thread-Index: AcnRlFxC8Av0l5BrWE6isnlqdyvULg==
In-Reply-To:
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On 09-05-10 6:19 PM, "Paul Hoffman" wrote:

> At 10:49 AM +0200 5/10/09, Stefan Santesson wrote:
>> For the most part I think your change proposals are fine.
>
> Thanks.
>
>> Some informational notes could be worth keeping such as "[X9.62] has defined
>> additional OIDs for the ECDSA signature algorithm.".
>
> I thought about that one, but it seems like a throw-away. Lots of people have
> defined "additional OIDS". We don't want to say "...and they MUST / SHOULD not
> be used by conforming systems" because relying parties might want to be able
> to handle those OIDs. So, I'm not sure of the value of saying that the other
> spec defined them.
>

I just thought these ones were of particular relevance as x9.62 is a
normative ref.

And we might want to say MUST/SHOULD NOT be used.

But I also see your point. Unless we want to say MUST/SHOULD NOT be used,
then we probably should not mention them.

>> It may also be useful
>> to keep some more text in the security considerations section, explaining
>> the guidance provided by the NIST publications.
>
> No, absolutely not. Let the NIST documents explanations stand on their own. It
> is not the place of the IETF to try to explain other people's logic,
> particularly when the other people are not clear in their own documents. This
> is not a criticism of the documents; I say this as someone who has read and
> re-read SP 800-57 probably more than almost anyone other than its authors.
>
> Think of it this way: if some association using PKIX required OCSP, and their
> specification document said "the reason that the IETF made the response codes
> in OCSP they way they are is...", many of us would first laugh out loud, then
> probably disagree with what they wrote.
>
> --Paul Hoffman, Director
> --VPN Consortium

I think it is OK to make it shorter, maybe even down to your suggestion.
I just thought some information you left out could be relevant. For example:

FIPS 186-3 fully specifies the DSA digital
signature algorithm and defines security
requirements for the DSA and ECDSA digital
signature algorithms; details can be found in
[FIPS 186-3]. ECDSA is fully specified in [X9.62].
[FIPS 186-3] also specifies three types of
elliptic curves for use in conjunction with one of
the described hash functions: curves over prime
fields, curves over binary fields, and Koblitz
curves (anomalous binary curves). FIPS 186-3
provides a table listing the uses and time periods
for each algorithm and key size combinations for
various applications.

Your security considerations section does not mention FIPS 183-3 or X9.62 at
all.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4AGM2km091949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 May 2009 09:22:02 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4AGM20l091948; Sun, 10 May 2009 09:22:02 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4AGLuAC091922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 May 2009 09:21:57 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Sun, 10 May 2009 09:19:58 -0700
To: Stefan Santesson ,
From: Paul Hoffman
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 10:49 AM +0200 5/10/09, Stefan Santesson wrote:
>For the most part I think your change proposals are fine.

Thanks.

>Some informational notes could be worth keeping such as "[X9.62] has defined
>additional OIDs for the ECDSA signature algorithm.".

I thought about that one, but it seems like a throw-away. Lots of people have defined "additional OIDS". We don't want to say "...and they MUST / SHOULD not be used by conforming systems" because relying parties might want to be able to handle those OIDs. So, I'm not sure of the value of saying that the other spec defined them.

> It may also be useful
>to keep some more text in the security considerations section, explaining
>the guidance provided by the NIST publications.

No, absolutely not. Let the NIST documents explanations stand on their own. It is not the place of the IETF to try to explain other people's logic, particularly when the other people are not clear in their own documents. This is not a criticism of the documents; I say this as someone who has read and re-read SP 800-57 probably more than almost anyone other than its authors.

Think of it this way: if some association using PKIX required OCSP, and their specification document said "the reason that the IETF made the response codes in OCSP they way they are is...", many of us would first laugh out loud, then probably disagree with what they wrote.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4A8nVRV065651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 May 2009 01:49:31 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4A8nVnL065650; Sun, 10 May 2009 01:49:31 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4A8nHsW065622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 10 May 2009 01:49:29 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 72761 invoked from network); 10 May 2009 08:49:18 -0000
Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 May 2009 08:49:18 -0000
Received: (qmail 86596 invoked from network); 10 May 2009 08:49:15 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 May 2009 08:49:15 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Sun, 10 May 2009 10:49:14 +0200
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
From: Stefan Santesson
To: Paul Hoffman ,
Message-ID:
Thread-Topic: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Thread-Index: AcnRTDHMFcJWEN+mKUegZl+yHqCzSQ==
In-Reply-To:
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Thanks Paul for your extensive review.

I agree in principle with your three points here. I personally like keeping
standards as short and clear as possible.

For the most part I think your change proposals are fine.

Some informational notes could be worth keeping such as "[X9.62] has defined
additional OIDs for the ECDSA signature algorithm.". It may also be useful
to keep some more text in the security considerations section, explaining
the guidance provided by the NIST publications.

/Stefan

On 09-05-09 6:50 PM, "Paul Hoffman" wrote:

>
> Greetings again. This document is *not* ready for advancement. It has many
> fundamental flaws that prevent it from being an understandable standard.
>
> 1) Update status is unclear
>
> As Russ pointed out, much of the information from the RFC 3279 is repeated
> here. Unlike Russ, I do not consider this to be "minor". This document is
> intended to be on standards track and presumably is an update to RFC 3279
> (even though the header on the first page does not say so). Thus, the
> repetition is quite bad when it is not exact or, worse, when it is incomplete.
>
> The only way to clear up the update status is to keep the status as updating
> RFC 3279 and strip the document of everything except the updates to RFC 3279,
> plus some pointers to recommendations of appropriate use. The good news is
> that this will turn the document into about two pages, mostly OIDs.
>
> 2) Mandating key sizes and lifetimes is inappropriate in this document
>
> RFC 3279 does not mandate key sizes; this draft does. Worse, this draft relies
> on the tortured logic in NIST SP 800-57 Part 1 that conflates multiple
> effective key strengths onto a single hash algorithm. The logic that NIST used
> in making that decision had to do with the difficulty of upgrading a disparate
> US government infrastructure over a long period of time. That's fine for NIST,
> but an IETF standard should not make such compromises. It is just wrong to
> update an existing algorithm RFC by adding a new set of restrictions, but only
> for some of the algorithms, namely the new ones being added.
>
> The key strength matching and lifetime mandates should be ripped out. It is
> fine to have a non-normative reference to NIST SP 800-57 Part 1 and NIST SP
> 800-78-1 in the Security Considerations to help people find the documents.
>
> 3) Adding new validation requirements at this late date is wrong
>
> RFC 3279 specified DSA only with SHA-1; this document adds DSA with SHA-2.
> However, this document now makes all implementations of RFC 3279 that could
> validate DSA non-conformant. It is wrong to add new algorithms and then punish
> existing implementations by labelling them non-conformant to a
> long-established standard.
>
> Following the three guidelines above, the meat of the document is reduced to
> that below.
>
> --Paul Hoffman
>
> Abstract
>
> This document updates RFC 3279 to specify algorithm identifiers
> and ASN.1 encoding rules for the Digital Signature Algorithm (DSA)
> and Elliptic Curve Digital Signature Algorithm (ECDSA) digital
> signatures when using SHA-224, SHA-256, SHA-384 or SHA-512 as
> hashing algorithm. This specification applies to the Internet
> X.509 Public Key Infrastructure (PKI) when digital signatures are
> used to sign certificates and certificate revocation lists (CRLs).
>
> 1. Introduction
>
> This specification defines the contents of the signatureAlgorithm,
> signatureValue and signature fields within Internet X.509
> certificates and CRLs when these objects are signed using DSA or
> ECDSA with a SHA2 hash algorithm. These fields are more fully
> described in [RFC 5280].
>
> This document profiles material presented in the "Secure Hash
> Standard" [FIPS 180-3], "Public Key Cryptography for the Financial
> Services Industry: The Elliptic Curve Digital Signature Standard
> (ECDSA)" [X9.62], and the "Digital Signature Standard" [FIPS
> 186-3].
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
> in this document are to be interpreted as described in [RFC 2119].
>
> 2. One-way Hash Functions
>
> This section identifies four additional hash algorithms for use
> with DSA and ECDSA in the Internet X.509 certificate and CRL
> profile [RFC 5280]. SHA-224, SHA-256, SHA-384, and SHA-512
> produce a 224-bit, 256-bit, 384-bit and 512-bit "hash" of the
> input respectively and are fully described in the Federal
> Information Processing Standard 180-3 [FIPS 180-3].
>
> The listed one-way hash functions are identified by the following
> object identifiers (OIDs):
>
> id-sha224 OBJECT IDENTIFIER ::= { joint- iso-itu-t(2)
> country(16) us(840) organization(1) gov(101) csor(3)
> nistalgorithm(4) hashalgs(2) 4 }
>
> id-sha256 OBJECT IDENTIFIER ::= { joint- iso-itu-t(2)
> country(16) us(840) organization(1) gov(101) csor(3)
> nistalgorithm(4) hashalgs(2) 1 }
>
> id-sha384 OBJECT IDENTIFIER ::= { joint- iso-itu-t(2)
> country(16) us(840) organization(1) gov(101) csor(3)
> nistalgorithm(4) hashalgs(2) 2 }
>
> id-sha512 OBJECT IDENTIFIER ::= { joint- iso-itu-t(2)
> country(16) us(840) organization(1) gov(101) csor(3)
> nistalgorithm(4) hashalgs(2) 3 }
>
> When one of these OIDs appears in an AlgorithmIdentifier, all
> implementations MUST accept both NULL and absent parameters as
> legal and equivalent encodings.
>
> 3. Signature Algorithms
>
> This section identifies OIDs for DSA and ECDSA with SHA-224,
> SHA-256, SHA-384, and SHA-512. The contents of the parameters
> component for each signature algorithm vary; details are provided
> for each algorithm.
>
> 3.1 DSA Signature Algorithm
>
> The DSA is defined in the Digital Signature Standard (DSS) [FIPS
> 186-3]. DSA was developed by the U.S. Government, and can be used
> in conjunction with a SHA2 one-way hash function such as SHA-224
> or SHA-256. DSA is fully described in [FIPS 186-3].
>
> When SHA-224 is used, the OID is:
>
> id-dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
> country(16) us(840) organization(1) gov(101) csor(3)
> algorithms(4) id-dsa-with-sha2(3) 1 }
>
> When SHA-256 is used, the OID is:
>
> id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
> country(16) us(840) organization(1) gov(101) csor(3)
> algorithms(4) id-dsa-with-sha2(3) 2 }
>
> When the id-dsa-with-sha224 or id-dsa-with-sha256 algorithm
> identifier appears in the algorithm field as an
> AlgorithmIdentifier, the encoding SHALL omit the parameters field.
> That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one
> component, the OID id-dsa-with-sha224 or id-dsa- with-sha256.
>
> Encoding rules for DSA signature values are specified in [RFC
> 3279].
>
> 3.2 ECDSA Signature Algorithm
>
> The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined
> in, "Public Key Cryptography for the Financial Services Industry:
> The Elliptic Curve Digital Signature Standard (ECDSA)" [X9.62].
> The ASN.1 OIDs used to specify that an ECDSA signature was
> generated using SHA-224, SHA-256, SHA-384 or SHA-512 are
> respectively:
>
> ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
> us(840) ansi-X9- 62(10045) signatures(4) ecdsa-with-SHA2(3)
> 1 }
>
> ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
> us(840) ansi-X9- 62(10045) signatures(4) ecdsa-with-SHA2(3)
> 2 }
>
> ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
> us(840) ansi-X9- 62(10045) signatures(4) ecdsa-with-SHA2(3)
> 3 }
>
> ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
> us(840) ansi-X9- 62(10045) signatures(4) ecdsa-with-SHA2(3)
> 4 }
>
> When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384
> or ecdsa-with-SHA512 algorithm identifier appears in the algorithm
> field as an AlgorithmIdentifier, the encoding MUST omit the
> parameters field. That is, the AlgorithmIdentifier SHALL be a
> SEQUENCE of one component, the OID ecdsa-with-SHA224,
> ecdsa-with-SHA256, ecdsa-with- SHA384 or ecdsa-with-SHA512.
>
> Conforming CA implementations MUST specify the hash algorithm
> explicitly, using the OIDs specified above, when encoding
> ECDSA/SHA2 signatures in certificates and CRLs.
>
> Conforming client implementations that process ECDSA signatures
> with any of the SHA-2 hash algorithms when processing certificates
> and CRLs MUST recognize the corresponding OIDs specified above.
>
> Encoding rules for ECDSA signature values are specified in [RFC
> 3279].
>
> 4. Security Considerations
>
> NIST has defined appropriate use of the hash functions in terms of
> the algorithm strengths and expected time frames for secure use in
> Special Publications (SPs) 800-78-1 [SP 800-78-1], 800-57 [SP
> 800-57] and 800-107 [SP 800-107]. These documents can be used as
> guides to choose appropriate key sizes for various security
> scenarios.
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n49GpTUZ023779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 May 2009 09:51:29 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n49GpTsS023778; Sat, 9 May 2009 09:51:29 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n49GpRKK023770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 9 May 2009 09:51:28 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Sat, 9 May 2009 09:50:48 -0700
To: [email-masked]
From: Paul Hoffman
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Greetings again. This document is *not* ready for advancement. It has many fundamental flaws that prevent it from being an understandable standard.

1) Update status is unclear

As Russ pointed out, much of the information from the RFC 3279 is repeated here. Unlike Russ, I do not consider this to be "minor". This document is intended to be on standards track and presumably is an update to RFC 3279 (even though the header on the first page does not say so). Thus, the repetition is quite bad when it is not exact or, worse, when it is incomplete.

The only way to clear up the update status is to keep the status as updating RFC 3279 and strip the document of everything except the updates to RFC 3279, plus some pointers to recommendations of appropriate use. The good news is that this will turn the document into about two pages, mostly OIDs.

2) Mandating key sizes and lifetimes is inappropriate in this document

RFC 3279 does not mandate key sizes; this draft does. Worse, this draft relies on the tortured logic in NIST SP 800-57 Part 1 that conflates multiple effective key strengths onto a single hash algorithm. The logic that NIST used in making that decision had to do with the difficulty of upgrading a disparate US government infrastructure over a long period of time. That's fine for NIST, but an IETF standard should not make such compromises. It is just wrong to update an existing algorithm RFC by adding a new set of restrictions, but only for some of the algorithms, namely the new ones being added.

The key strength matching and lifetime mandates should be ripped out. It is fine to have a non-normative reference to NIST SP 800-57 Part 1 and NIST SP 800-78-1 in the Security Considerations to help people find the documents.

3) Adding new validation requirements at this late date is wrong

RFC 3279 specified DSA only with SHA-1; this document adds DSA with SHA-2. However, this document now makes all implementations of RFC 3279 that could validate DSA non-conformant. It is wrong to add new algorithms and then punish existing implementations by labelling them non-conformant to a long-established standard.

Following the three guidelines above, the meat of the document is reduced to that below.

--Paul Hoffman

Abstract

This document updates RFC 3279 to specify algorithm identifiers
and ASN.1 encoding rules for the Digital Signature Algorithm (DSA)
and Elliptic Curve Digital Signature Algorithm (ECDSA) digital
signatures when using SHA-224, SHA-256, SHA-384 or SHA-512 as
hashing algorithm. This specification applies to the Internet
X.509 Public Key Infrastructure (PKI) when digital signatures are
used to sign certificates and certificate revocation lists (CRLs).

1. Introduction

This specification defines the contents of the signatureAlgorithm,
signatureValue and signature fields within Internet X.509
certificates and CRLs when these objects are signed using DSA or
ECDSA with a SHA2 hash algorithm. These fields are more fully
described in [RFC 5280].

This document profiles material presented in the "Secure Hash
Standard" [FIPS 180-3], "Public Key Cryptography for the Financial
Services Industry: The Elliptic Curve Digital Signature Standard
(ECDSA)" [X9.62], and the "Digital Signature Standard" [FIPS
186-3].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [RFC 2119].

2. One-way Hash Functions

This section identifies four additional hash algorithms for use
with DSA and ECDSA in the Internet X.509 certificate and CRL
profile [RFC 5280]. SHA-224, SHA-256, SHA-384, and SHA-512
produce a 224-bit, 256-bit, 384-bit and 512-bit "hash" of the
input respectively and are fully described in the Federal
Information Processing Standard 180-3 [FIPS 180-3].

The listed one-way hash functions are identified by the following
object identifiers (OIDs):

id-sha224 OBJECT IDENTIFIER ::= { joint- iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 4 }

id-sha256 OBJECT IDENTIFIER ::= { joint- iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 1 }

id-sha384 OBJECT IDENTIFIER ::= { joint- iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 2 }

id-sha512 OBJECT IDENTIFIER ::= { joint- iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 3 }

When one of these OIDs appears in an AlgorithmIdentifier, all
implementations MUST accept both NULL and absent parameters as
legal and equivalent encodings.

3. Signature Algorithms

This section identifies OIDs for DSA and ECDSA with SHA-224,
SHA-256, SHA-384, and SHA-512. The contents of the parameters
component for each signature algorithm vary; details are provided
for each algorithm.

3.1 DSA Signature Algorithm

The DSA is defined in the Digital Signature Standard (DSS) [FIPS
186-3]. DSA was developed by the U.S. Government, and can be used
in conjunction with a SHA2 one-way hash function such as SHA-224
or SHA-256. DSA is fully described in [FIPS 186-3].

When SHA-224 is used, the OID is:

id-dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3)
algorithms(4) id-dsa-with-sha2(3) 1 }

When SHA-256 is used, the OID is:

id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3)
algorithms(4) id-dsa-with-sha2(3) 2 }

When the id-dsa-with-sha224 or id-dsa-with-sha256 algorithm
identifier appears in the algorithm field as an
AlgorithmIdentifier, the encoding SHALL omit the parameters field.
That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one
component, the OID id-dsa-with-sha224 or id-dsa- with-sha256.

Encoding rules for DSA signature values are specified in [RFC
3279].

3.2 ECDSA Signature Algorithm

The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined
in, "Public Key Cryptography for the Financial Services Industry:
The Elliptic Curve Digital Signature Standard (ECDSA)" [X9.62].
The ASN.1 OIDs used to specify that an ECDSA signature was
generated using SHA-224, SHA-256, SHA-384 or SHA-512 are
respectively:

ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9- 62(10045) signatures(4) ecdsa-with-SHA2(3)
1 }

ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9- 62(10045) signatures(4) ecdsa-with-SHA2(3)
2 }

ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9- 62(10045) signatures(4) ecdsa-with-SHA2(3)
3 }

ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9- 62(10045) signatures(4) ecdsa-with-SHA2(3)
4 }

When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384
or ecdsa-with-SHA512 algorithm identifier appears in the algorithm
field as an AlgorithmIdentifier, the encoding MUST omit the
parameters field. That is, the AlgorithmIdentifier SHALL be a
SEQUENCE of one component, the OID ecdsa-with-SHA224,
ecdsa-with-SHA256, ecdsa-with- SHA384 or ecdsa-with-SHA512.

Conforming CA implementations MUST specify the hash algorithm
explicitly, using the OIDs specified above, when encoding
ECDSA/SHA2 signatures in certificates and CRLs.

Conforming client implementations that process ECDSA signatures
with any of the SHA-2 hash algorithms when processing certificates
and CRLs MUST recognize the corresponding OIDs specified above.

Encoding rules for ECDSA signature values are specified in [RFC
3279].

4. Security Considerations

NIST has defined appropriate use of the hash functions in terms of
the algorithm strengths and expected time frames for secure use in
Special Publications (SPs) 800-78-1 [SP 800-78-1], 800-57 [SP
800-57] and 800-107 [SP 800-107]. These documents can be used as
guides to choose appropriate key sizes for various security
scenarios.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n48H4W5h046278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 May 2009 10:04:32 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n48H4W63046277; Fri, 8 May 2009 10:04:32 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n48H4VvH046271 for ; Fri, 8 May 2009 10:04:31 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 3D01EF24009; Fri, 8 May 2009 13:05:00 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 2CthmdHKFtBN; Fri, 8 May 2009 13:04:30 -0400 (EDT)
Received: from THINKPADR52.vigilsec.com (dhcp-26-110.ripemtg.ripe.net [193.0.26.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 89BFAF24001; Fri, 8 May 2009 13:04:55 -0400 (EDT)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 08 May 2009 13:04:08 -0400
To: Stephen Kent , [email-masked]
From: Russ Housley
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I think the document is ready to go.

MINOR

Much of the information from the RFC 3279 is repeated here, like the
signature value being a sequence or r and s. However, the parameter
stuff is not repeated (p, q, g). The decision of what stuff to
duplicate (or not) should be all or nothing, I think.

EDITORIAL

The OIDs are not formatted for easy reading. I liked the layout in
RFC 4055 better. For example:

id-sha224 OBJECT IDENTIFIER ::= {{ joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 4 }
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 }
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 2 }

Russ

At 11:21 AM 5/6/2009, Stephen Kent wrote:

>The authors of this I-D have requested that I initiate WGLC.
>
>The last call will run for two weeks, closing on May 20th.
>
>Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n47JDrJC065281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 12:13:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n47JDrCE065279; Thu, 7 May 2009 12:13:53 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n47JDfgA065231 for ; Thu, 7 May 2009 12:13:51 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 33656 invoked from network); 7 May 2009 19:13:40 -0000
Received: from unknown (HELO thunderfish.local) ([email-masked] with plain) by smtp110.biz.mail.re2.yahoo.com with SMTP; 7 May 2009 19:13:40 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: 6guLw.wVM1mnefRjkXXxGoeidOwcTnIBD84pfVzNTZcy_906SOJ8p85Dz0G2W15lnxPMJgHaxlza8ikMwSCMakIdON4cGe2DqV0LvG5b_RytZyPi7QnNxjI0nCZvvw3XLxq2a1wWKEEi2cB8WKVIeUVtsuGxP9o.n9e8jWTa.kyiKbqO.AvHMlo.YlZ6CRT61vLf3MxlMIoilT636QO7xuzRZ.ZCTdvuhbZz1SeAgzXDxot5Gjr1w6jtV_GEFPaw2FSuJm8iVpJQlUOEykfuFiJWUPizjDhIPsgy1PBzd0xkW_e4hw--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Thu, 07 May 2009 15:13:40 -0400
From: Sean Turner
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: [email-masked], pkix
Subject: SMIME Capabilities examples
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I'm looking for examples of certificates or messages with SMIME
Capability values for the following algorithms:
- SHA-224, SHA-256, SHA-384, SHA-512
- RSA with MD5, SHA-*
- DSA with SHA-1, SHA-224, SHA-256
- ECDSA with SHA-*
- DH SS/ES with key wrap 3DES or RC2 (40, 64, 128)
- ECDH/ECMQV
- AES-CBC-128, AES-CBC-192, AES-CBC-256
- Camellia
- SEED
- HMAC SHA-*

If any one has examples, I'd appreciate a copy.

spt

p.s. I apologize to those that get this on most lists.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n47BvIV4031689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 04:57:18 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n47BvIa9031688; Thu, 7 May 2009 04:57:18 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n47BvFgb031679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 May 2009 04:57:17 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 76891 invoked from network); 7 May 2009 11:57:19 -0000
Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 7 May 2009 11:57:19 -0000
Received: (qmail 53408 invoked from network); 7 May 2009 11:57:14 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 May 2009 11:57:14 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Thu, 07 May 2009 13:57:13 +0200
Subject: Re: draft-santesson-pkix-certimage-00.txt: any example to date?
From: Stefan Santesson
To: Santoni Adriano
CC:
Message-ID:
Thread-Topic: draft-santesson-pkix-certimage-00.txt: any example to date?
Thread-Index: AcnO/QfRDn7rlWhvrkSFDq6yPhwBpgACu5sAAAC/yKc=
In-Reply-To:
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

The draft was published a few weeks ago so I don't know of any real world
implementations.

The certificate image may contain any mix of text and graphics.
It may for example look very similar to the ID in your wallet.

/Stefan

On 09-05-07 1:37 PM, "Santoni Adriano" wrote:

>=20
> Stefan,
>=20
> are you aware, to date, of any real world "certificate image" to look at =
as a
> good example of how a cert image should look?
>=20
> Adriano
>=20
>=20
> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Pe=
r
> conto di Stefan Santesson
> Inviato: gioved=EC 7 maggio 2009 12.18
> A: Roberto Opazo
> Cc: Paul Hoffman; Russ Housley; [email-masked]
> Oggetto: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
>=20
>=20
>=20
> Roberto,
>=20
> I agree with what you say but would like to add one thing regarding
> application support.
>=20
> It used to be that the browsers were the critical application for showing
> logotypes or a certificate image. However that has changed slightly.
>=20
> EU member states continue to invest considerable resources to provide ser=
vices
> in electronic form, supported by national endorsed ID certificates, suppo=
rted
> by EU commission activities. The services directive, the action plan for
> harmonizing e-signatuires and e-identification, the STORK project, the PE=
PPOL
> project are some significant examples.
>=20
> It is very common for these national infrastructures to provide a small c=
lient
> software which provides the UI for authentication and signing.
>=20
> This makes it possible to use a certificate image to support these servic=
es
> regardless of browser support.
>=20
> I have also talked to several providers of services and CAs in addition t=
o
> representatives from the EU commission and EU projects who are seriously
> interested in using this feature regardless of the browsers.
>=20
> I wouldn't be surprised to see browsers follow once they see the value in
> local UI deployments.
>=20
> /Stefan
>=20
>=20
>=20
>=20
> On 09-05-06 5:59 PM, "Roberto Opazo" wrote:
>=20
>>=20
>> Stefan
>>=20
>> I also suport the idea of specifying a method to bind a visual
>> representation of a certificate in the form of a certificate image to
>> a [RFC5280] public key certificate by defining a new otherLogos image
>> type according to [RFC3709].
>>=20
>> I see two points here:
>>=20
>> * RFC 3709 is already done, so we should choose between completing it
>> with support for a whole certificate image or revoking it. It=B9s easer
>> and consistent to complete the job.
>>=20
>> * As a certificate provider, I think it=B9s very obvious the reason why
>> RFC 3709 has not been adopted, but that=B9s not the point jet. The
>> standard needs some browser support before any CA start using it.
>>=20
>> Best regards,
>>=20
>> Roberto Opazo
>>=20
>> 2009/5/5 Anders Rundgren :
>>>=20
>>> The *motive* is definitely good and worth pursuing.
>>>=20
>>> What's less suitable is the idea of *publishing* an end-user's
>>> credential selection images. =A0I would like to see some samples
>>> applied to eID or VISA certificates.
>>>=20
>>> Anders
>>>=20
>>> ----- Original Message -----
>>> From: "Russ Housley"
>>> To: "Paul Hoffman"
>>> Cc:
>>> Sent: Tuesday, May 05, 2009 15:03
>>> Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
>>>=20
>>>=20
>>>=20
>>> Paul:
>>>=20
>>> We clearly disagree. =A0I still believe that logotypes are needed to
>>> make useful user interfaces. =A0We have not seen logotypes take off in
>>> the marketplece, and I am hoping that the use of a single image
>>> instead of multiple images will remove an impediment.
>>>=20
>>> Russ
>>>=20
>>> At 07:01 PM 4/30/2009, Paul Hoffman wrote:
>>>=20
>>>> At 12:31 AM +0200 5/1/09, Stefan Santesson wrote:
>>>>> On 09-04-30 7:42 PM, "Paul Hoffman" wrote:
>>>>>> - Note that only one person has supported the idea, even
>>>> obliquely, since the
>>>>>> request was posted.
>>>>>>=20
>>>>>=20
>>>>> First of all that is a premature assessment. Very little time has
>>>>> passed so far.
>>>>=20
>>>> That is for the co-chairs to decide. Hopefully, you have recused
>>>> yourself from this decision.
>>>>=20
>>>>> Secondly you are wrong. This draft is supported also by the
>>>>> editors. That makes it five. Only one person so far has voiced agains=
t.
>>>>=20
>>>> There is a reasonable assumption in the IETF that all the co-authors
>>>> on a draft support it. The question for WG adoption is whether
>>>> *others* support the inclusion in the WG.
>>>>=20
>>>>>> - Given the extremely thin adoption of RFC 3709, it is
>>>> inappropriate for the
>>>>>> WG to take on a major extension to that RFC.
>>>>>>=20
>>>>>=20
>>>>> Thin adoption of RFC 3709 is not a problem at all.
>>>>=20
>>>> We disagree, strongly.
>>>>=20
>>>>> One of the problems with
>>>>> just providing logotypes with 3709 is that the solution is
>>>>> incomplete. The certificate image offers a complete solution.
>>>>=20
>>>> Which implementers have said "oh, if you only included Postscript,
>>>> then we would have done 3709"?
>>>>=20
>>>>> The problem is important and need a solution. Building on RFC 3709
>>>>> offers an easy solution.
>>>>=20
>>>> We disagree, strongly.
>>>>=20
>>>>>> As an individual submission:
>>>>>>=20
>>>>>> - This proposes that compliant PKIX validators need to include
>>>> at least one
>>>>>> complex image-display mechanism. =A0These mechanisms have been
>>>> error-prone in
>>>>>> the past, sometimes leading to the execution of arbitrary code on
>>>>>> the host system. Forcing, or even suggesting, this be deployed as
>>>>>> part of
>>>> PKIX seems
>>>>>> needlessly dangerous for very little value.
>>>>>>=20
>>>>>=20
>>>>> I don't understand the problem.
>>>>=20
>>>> Clearly.
>>>>=20
>>>>> We are talking about having the option to display a signed image
>>>>> from a trusted source. As if that would be a lot more dangerous
>>>>> than displaying images in your browser from untrusted sources.
>>>>=20
>>>> To date, the CAs in the root pile have been trusted to issue
>>>> certificates that reflect a proper binding between an end entity and
>>>> a public key. There was some risk of them creating certificates with
>>>> malicious formatting, but that was considered easy to detect. You
>>>> are now proposing that those hundred of CAs be automatically trusted
>>>> to format the art portions of their certificates correctly. That is
>>>> a very different level of trust.
>>>>=20
>>>> Even if a CA formats the certificate in a way they think is correct,
>>>> there is a chance that the named party will have given them
>>>> information that will cause the display mechanism to crash and
>>>> possibly execute arbitrary code. That isn't possible today with any
>>>> sensible ASN.1 parser.
>>>>=20
>>>>>> - The rationale from the introduction of the document for
>>>> showing pictures
>>>>>> instead of words is wrong. If you want to fix the words the user
>>>> sees, fix the
>>>>>> words, don't pretend that a picture it is sorta-kinda based on the
>>>>>> current words but not really will lead to better security.
>>>>>>=20
>>>>>=20
>>>>> I don't have to pretend. We have at least 3 image formats that is
>>>>> very well suited to display a mix of text and graphics. The feature
>>>>> achieved is usability more than security. To the extent security
>>>>> can benefit from a more user friendly UI, this is also providing
>>>>> better security.
>>>>=20
>>>> This does not explain why you don't try to just fix the problems
>>>> that you claim are the base for this extension. No one *needs*
>>>> pictures; they need accurate information about the identified party.
>>>> That can be done in text, yes?
>>>>=20
>>>>>> - "The previous RFC failed so now we want to extend it to make it
>>>>>> more complicated" just sounds silly for a standard. The fact that
>>>>>> it
>>>> has been done
>>>>>> in the IETF before doesn't mean we should make the same mistake agai=
n.
>>>>>>=20
>>>>>=20
>>>>> Not at all. It is the total opposite. Just adding logotypes didn't
>>>>> make the task to provide a understandable UI easy enough. So we
>>>>> need to make the solution easier and complete.
>>>>>=20
>>>>> A UI just using RFC 3709 would have to:
>>>>> - Decide where to place the logotypes on the screen relative to the
>>>>> text
>>>>> - Decide how to scale the images relative to each other and to the
>>>>> text
>>>>> - Come up with display text describing the content of each
>>>>> attribute
>>>>> - Decide which naming attributes and other names to display
>>>>> - Figure out how to serve the users language preferences with
>>>>> respect to display text.
>>>>>=20
>>>>> A UI using the certificate image in this new draft, can instead do
>>>>> the following
>>>>> - Display the certificate Image
>>>>>=20
>>>>> I would call that easier, not more complicated.
>>>>=20
>>>> You come from the assumption that logotypes are actually useful, not
>>>> just (to use your terms) "user friendly" and based on "usability
>>>> more than security".
>>>>=20
>>>>> I would understand your violent disagreement more Paul, if you
>>>>> could offer an alternative solution.
>>>>=20
>>>> I already did that in the last message, but let me try again. If the
>>>> problem is that the names in certificates are not right, fix them.
>>>> Specify "display text describing the content of each attribute",
>>>> "decide which naming attributes and other names to display", and
>>>> "figure out how to serve the users language preferences with respect
>>>> to display text". None of that takes graphics, much less more
>>>> complicated graphics than has already failed.
>>>>=20
>>>> --Paul Hoffman, Director
>>>> --VPN Consortium
>>>=20
>>>=20
>>=20
>=20
>=20

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n47Bbo1j029818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 04:37:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n47BboDF029817; Thu, 7 May 2009 04:37:50 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from out.almavivaitalia.it (host47-104-static.43-193-b.business.telecomitalia.it [193.43.104.47] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n47BbcNp029802 for ; Thu, 7 May 2009 04:37:49 -0700 (MST) (envelope-from [email-masked])
Received: from POSTA02.itmaster.local ([156.54.185.25]) by out.almavivaitalia.it with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 13:40:46 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: draft-santesson-pkix-certimage-00.txt: any example to date?
Date: Thu, 7 May 2009 13:37:35 +0200
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-santesson-pkix-certimage-00.txt: any example to date?
Thread-Index: AcnO/QfRDn7rlWhvrkSFDq6yPhwBpgACu5sA
References:
From: "Santoni Adriano"
To: "Stefan Santesson"
Cc:
X-OriginalArrivalTime: 07 May 2009 11:40:46.0265 (UTC) FILETIME=[A93AA290:01C9CF08]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stefan,

are you aware, to date, of any real world "certificate image" to look at =
as a good example of how a cert image should look?=20

Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] =
Per conto di Stefan Santesson
Inviato: gioved=EC 7 maggio 2009 12.18
A: Roberto Opazo
Cc: Paul Hoffman; Russ Housley; [email-masked]
Oggetto: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt

Roberto,

I agree with what you say but would like to add one thing regarding =
application support.

It used to be that the browsers were the critical application for =
showing logotypes or a certificate image. However that has changed =
slightly.

EU member states continue to invest considerable resources to provide =
services in electronic form, supported by national endorsed ID =
certificates, supported by EU commission activities. The services =
directive, the action plan for harmonizing e-signatuires and =
e-identification, the STORK project, the PEPPOL project are some =
significant examples.

It is very common for these national infrastructures to provide a small =
client software which provides the UI for authentication and signing.

This makes it possible to use a certificate image to support these =
services regardless of browser support.

I have also talked to several providers of services and CAs in addition =
to representatives from the EU commission and EU projects who are =
seriously interested in using this feature regardless of the browsers.

I wouldn't be surprised to see browsers follow once they see the value =
in local UI deployments.

/Stefan

On 09-05-06 5:59 PM, "Roberto Opazo" wrote:

>=20
> Stefan
>=20
> I also suport the idea of specifying a method to bind a visual=20
> representation of a certificate in the form of a certificate image to =

> a [RFC5280] public key certificate by defining a new otherLogos image=20
> type according to [RFC3709].
>=20
> I see two points here:
>=20
> * RFC 3709 is already done, so we should choose between completing it=20
> with support for a whole certificate image or revoking it. It=B9s =
easer=20
> and consistent to complete the job.
>=20
> * As a certificate provider, I think it=B9s very obvious the reason =
why=20
> RFC 3709 has not been adopted, but that=B9s not the point jet. The=20
> standard needs some browser support before any CA start using it.
>=20
> Best regards,
>=20
> Roberto Opazo
>=20
> 2009/5/5 Anders Rundgren :
>>=20
>> The *motive* is definitely good and worth pursuing.
>>=20
>> What's less suitable is the idea of *publishing* an end-user's=20
>> credential selection images. =A0I would like to see some samples=20
>> applied to eID or VISA certificates.
>>=20
>> Anders
>>=20
>> ----- Original Message -----
>> From: "Russ Housley"
>> To: "Paul Hoffman"
>> Cc:
>> Sent: Tuesday, May 05, 2009 15:03
>> Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
>>=20
>>=20
>>=20
>> Paul:
>>=20
>> We clearly disagree. =A0I still believe that logotypes are needed to=20
>> make useful user interfaces. =A0We have not seen logotypes take off =
in=20
>> the marketplece, and I am hoping that the use of a single image=20
>> instead of multiple images will remove an impediment.
>>=20
>> Russ
>>=20
>> At 07:01 PM 4/30/2009, Paul Hoffman wrote:
>>=20
>>> At 12:31 AM +0200 5/1/09, Stefan Santesson wrote:
>>>> On 09-04-30 7:42 PM, "Paul Hoffman" wrote:
>>>>> - Note that only one person has supported the idea, even
>>> obliquely, since the
>>>>> request was posted.
>>>>>=20
>>>>=20
>>>> First of all that is a premature assessment. Very little time has=20
>>>> passed so far.
>>>=20
>>> That is for the co-chairs to decide. Hopefully, you have recused=20
>>> yourself from this decision.
>>>=20
>>>> Secondly you are wrong. This draft is supported also by the=20
>>>> editors. That makes it five. Only one person so far has voiced =
against.
>>>=20
>>> There is a reasonable assumption in the IETF that all the co-authors =

>>> on a draft support it. The question for WG adoption is whether
>>> *others* support the inclusion in the WG.
>>>=20
>>>>> - Given the extremely thin adoption of RFC 3709, it is
>>> inappropriate for the
>>>>> WG to take on a major extension to that RFC.
>>>>>=20
>>>>=20
>>>> Thin adoption of RFC 3709 is not a problem at all.
>>>=20
>>> We disagree, strongly.
>>>=20
>>>> One of the problems with
>>>> just providing logotypes with 3709 is that the solution is=20
>>>> incomplete. The certificate image offers a complete solution.
>>>=20
>>> Which implementers have said "oh, if you only included Postscript,=20
>>> then we would have done 3709"?
>>>=20
>>>> The problem is important and need a solution. Building on RFC 3709=20
>>>> offers an easy solution.
>>>=20
>>> We disagree, strongly.
>>>=20
>>>>> As an individual submission:
>>>>>=20
>>>>> - This proposes that compliant PKIX validators need to include
>>> at least one
>>>>> complex image-display mechanism. =A0These mechanisms have been
>>> error-prone in
>>>>> the past, sometimes leading to the execution of arbitrary code on=20
>>>>> the host system. Forcing, or even suggesting, this be deployed as=20
>>>>> part of
>>> PKIX seems
>>>>> needlessly dangerous for very little value.
>>>>>=20
>>>>=20
>>>> I don't understand the problem.
>>>=20
>>> Clearly.
>>>=20
>>>> We are talking about having the option to display a signed image=20
>>>> from a trusted source. As if that would be a lot more dangerous=20
>>>> than displaying images in your browser from untrusted sources.
>>>=20
>>> To date, the CAs in the root pile have been trusted to issue=20
>>> certificates that reflect a proper binding between an end entity and =

>>> a public key. There was some risk of them creating certificates with =

>>> malicious formatting, but that was considered easy to detect. You=20
>>> are now proposing that those hundred of CAs be automatically trusted =

>>> to format the art portions of their certificates correctly. That is=20
>>> a very different level of trust.
>>>=20
>>> Even if a CA formats the certificate in a way they think is correct, =

>>> there is a chance that the named party will have given them=20
>>> information that will cause the display mechanism to crash and=20
>>> possibly execute arbitrary code. That isn't possible today with any=20
>>> sensible ASN.1 parser.
>>>=20
>>>>> - The rationale from the introduction of the document for
>>> showing pictures
>>>>> instead of words is wrong. If you want to fix the words the user
>>> sees, fix the
>>>>> words, don't pretend that a picture it is sorta-kinda based on the =

>>>>> current words but not really will lead to better security.
>>>>>=20
>>>>=20
>>>> I don't have to pretend. We have at least 3 image formats that is=20
>>>> very well suited to display a mix of text and graphics. The feature =

>>>> achieved is usability more than security. To the extent security=20
>>>> can benefit from a more user friendly UI, this is also providing=20
>>>> better security.
>>>=20
>>> This does not explain why you don't try to just fix the problems=20
>>> that you claim are the base for this extension. No one *needs*=20
>>> pictures; they need accurate information about the identified party.
>>> That can be done in text, yes?
>>>=20
>>>>> - "The previous RFC failed so now we want to extend it to make it=20
>>>>> more complicated" just sounds silly for a standard. The fact that=20
>>>>> it
>>> has been done
>>>>> in the IETF before doesn't mean we should make the same mistake =
again.
>>>>>=20
>>>>=20
>>>> Not at all. It is the total opposite. Just adding logotypes didn't=20
>>>> make the task to provide a understandable UI easy enough. So we=20
>>>> need to make the solution easier and complete.
>>>>=20
>>>> A UI just using RFC 3709 would have to:
>>>> - Decide where to place the logotypes on the screen relative to the =

>>>> text
>>>> - Decide how to scale the images relative to each other and to the=20
>>>> text
>>>> - Come up with display text describing the content of each=20
>>>> attribute
>>>> - Decide which naming attributes and other names to display
>>>> - Figure out how to serve the users language preferences with=20
>>>> respect to display text.
>>>>=20
>>>> A UI using the certificate image in this new draft, can instead do=20
>>>> the following
>>>> - Display the certificate Image
>>>>=20
>>>> I would call that easier, not more complicated.
>>>=20
>>> You come from the assumption that logotypes are actually useful, not =

>>> just (to use your terms) "user friendly" and based on "usability=20
>>> more than security".
>>>=20
>>>> I would understand your violent disagreement more Paul, if you=20
>>>> could offer an alternative solution.
>>>=20
>>> I already did that in the last message, but let me try again. If the =

>>> problem is that the names in certificates are not right, fix them.
>>> Specify "display text describing the content of each attribute",=20
>>> "decide which naming attributes and other names to display", and=20
>>> "figure out how to serve the users language preferences with respect =

>>> to display text". None of that takes graphics, much less more=20
>>> complicated graphics than has already failed.
>>>=20
>>> --Paul Hoffman, Director
>>> --VPN Consortium
>>=20
>>=20
>=20

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n47AHneJ022622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 03:17:49 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n47AHnlm022621; Thu, 7 May 2009 03:17:49 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n47AHYmh022594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 May 2009 03:17:47 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 84485 invoked from network); 7 May 2009 10:17:37 -0000
Received: from s34.loopia.se (HELO s60.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 7 May 2009 10:17:37 -0000
Received: (qmail 40938 invoked from network); 7 May 2009 10:17:32 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 May 2009 10:17:32 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Thu, 07 May 2009 12:17:31 +0200
Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
From: Stefan Santesson
To: Roberto Opazo
CC: Paul Hoffman , Russ Housley ,
Message-ID:
Thread-Topic: I-D ACTION:draft-santesson-pkix-certimage-00.txt
Thread-Index: AcnO/QfRDn7rlWhvrkSFDq6yPhwBpg==
In-Reply-To:
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Roberto,

I agree with what you say but would like to add one thing regarding
application support.

It used to be that the browsers were the critical application for showing
logotypes or a certificate image. However that has changed slightly.

EU member states continue to invest considerable resources to provide
services in electronic form, supported by national endorsed ID certificates=
,
supported by EU commission activities. The services directive, the action
plan for harmonizing e-signatuires and e-identification, the STORK project,
the PEPPOL project are some significant examples.

It is very common for these national infrastructures to provide a small
client software which provides the UI for authentication and signing.

This makes it possible to use a certificate image to support these services
regardless of browser support.

I have also talked to several providers of services and CAs in addition to
representatives from the EU commission and EU projects who are seriously
interested in using this feature regardless of the browsers.

I wouldn't be surprised to see browsers follow once they see the value in
local UI deployments.

/Stefan

On 09-05-06 5:59 PM, "Roberto Opazo" wrote:

>=20
> Stefan
>=20
> I also suport the idea of specifying a method to bind a visual
> representation of a certificate in the form of a certificate image to
> a [RFC5280] public key certificate by defining a new otherLogos image
> type according to [RFC3709].
>=20
> I see two points here:
>=20
> * RFC 3709 is already done, so we should choose between completing it
> with support for a whole certificate image or revoking it. It=B9s easer
> and consistent to complete the job.
>=20
> * As a certificate provider, I think it=B9s very obvious the reason why
> RFC 3709 has not been adopted, but that=B9s not the point jet. The
> standard needs some browser support before any CA start using it.
>=20
> Best regards,
>=20
> Roberto Opazo
>=20
> 2009/5/5 Anders Rundgren :
>>=20
>> The *motive* is definitely good and worth pursuing.
>>=20
>> What's less suitable is the idea of *publishing* an end-user's credentia=
l
>> selection images. =A0I would like to see some samples applied to eID or VI=
SA
>> certificates.
>>=20
>> Anders
>>=20
>> ----- Original Message -----
>> From: "Russ Housley"
>> To: "Paul Hoffman"
>> Cc:
>> Sent: Tuesday, May 05, 2009 15:03
>> Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
>>=20
>>=20
>>=20
>> Paul:
>>=20
>> We clearly disagree. =A0I still believe that logotypes are needed to
>> make useful user interfaces. =A0We have not seen logotypes take off in
>> the marketplece, and I am hoping that the use of a single image
>> instead of multiple images will remove an impediment.
>>=20
>> Russ
>>=20
>> At 07:01 PM 4/30/2009, Paul Hoffman wrote:
>>=20
>>> At 12:31 AM +0200 5/1/09, Stefan Santesson wrote:
>>>> On 09-04-30 7:42 PM, "Paul Hoffman" wrote:
>>>>> - Note that only one person has supported the idea, even
>>> obliquely, since the
>>>>> request was posted.
>>>>>=20
>>>>=20
>>>> First of all that is a premature assessment. Very little time has pass=
ed so
>>>> far.
>>>=20
>>> That is for the co-chairs to decide. Hopefully, you have recused
>>> yourself from this decision.
>>>=20
>>>> Secondly you are wrong. This draft is supported also by the editors. T=
hat
>>>> makes it five. Only one person so far has voiced against.
>>>=20
>>> There is a reasonable assumption in the IETF that all the co-authors
>>> on a draft support it. The question for WG adoption is whether
>>> *others* support the inclusion in the WG.
>>>=20
>>>>> - Given the extremely thin adoption of RFC 3709, it is
>>> inappropriate for the
>>>>> WG to take on a major extension to that RFC.
>>>>>=20
>>>>=20
>>>> Thin adoption of RFC 3709 is not a problem at all.
>>>=20
>>> We disagree, strongly.
>>>=20
>>>> One of the problems with
>>>> just providing logotypes with 3709 is that the solution is incomplete.=
The
>>>> certificate image offers a complete solution.
>>>=20
>>> Which implementers have said "oh, if you only included Postscript,
>>> then we would have done 3709"?
>>>=20
>>>> The problem is important and need a solution. Building on RFC 3709 off=
ers
>>>> an
>>>> easy solution.
>>>=20
>>> We disagree, strongly.
>>>=20
>>>>> As an individual submission:
>>>>>=20
>>>>> - This proposes that compliant PKIX validators need to include
>>> at least one
>>>>> complex image-display mechanism. =A0These mechanisms have been
>>> error-prone in
>>>>> the past, sometimes leading to the execution of arbitrary code on the=
host
>>>>> system. Forcing, or even suggesting, this be deployed as part of
>>> PKIX seems
>>>>> needlessly dangerous for very little value.
>>>>>=20
>>>>=20
>>>> I don't understand the problem.
>>>=20
>>> Clearly.
>>>=20
>>>> We are talking about having the option to
>>>> display a signed image from a trusted source. As if that would be a lo=
t
>>>> more
>>>> dangerous than displaying images in your browser from untrusted source=
s.
>>>=20
>>> To date, the CAs in the root pile have been trusted to issue
>>> certificates that reflect a proper binding between an end entity and
>>> a public key. There was some risk of them creating certificates with
>>> malicious formatting, but that was considered easy to detect. You
>>> are now proposing that those hundred of CAs be automatically trusted
>>> to format the art portions of their certificates correctly. That is
>>> a very different level of trust.
>>>=20
>>> Even if a CA formats the certificate in a way they think is correct,
>>> there is a chance that the named party will have given them
>>> information that will cause the display mechanism to crash and
>>> possibly execute arbitrary code. That isn't possible today with any
>>> sensible ASN.1 parser.
>>>=20
>>>>> - The rationale from the introduction of the document for
>>> showing pictures
>>>>> instead of words is wrong. If you want to fix the words the user
>>> sees, fix the
>>>>> words, don't pretend that a picture it is sorta-kinda based on the cu=
rrent
>>>>> words but not really will lead to better security.
>>>>>=20
>>>>=20
>>>> I don't have to pretend. We have at least 3 image formats that is very=
well
>>>> suited to display a mix of text and graphics. The feature achieved is
>>>> usability more than security. To the extent security can benefit from =
a
>>>> more
>>>> user friendly UI, this is also providing better security.
>>>=20
>>> This does not explain why you don't try to just fix the problems
>>> that you claim are the base for this extension. No one *needs*
>>> pictures; they need accurate information about the identified party.
>>> That can be done in text, yes?
>>>=20
>>>>> - "The previous RFC failed so now we want to extend it to make it mor=
e
>>>>> complicated" just sounds silly for a standard. The fact that it
>>> has been done
>>>>> in the IETF before doesn't mean we should make the same mistake again=
.
>>>>>=20
>>>>=20
>>>> Not at all. It is the total opposite. Just adding logotypes didn't mak=
e the
>>>> task to provide a understandable UI easy enough. So we need to make th=
e
>>>> solution easier and complete.
>>>>=20
>>>> A UI just using RFC 3709 would have to:
>>>> - Decide where to place the logotypes on the screen relative to the te=
xt
>>>> - Decide how to scale the images relative to each other and to the tex=
t
>>>> - Come up with display text describing the content of each attribute
>>>> - Decide which naming attributes and other names to display
>>>> - Figure out how to serve the users language preferences with respect =
to
>>>> display text.
>>>>=20
>>>> A UI using the certificate image in this new draft, can instead do the
>>>> following
>>>> - Display the certificate Image
>>>>=20
>>>> I would call that easier, not more complicated.
>>>=20
>>> You come from the assumption that logotypes are actually useful, not
>>> just (to use your terms) "user friendly" and based on "usability
>>> more than security".
>>>=20
>>>> I would understand your violent disagreement more Paul, if you could o=
ffer
>>>> an alternative solution.
>>>=20
>>> I already did that in the last message, but let me try again. If the
>>> problem is that the names in certificates are not right, fix them.
>>> Specify "display text describing the content of each attribute",
>>> "decide which naming attributes and other names to display", and
>>> "figure out how to serve the users language preferences with respect
>>> to display text". None of that takes graphics, much less more
>>> complicated graphics than has already failed.
>>>=20
>>> --Paul Hoffman, Director
>>> --VPN Consortium
>>=20
>>=20
>=20

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n478eVV3014058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 01:40:31 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n478eVUX014057; Thu, 7 May 2009 01:40:31 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n478eHZJ014040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 May 2009 01:40:30 -0700 (MST) (envelope-from [email-masked])
Received: from ERA1 ([94.191.250.70]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id ONV77515 for ; Thu, 07 May 2009 10:40:15 +0200
From: "Erik Andersen"
To: "PKIX"
Subject: Tutorial on OCSP
Date: Thu, 7 May 2009 10:40:14 +0200
Message-ID: <6BCF824D91F74FA793C5F6254AEC04AC@ERA1>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C9CF00.36987300"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6838
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AcnO73BJlGAmala8RViJC6o5TWsO6Q==
Importance: Normal
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C9CF00.36987300
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

As there, at least among some, is a misunderstanding within ITU-T Study
Group 17 on the scope of RFC 2560, I decided to write something on the
subject to possibly correct such misunderstanding. The result so far may =
be
found on http://www.x500standard.com/index.php?n=3DX509W.OCSP. I will be =
very
happy to receive comments on correctness, suggestions for improvements, =
more
explanations, etc.=20

=20

Erik Andersen

Andersen's L-Service

Elsevej 48, DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

email: [email-masked]

www.x500.eu

www.x500standard.com

=20

------=_NextPart_000_0006_01C9CF00.36987300
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

As there, at least among some, is a =
misunderstanding within
ITU-T Study Group 17 on the scope of RFC 2560, I decided to write =
something on
the subject to possibly correct such misunderstanding. The result so far =
may be
found on http://www.=
x500standard.com/index.php?n=3DX509W.OCSP.
I will be very happy to receive comments on correctness, suggestions for
improvements, more explanations, etc.

Erik Andersen

Andersen's L-Service

Elsevej 48, DK-3500 =
Vaerloese

Denmark

Mobile: +45 2097 1490

email: [email-masked]

www.x500.eu

www.x500standard.com

------=_NextPart_000_0006_01C9CF00.36987300--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n478Yh1V013611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 01:34:43 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n478YhtU013610; Thu, 7 May 2009 01:34:43 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n478YVvw013589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 May 2009 01:34:42 -0700 (MST) (envelope-from [email-masked])
Received: from ERA1 ([94.191.250.70]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id ONP26729 for ; Thu, 07 May 2009 10:34:29 +0200
From: "Erik Andersen"
To:
Subject: RE: Signing of OCSP responses
Date: Thu, 7 May 2009 10:34:27 +0200
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6838
In-Reply-To:
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AcnO6bSiRBbzjEPYQom61bLlym9HaQABH28g
Importance: Normal
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi Peter,

When I do not understand something, it is either because I am stupid or
because it is not understandable. I am always happy when the latter =
seems to
be the case.

Erik Andersen
Andersen's L-Service
Elsevej 48, DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
email: [email-masked]
www.x500.eu
www.x500standard.com
=20

-----Original Message-----
From: pgut001 [mailto:[email-masked]]=20
Sent: 7. maj 2009 09:59
To: [email-masked]; [email-masked]
Subject: RE: Signing of OCSP responses

"Erik Andersen" writes:

>Thanks for your reply. It appears to me that RFC 2560 is not always =
that
>precise.

It has been called "schizophrenic" because it allows for all of the
conflicting business models of the various contributors in the same RFC.
This
does not help with interpretation :-).

Peter.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n477xIoY011144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 00:59:18 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n477xI07011143; Thu, 7 May 2009 00:59:18 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n477x69V011130 for ; Thu, 7 May 2009 00:59:16 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5F34E1714C1; Thu, 7 May 2009 19:59:05 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNt3YUc73RLQ; Thu, 7 May 2009 19:59:05 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C65A617148F; Thu, 7 May 2009 19:59:04 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 8DB8421E4031; Thu, 7 May 2009 19:59:01 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1M1yVR-0006zT-DW; Thu, 07 May 2009 19:59:01 +1200
From: Peter Gutmann
To: [email-masked], [email-masked]
Subject: RE: Signing of OCSP responses
In-Reply-To: <083E6F4250454F64A340AC3B2BF8A484@ERA1>
Message-Id:
Date: Thu, 07 May 2009 19:59:01 +1200
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

"Erik Andersen" writes:

>Thanks for your reply. It appears to me that RFC 2560 is not always that
>precise.

It has been called "schizophrenic" because it allows for all of the
conflicting business models of the various contributors in the same RFC. This
does not help with interpretation :-).

Peter.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46JPgUO071213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 May 2009 12:25:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n46JPgb3071212; Wed, 6 May 2009 12:25:42 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.67.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46JPV3h071200 for ; Wed, 6 May 2009 12:25:42 -0700 (MST) (envelope-from [email-masked])
Received: from smtp.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id n46JT927007211 for ; Wed, 6 May 2009 19:29:09 GMT
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CE80.6B01D34E"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: NSA Suite B Certificate & CRL Profile
Date: Wed, 6 May 2009 15:25:30 -0400
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: NSA Suite B Certificate & CRL Profile
Thread-Index: AcnOgGu6AAiv2taiR6mBCQ6Ej3ipjQ==
From: "Zieglar, Lydia L."
To:
Cc: "Wallner, Debbie M"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9CE80.6B01D34E
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We have recently submitted the next revision of the National Security
Agency's Suite B Certificate and CRL Profile to the IETF as an
Internet-Draft (individual submission).
=20
Comments are welcome and may be sent to Lydia Zieglar at
[email-masked] =20
=20
You may find the document at:
http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cert-profile-02
.txt
=20
Thanks,
Lydia Zieglar
=20
=20
Lydia Zieglar
301-688-1028
[email-masked]
=20

------_=_NextPart_001_01C9CE80.6B01D34E
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We =
have recently=20
submitted the next revision of the National Security Agency's Suite B=20
Certificate and CRL Profile to the IETF as an Internet-Draft (individual =

submission).

Comments are=20
welcome and may be sent to Lydia Zieglar at [email-masked]

You =
may find the=20
document at:

http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cer=
t-profile-02.txt

Thanks,

Lydia Zieglar

Lydia Zieglar

301-688-1028

[email-masked]

------_=_NextPart_001_01C9CE80.6B01D34E--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46Gxgwp059327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 May 2009 09:59:42 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n46Gxgwg059326; Wed, 6 May 2009 09:59:42 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-qy0-f103.google.com (mail-qy0-f103.google.com [209.85.221.103]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46GxUTI059290 for ; Wed, 6 May 2009 09:59:41 -0700 (MST) (envelope-from [email-masked])
Received: by qyk1 with SMTP id 1so413234qyk.16 for ; Wed, 06 May 2009 09:59:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.68.7 with SMTP id v7mr2702627ybk.131.1241629170414; Wed, 06 May 2009 09:59:30 -0700 (PDT)
In-Reply-To: <416BDDE8F8D5404E8558784D88F0651F@AndersPC>
References: <[email-masked]> <416BDDE8F8D5404E8558784D88F0651F@AndersPC>
Date: Wed, 6 May 2009 12:59:30 -0400
Message-ID:
Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
From: Roberto Opazo
To: Anders Rundgren
Cc: Paul Hoffman , Russ Housley , [email-masked]
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stefan

I also suport the idea of specifying a method to bind a visual
representation of a certificate in the form of a certificate image to
a [RFC5280] public key certificate by defining a new otherLogos image
type according to [RFC3709].

I see two points here:

* RFC 3709 is already done, so we should choose between completing it
with support for a whole certificate image or revoking it. It=92s easer
and consistent to complete the job.

* As a certificate provider, I think it=92s very obvious the reason why
RFC 3709 has not been adopted, but that=92s not the point jet. The
standard needs some browser support before any CA start using it.

Best regards,

Roberto Opazo

2009/5/5 Anders Rundgren :
>
> The *motive* is definitely good and worth pursuing.
>
> What's less suitable is the idea of *publishing* an end-user's credential
> selection images. =A0I would like to see some samples applied to eID or V=
ISA
> certificates.
>
> Anders
>
> ----- Original Message -----
> From: "Russ Housley"
> To: "Paul Hoffman"
> Cc:
> Sent: Tuesday, May 05, 2009 15:03
> Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
>
>
>
> Paul:
>
> We clearly disagree. =A0I still believe that logotypes are needed to
> make useful user interfaces. =A0We have not seen logotypes take off in
> the marketplece, and I am hoping that the use of a single image
> instead of multiple images will remove an impediment.
>
> Russ
>
> At 07:01 PM 4/30/2009, Paul Hoffman wrote:
>
>>At 12:31 AM +0200 5/1/09, Stefan Santesson wrote:
>> >On 09-04-30 7:42 PM, "Paul Hoffman" wrote:
>> > > - Note that only one person has supported the idea, even
>> obliquely, since the
>> >> request was posted.
>> >>
>> >
>> >First of all that is a premature assessment. Very little time has passe=
d so
>> >far.
>>
>>That is for the co-chairs to decide. Hopefully, you have recused
>>yourself from this decision.
>>
>> >Secondly you are wrong. This draft is supported also by the editors. Th=
at
>> >makes it five. Only one person so far has voiced against.
>>
>>There is a reasonable assumption in the IETF that all the co-authors
>>on a draft support it. The question for WG adoption is whether
>>*others* support the inclusion in the WG.
>>
>> > > - Given the extremely thin adoption of RFC 3709, it is
>> inappropriate for the
>> >> WG to take on a major extension to that RFC.
>> >>
>> >
>> >Thin adoption of RFC 3709 is not a problem at all.
>>
>>We disagree, strongly.
>>
>> >One of the problems with
>> >just providing logotypes with 3709 is that the solution is incomplete. =
The
>> >certificate image offers a complete solution.
>>
>>Which implementers have said "oh, if you only included Postscript,
>>then we would have done 3709"?
>>
>> >The problem is important and need a solution. Building on RFC 3709 offe=
rs an
>> >easy solution.
>>
>>We disagree, strongly.
>>
>> > > As an individual submission:
>> >>
>> >> - This proposes that compliant PKIX validators need to include
>> at least one
>> >> complex image-display mechanism. =A0These mechanisms have been
>> error-prone in
>> >> the past, sometimes leading to the execution of arbitrary code on the=
host
>> >> system. Forcing, or even suggesting, this be deployed as part of
>> PKIX seems
>> >> needlessly dangerous for very little value.
>> >>
>> >
>> >I don't understand the problem.
>>
>>Clearly.
>>
>> >We are talking about having the option to
>> >display a signed image from a trusted source. As if that would be a lot=
more
>> >dangerous than displaying images in your browser from untrusted sources=
.
>>
>>To date, the CAs in the root pile have been trusted to issue
>>certificates that reflect a proper binding between an end entity and
>>a public key. There was some risk of them creating certificates with
>>malicious formatting, but that was considered easy to detect. You
>>are now proposing that those hundred of CAs be automatically trusted
>>to format the art portions of their certificates correctly. That is
>>a very different level of trust.
>>
>>Even if a CA formats the certificate in a way they think is correct,
>>there is a chance that the named party will have given them
>>information that will cause the display mechanism to crash and
>>possibly execute arbitrary code. That isn't possible today with any
>>sensible ASN.1 parser.
>>
>> > > - The rationale from the introduction of the document for
>> showing pictures
>> >> instead of words is wrong. If you want to fix the words the user
>> sees, fix the
>> >> words, don't pretend that a picture it is sorta-kinda based on the cu=
rrent
>> >> words but not really will lead to better security.
>> >>
>> >
>> >I don't have to pretend. We have at least 3 image formats that is very =
well
>> >suited to display a mix of text and graphics. The feature achieved is
>> >usability more than security. To the extent security can benefit from a=
more
>> >user friendly UI, this is also providing better security.
>>
>>This does not explain why you don't try to just fix the problems
>>that you claim are the base for this extension. No one *needs*
>>pictures; they need accurate information about the identified party.
>>That can be done in text, yes?
>>
>> > > - "The previous RFC failed so now we want to extend it to make it mo=
re
>> > > complicated" just sounds silly for a standard. The fact that it
>> has been done
>> > > in the IETF before doesn't mean we should make the same mistake agai=
n.
>> > >
>> >
>> >Not at all. It is the total opposite. Just adding logotypes didn't make=
the
>> >task to provide a understandable UI easy enough. So we need to make the
>> >solution easier and complete.
>> >
>> >A UI just using RFC 3709 would have to:
>> > - Decide where to place the logotypes on the screen relative to the te=
xt
>> > - Decide how to scale the images relative to each other and to the tex=
t
>> > - Come up with display text describing the content of each attribute
>> > - Decide which naming attributes and other names to display
>> > - Figure out how to serve the users language preferences with respect =
to
>> >display text.
>> >
>> >A UI using the certificate image in this new draft, can instead do the
>> >following
>> > - Display the certificate Image
>> >
>> >I would call that easier, not more complicated.
>>
>>You come from the assumption that logotypes are actually useful, not
>>just (to use your terms) "user friendly" and based on "usability
>>more than security".
>>
>> >I would understand your violent disagreement more Paul, if you could of=
fer
>> >an alternative solution.
>>
>>I already did that in the last message, but let me try again. If the
>>problem is that the names in certificates are not right, fix them.
>>Specify "display text describing the content of each attribute",
>>"decide which naming attributes and other names to display", and
>>"figure out how to serve the users language preferences with respect
>>to display text". None of that takes graphics, much less more
>>complicated graphics than has already failed.
>>
>>--Paul Hoffman, Director
>>--VPN Consortium
>
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46FYis0052358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 May 2009 08:34:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n46FYiBX052356; Wed, 6 May 2009 08:34:44 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46FYgwx052346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 May 2009 08:34:43 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1M1j8s-0006ct-An for [email-masked]; Wed, 06 May 2009 11:34:42 -0400
Mime-Version: 1.0
Message-Id:
Date: Wed, 6 May 2009 11:34:39 -0400
To: [email-masked]
From: Stephen Kent
Subject: Nevermind!
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stephen and Stefan reminded me that "other certs" completed WGLC.
Thats what 4 weeks of vacation in a 5 weeks interval can do to my
brian.

Nevermind.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46FLjB2051405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 May 2009 08:21:45 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n46FLjC4051404; Wed, 6 May 2009 08:21:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46FLY5L051381 for ; Wed, 6 May 2009 08:21:44 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M1iw9-0002DF-ER for [email-masked]; Wed, 06 May 2009 11:21:33 -0400
Mime-Version: 1.0
Message-Id:
Date: Wed, 6 May 2009 11:21:31 -0400
To: [email-masked]
From: Stephen Kent
Subject: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

The authors of this I-D have requested that I initiate WGLC.

The last call will run for two weeks, closing on May 20th.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46F9RQc050315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 May 2009 08:09:28 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n46F9Rfx050312; Wed, 6 May 2009 08:09:27 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46F9NYD050302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 May 2009 08:09:23 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1M1ikM-00066Y-BO for [email-masked]; Wed, 06 May 2009 11:09:22 -0400
Mime-Version: 1.0
Message-Id:
Date: Wed, 6 May 2009 11:09:20 -0400
To: [email-masked]
From: Stephen Kent
Subject: WGLC for "other certs" I-D
Content-Type: multipart/alternative; boundary="============_-970499934==_ma============"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--============_-970499934==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

I am initiating a WGLC on draft-ietf-pkix-other-certs-03.

The last call will end in two weeks, on May 20th.

Steve
--============_-970499934==_ma============
Content-Type: text/html; charset="us-ascii"

WGLC for "other certs"
I-D

I am initiating a WGLC on draft-ietf-pkix-other-certs-03.

The last call will end in two weeks, on May 20th.

Steve

--============_-970499934==_ma============--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46F7bQk050210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 May 2009 08:07:37 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n46F7bKC050209; Wed, 6 May 2009 08:07:37 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46F7OEl050193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 May 2009 08:07:35 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1M1iiR-000658-BB; Wed, 06 May 2009 11:07:23 -0400
Mime-Version: 1.0
Message-Id:
In-Reply-To: <083E6F4250454F64A340AC3B2BF8A484@ERA1>
References: <083E6F4250454F64A340AC3B2BF8A484@ERA1>
Date: Wed, 6 May 2009 11:07:20 -0400
To: "Erik Andersen"
From: Stephen Kent
Subject: RE: Signing of OCSP responses
Cc: "'PKIX'"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Erik,

A more common OCSP scenario is one in which the RPs acquire certs for
OCSSP servers via an out-of-band means, e.g., via configuration.
These RPs are administratively directed to rely on the responses from
these servers.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46Dh8iV042446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 May 2009 06:43:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n46Dh8rF042445; Wed, 6 May 2009 06:43:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46Dgvep042433 for ; Wed, 6 May 2009 06:43:07 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 1AA489A472F; Wed, 6 May 2009 09:43:15 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id oedqze7TzeJJ; Wed, 6 May 2009 09:42:56 -0400 (EDT)
Received: from THINKPADR52.vigilsec.com (dhcp-26-110.ripemtg.ripe.net [193.0.26.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id DE3759A4726; Wed, 6 May 2009 09:43:12 -0400 (EDT)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 06 May 2009 09:42:07 -0400
To: Stefan Santesson
From: Russ Housley
Subject: Re: WGLC for draft-ietf-pkix-ta-format-02
Cc: [email-masked]
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Remember how we got here!  The TAMP document included a trust anchor
format, and it was suggested that the format be extracted so that other
protocols might be able to take advantage of them.  These fields
seem to be related to a protocol environment.  I do not think they
should be included in the draft-ietf-pkix-ta-format document.

Russ

At 09:12 AM 5/5/2009, Stefan Santesson wrote:

The TSL
file has some overall data for the whole list such as:

Version identifier

Issuer

issue date and time

Next update

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46ABLnK023121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 May 2009 03:11:21 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n46ABLuN023120; Wed, 6 May 2009 03:11:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n46ABIfC023104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 May 2009 03:11:19 -0700 (MST) (envelope-from [email-masked])
Received: from ERA1 ([212.27.18.153]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id NPR75511 for ; Wed, 06 May 2009 12:11:11 +0200
From: "Erik Andersen"
To: "'PKIX'"
Subject: RE: Signing of OCSP responses
Date: Wed, 6 May 2009 12:11:07 +0200
Message-ID: <083E6F4250454F64A340AC3B2BF8A484@ERA1>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C9CE43.BFB216E0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6838
In-Reply-To:
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AcnOIh0sqUsb1/tqTZyYo8LTSLv7bAADY2dgAACuqhA=
Importance: Normal
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C9CE43.BFB216E0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Liaquat,

Thanks for your reply. It appears to me that RFC 2560 is not always that
precise. In addition, it refers to obsolete RFCs.

Erik Andersen

Andersen's L-Service

Elsevej 48, DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

email: [email-masked]

www.x500.eu

www.x500standard.com

-----Original Message-----
From: Liaquat Khan [mailto:[email-masked]]
Sent: 6. maj 2009 11:53
To: 'Erik Andersen'; 'PKIX'
Subject: RE: Signing of OCSP responses

Hi Erik

This question comes up now and then (assuming I understand you correctly).
One way to manage this is for the OCSP responder public key to be certified
by each of the CA's for which it responds. Then the OCSP responder should
return all the responder certificates issued by the CAs for which it is
responding in that particular response.

Regards,

Liaquat

_____

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erik Andersen
Sent: 06 May 2009 12:10
To: PKIX
Subject: Signing of OCSP responses

Hi,

I have a question that may disclose my ignorance, but I will try anyway.

The ASN.1 indicates and so does the text of 4.2.1 that ResponseData is
signed. The ResponseData includes the status for all certificates for which
status information is requested. It is also my understanding that these
certificates may have different issuing CAs.

However, 4.2.2.2 makes one believe that the status information for
certificates are individually signed.

Erik Andersen

Andersen's L-Service

Elsevej 48, DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

email: [email-masked]

www.x500.eu

www.x500standard.com

------=_NextPart_000_000E_01C9CE43.BFB216E0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Liaquat,

Thanks for your =
reply. It
appears to me that RFC 2560 is not always that precise. In addition, it =
refers
to obsolete RFCs.

Erik Andersen

Andersen's =
L-Service

Elsevej 48, DK-3500 =
Vaerloese

Denmark

Mobile: +45 2097 =
1490

email: =
[email-masked]

www.x500.eu

www.x500standard.com

-----Original
Message-----

From: Liaquat Khan
[mailto:[email-masked]]

Sent: 6. maj 2009 =
11:53

To: 'Erik Andersen'; =
'PKIX'

Subject: RE: Signing of =
OCSP
responses

Hi Erik

This question comes up now and then (assuming I understand =
you
correctly).  One way to manage this is for the OCSP responder =
public key
to be certified by each of the CA’s for which it responds. =
Then the
OCSP responder should return all the responder certificates issued by =
the CAs
for which it is responding in that particular response. =

Regards,

Liaquat

From:
[email-masked] [mailto:[email-masked]] =
On Behalf Of Erik Andersen

Sent: 06
May 2009 12:10

To: PKIX

Subject: Signing of OCSP =
responses

Hi,

I have a =
question that
may disclose my ignorance, but I will try anyway.

The ASN.1 =
indicates and
so does the text of 4.2.1 that ResponseData is signed. The ResponseData
includes the status for all certificates for which status information is
requested. It is also my understanding that these certificates may have
different issuing CAs.

However, =
4.2.2.2 makes
one believe that the status information for certificates are =
individually
signed.

Erik =
Andersen

Andersen's =
L-Service

Elsevej 48, =
DK-3500
Vaerloese

Denmark

Mobile:
+45 2097 1490

email: =
[email-masked]

www.x500.eu

www.x500standard.com<=
/font>

------=_NextPart_000_000E_01C9CE43.BFB216E0--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n469rkA8021592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 May 2009 02:53:46 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n469rkWV021591; Wed, 6 May 2009 02:53:46 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ascertia.com (server5852.dedicated.webfusion.co.uk [81.21.74.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n469rZM3021577 for ; Wed, 6 May 2009 02:53:45 -0700 (MST) (envelope-from [email-masked])
Received: from ASCUK001 ([87.201.190.183]) by ds5852.dedicated.turbodns.co.uk with MailEnable ESMTP; Wed, 06 May 2009 10:54:41 +0100
From: "Liaquat Khan"
To: "'Erik Andersen'" , "'PKIX'"
References:
Subject: RE: Signing of OCSP responses
Date: Wed, 6 May 2009 13:53:03 +0400
Message-ID:
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C9CE51.FAA94580"
X-Mailer: Microsoft Office Outlook 11
In-Reply-To:
Thread-Index: AcnOIh0sqUsb1/tqTZyYo8LTSLv7bAADY2dg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-ME-Bayesian: 0.000000
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01C9CE51.FAA94580
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Erik

This question comes up now and then (assuming I understand you correctly).
One way to manage this is for the OCSP responder public key to be certified
by each of the CA's for which it responds. Then the OCSP responder should
return all the responder certificates issued by the CAs for which it is
responding in that particular response.

Regards,

Liaquat

_____

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erik Andersen
Sent: 06 May 2009 12:10
To: PKIX
Subject: Signing of OCSP responses

Hi,

I have a question that may disclose my ignorance, but I will try anyway.

The ASN.1 indicates and so does the text of 4.2.1 that ResponseData is
signed. The ResponseData includes the status for all certificates for which
status information is requested. It is also my understanding that these
certificates may have different issuing CAs.

However, 4.2.2.2 makes one believe that the status information for
certificates are individually signed.

Erik Andersen

Andersen's L-Service

Elsevej 48, DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

email: [email-masked]

www.x500.eu

www.x500standard.com

------=_NextPart_000_002B_01C9CE51.FAA94580
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi =
Erik

This question comes up now and then
(assuming I understand you correctly).  One way to manage this is =
for the
OCSP responder public key to be certified by each of the CA’s for =
which
it responds.  Then the OCSP responder should return all the =
responder certificates
issued by the CAs for which it is responding in that particular =
response.

Regards,

Liaquat =

From:
[email-masked] [mailto:[email-masked]] =
On Behalf Of Erik Andersen

Sent: 06 May 2009 =
12:10

To: PKIX

Subject: Signing of OCSP =
responses

Hi,

I have a question that may disclose my ignorance, but =
I will
try anyway.

The ASN.1 indicates and so does the text of 4.2.1 =
that
ResponseData is signed. The ResponseData includes the status for all
certificates for which status information is requested. It is also my
understanding that these certificates may have different issuing =
CAs.

However, 4.2.2.2 makes one believe that the status
information for certificates are individually signed. =

Erik Andersen

Andersen's L-Service

Elsevej 48, DK-3500 Vaerloese

Denmark

Mobile: +45 2097
1490

email: [email-masked]

www.x500.eu

www.x500standard.com

------=_NextPart_000_002B_01C9CE51.FAA94580--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n468AifP013977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 May 2009 01:10:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n468AiVJ013976; Wed, 6 May 2009 01:10:44 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n468AVno013952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 May 2009 01:10:43 -0700 (MST) (envelope-from [email-masked])
Received: from ERA1 ([212.27.18.153]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id NNQ04729 for ; Wed, 06 May 2009 10:10:29 +0200
From: "Erik Andersen"
To: "PKIX"
Subject: Signing of OCSP responses
Date: Wed, 6 May 2009 10:10:27 +0200
Message-ID:
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C9CE32.E21DCBE0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6838
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AcnOIh0sqUsb1/tqTZyYo8LTSLv7bA==
Importance: Normal
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01C9CE32.E21DCBE0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

I have a question that may disclose my ignorance, but I will try anyway.

The ASN.1 indicates and so does the text of 4.2.1 that ResponseData is
signed. The ResponseData includes the status for all certificates for which
status information is requested. It is also my understanding that these
certificates may have different issuing CAs.

However, 4.2.2.2 makes one believe that the status information for
certificates are individually signed.

Erik Andersen

Andersen's L-Service

Elsevej 48, DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

email: [email-masked]

www.x500.eu

www.x500standard.com

------=_NextPart_000_0004_01C9CE32.E21DCBE0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I have a question that may disclose my =
ignorance, but
I will try anyway.

The ASN.1 indicates and so does the text of =
4.2.1
that ResponseData is signed. The ResponseData includes the status for =
all
certificates for which status information is requested. It is also my
understanding that these certificates may have different issuing =
CAs.

However, 4.2.2.2 makes one believe that the =
status information
for certificates are individually signed.

Erik Andersen

Andersen's L-Service

Elsevej 48, DK-3500 =
Vaerloese

Denmark

Mobile: +45 2097 =
1490

email: [email-masked]

www.x500.eu

www.x500standard.com

------=_NextPart_000_0004_01C9CE32.E21DCBE0--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45HHKiK059232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 10:17:20 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45HHKde059231; Tue, 5 May 2009 10:17:20 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45HGkpw059191 for ; Tue, 5 May 2009 10:17:19 -0700 (MST) (envelope-from [email-masked])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn1.fre.skanova.net (7.3.129) id 49CCDA0D005BECE0; Tue, 5 May 2009 19:16:45 +0200
Message-ID: <416BDDE8F8D5404E8558784D88F0651F@AndersPC>
From: "Anders Rundgren"
To: "Paul Hoffman" , "Russ Housley"
Cc:
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
Date: Tue, 5 May 2009 19:17:26 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

The *motive* is definitely good and worth pursuing.

What's less suitable is the idea of *publishing* an end-user's credential
selection images. I would like to see some samples applied to eID or VISA
certificates.

Anders

----- Original Message -----
From: "Russ Housley"
To: "Paul Hoffman"
Cc:
Sent: Tuesday, May 05, 2009 15:03
Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt

Paul:

We clearly disagree. I still believe that logotypes are needed to
make useful user interfaces. We have not seen logotypes take off in
the marketplece, and I am hoping that the use of a single image
instead of multiple images will remove an impediment.

Russ

At 07:01 PM 4/30/2009, Paul Hoffman wrote:

>At 12:31 AM +0200 5/1/09, Stefan Santesson wrote:
> >On 09-04-30 7:42 PM, "Paul Hoffman" wrote:
> > > - Note that only one person has supported the idea, even
> obliquely, since the
> >> request was posted.
> >>
> >
> >First of all that is a premature assessment. Very little time has passed so
> >far.
>
>That is for the co-chairs to decide. Hopefully, you have recused
>yourself from this decision.
>
> >Secondly you are wrong. This draft is supported also by the editors. That
> >makes it five. Only one person so far has voiced against.
>
>There is a reasonable assumption in the IETF that all the co-authors
>on a draft support it. The question for WG adoption is whether
>*others* support the inclusion in the WG.
>
> > > - Given the extremely thin adoption of RFC 3709, it is
> inappropriate for the
> >> WG to take on a major extension to that RFC.
> >>
> >
> >Thin adoption of RFC 3709 is not a problem at all.
>
>We disagree, strongly.
>
> >One of the problems with
> >just providing logotypes with 3709 is that the solution is incomplete. The
> >certificate image offers a complete solution.
>
>Which implementers have said "oh, if you only included Postscript,
>then we would have done 3709"?
>
> >The problem is important and need a solution. Building on RFC 3709 offers an
> >easy solution.
>
>We disagree, strongly.
>
> > > As an individual submission:
> >>
> >> - This proposes that compliant PKIX validators need to include
> at least one
> >> complex image-display mechanism. These mechanisms have been
> error-prone in
> >> the past, sometimes leading to the execution of arbitrary code on the host
> >> system. Forcing, or even suggesting, this be deployed as part of
> PKIX seems
> >> needlessly dangerous for very little value.
> >>
> >
> >I don't understand the problem.
>
>Clearly.
>
> >We are talking about having the option to
> >display a signed image from a trusted source. As if that would be a lot more
> >dangerous than displaying images in your browser from untrusted sources.
>
>To date, the CAs in the root pile have been trusted to issue
>certificates that reflect a proper binding between an end entity and
>a public key. There was some risk of them creating certificates with
>malicious formatting, but that was considered easy to detect. You
>are now proposing that those hundred of CAs be automatically trusted
>to format the art portions of their certificates correctly. That is
>a very different level of trust.
>
>Even if a CA formats the certificate in a way they think is correct,
>there is a chance that the named party will have given them
>information that will cause the display mechanism to crash and
>possibly execute arbitrary code. That isn't possible today with any
>sensible ASN.1 parser.
>
> > > - The rationale from the introduction of the document for
> showing pictures
> >> instead of words is wrong. If you want to fix the words the user
> sees, fix the
> >> words, don't pretend that a picture it is sorta-kinda based on the current
> >> words but not really will lead to better security.
> >>
> >
> >I don't have to pretend. We have at least 3 image formats that is very well
> >suited to display a mix of text and graphics. The feature achieved is
> >usability more than security. To the extent security can benefit from a more
> >user friendly UI, this is also providing better security.
>
>This does not explain why you don't try to just fix the problems
>that you claim are the base for this extension. No one *needs*
>pictures; they need accurate information about the identified party.
>That can be done in text, yes?
>
> > > - "The previous RFC failed so now we want to extend it to make it more
> > > complicated" just sounds silly for a standard. The fact that it
> has been done
> > > in the IETF before doesn't mean we should make the same mistake again.
> > >
> >
> >Not at all. It is the total opposite. Just adding logotypes didn't make the
> >task to provide a understandable UI easy enough. So we need to make the
> >solution easier and complete.
> >
> >A UI just using RFC 3709 would have to:
> > - Decide where to place the logotypes on the screen relative to the text
> > - Decide how to scale the images relative to each other and to the text
> > - Come up with display text describing the content of each attribute
> > - Decide which naming attributes and other names to display
> > - Figure out how to serve the users language preferences with respect to
> >display text.
> >
> >A UI using the certificate image in this new draft, can instead do the
> >following
> > - Display the certificate Image
> >
> >I would call that easier, not more complicated.
>
>You come from the assumption that logotypes are actually useful, not
>just (to use your terms) "user friendly" and based on "usability
>more than security".
>
> >I would understand your violent disagreement more Paul, if you could offer
> >an alternative solution.
>
>I already did that in the last message, but let me try again. If the
>problem is that the names in certificates are not right, fix them.
>Specify "display text describing the content of each attribute",
>"decide which naming attributes and other names to display", and
>"figure out how to serve the users language preferences with respect
>to display text". None of that takes graphics, much less more
>complicated graphics than has already failed.
>
>--Paul Hoffman, Director
>--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45DVG8P038582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 06:31:16 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45DVG8f038580; Tue, 5 May 2009 06:31:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45DVDXN038571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 May 2009 06:31:15 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 78406 invoked from network); 5 May 2009 13:31:17 -0000
Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 5 May 2009 13:31:17 -0000
Received: (qmail 53014 invoked from network); 5 May 2009 13:31:12 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 May 2009 13:31:12 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Tue, 05 May 2009 15:31:11 +0200
Subject: Re: WGLC for draft-ietf-pkix-ta-format-02
From: Stefan Santesson
To: , ietf-pkix
Message-ID:
Thread-Topic: WGLC for draft-ietf-pkix-ta-format-02
Thread-Index: AcnNhcENllqVC/Gw4kyjVA7rRh8aJg==
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3324382272_35685465"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> 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_3324382272_35685465
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Denis,

The TA-Format document is not just used for TAM. The TA-Format document was
broken out from TAM so that it could serve any environment or model that
need to represent a signed list of TAs.

/Stefan

On 09-05-05 3:26 PM, "Denis Pinkas" wrote:

> Stefan,
> =20
> See my comments in-line.
> =20
>> =20
>> ----- Message re=E7u -----
>> =20
>> De : owner-ietf-pkix
>> =20
>> =C0 : Stefan Santesson,pkix
>> =20
>> Date : 2009-05-05, 15:12:13
>> =20
>> Sujet : Re: WGLC for draft-ietf-pkix-ta-format-02
>> =20
>>=20
>> =20
>> =20
> At the meeting in San Francisco I pointed to the ETSI TSL standard as
> something we at least should take a look at as it partly covers the same =
area
> as the ta-format document.
>=20
> IMO, the ETSI TSL does not cover the same topic, even partly.
> The ETSI TSL is based on a pull model, where TAM is based on a push model=
.
> Their goals are different.
>=20
> (...)
>=20
> Note: I=B9m not proposing this at this time. I just want the PKIX list to
> consider this. My mind is not made up yet.
>=20
> Denis
>=20
> /Stefan
>=20
>=20
> As part of the WGLC I would like the WG to consider adding more overall
> metadata to =20
>=20
>=20
> On 09-05-04 3:58 PM, "Stefan Santesson" wrote:
>=20
> =20
>> The authors of the TA format specification has asked for a WGLC on the
>> current document:
>> http://tools.ietf.org/html/draft-ietf-pkix-ta-format-02
>>=20
>> This last call will run for 2 weeks and ends on Monday, May 18.
>> =20
>=20

--B_3324382272_35685465
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: WGLC for draft-ietf-pkix-ta-format-02

Denis,

The TA-Format document is not just used for TAM. The TA-Format document was=
broken out from TAM so that it could serve any environment or model that ne=
ed to represent a signed list of TAs.

/Stefan

On 09-05-05 3:26 PM, "Denis Pinkas" <[email-masked]> wrote:

Stefan,

See my comments in-line.

-----  Message reçu -----

De  : =
owner-ietf-pkix <mailto :owner-iet=
[email-masked]>

À  =
: Stefan  Santesson,pkix <mailto :s=
[email-masked],[email-masked]> =

Date  : 2009-05-05, 15:12:13

Sujet  : Re: WGLC for draft-ietf-pkix-ta-format-02

At the meeting in San Francisco I pointe=
d to the ETSI TSL standard as something we at least should take a look at as=
it partly covers the same area as the ta-format document.

IMO, the ETSI TSL does not cove=
r the same topic, even partly.

The ETSI TSL is based on a pull model, where TAM is b=
ased on a push model.

Their goals are different.

(...)

Note: I’m not proposing this at this time. I just want the PKIX list =
to consider this. My mind is not made up yet.

Denis

/Stefan

As part of the WGLC I would like the WG to consider adding more overall met=
adata to

On 09-05-04 3:58 PM, "Stefan Santesson" <[email-masked]> wrote:

The authors of the TA format specificatio=
n has asked  for a WGLC on the current document:

http://to=
ols.ietf.org/html/draft-ietf-pkix-ta-format-02

This  last call will run for 2 weeks and ends on Monday, May  18.=

--B_3324382272_35685465--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45DQV0w038139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 06:26:31 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45DQVdC038138; Tue, 5 May 2009 06:26:31 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45DQJVx038112 for ; Tue, 5 May 2009 06:26:30 -0700 (MST) (envelope-from [email-masked])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id 1F7FB183E6; Tue, 5 May 2009 15:24:06 +0200 (CEST)
Received: from FRCLS4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2009050515261850:10592 ; Tue, 5 May 2009 15:26:18 +0200
Reply-To: [email-masked]
From: "Denis Pinkas"
To: "Stefan Santesson", "ietf-pkix"
Subject: Re: WGLC for draft-ietf-pkix-ta-format-02
Date: Tue, 5 May 2009 15:26:17 +0200
Message-Id:
References:
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 05/05/2009 15:26:18, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 05/05/2009 15:26:19, Serialize complete at 05/05/2009 15:26:19
Content-Type: multipart/alternative; boundary="----=_NextPart_09050515261720413524155_002"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

------=_NextPart_09050515261720413524155_002
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Stefan,

See my comments in-line.

----- Message re=E7u -----=20
De : owner-ietf-pkix=20
=C0 : Stefan Santesson,pkix=20
Date : 2009-05-05, 15:12:13
Sujet : Re: WGLC for draft-ietf-pkix-ta-format-02

At the meeting in San Francisco I pointed to the ETSI TSL standard as som=
ething we at least should take a look at as it partly covers the same are=
a as the ta-format document.

IMO, the ETSI TSL does not cover the same topic, even partly.=20
The ETSI TSL is based on a pull model, where TAM is based on a push model=
.
Their goals are different.

(...)

Note: I=92m not proposing this at this time. I just want the PKIX list to=
consider this. My mind is not made up yet.

Denis
/Stefan

As part of the WGLC I would like the WG to consider adding more overall m=
etadata to =20

On 09-05-04 3:58 PM, "Stefan Santesson" wrote:

The authors of the TA format specification has asked for a WGLC on the cu=
rrent document:
http://tools.ietf.org/html/draft-ietf-pkix-ta-format-02

This last call will run for 2 weeks and ends on Monday, May 18.
=20

------=_NextPart_09050515261720413524155_002
Content-Type: text/html;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Stefan,

See my comments in-line.

-----=20
Message re=E7u -----

De=20
: owner-ietf-pkix<=
/A>=20

=C0=20
: Stefan=20
Santesson,pkix

Date=20
: 2009-05-05, 15:12:13

Sujet=20
: Re: WGLC for draft-ietf-pkix-ta-format-02

At the meeting in San Francisco I pointed to th=
e ETSI=20
TSL standard as something we at least should take a look at as it partly =
covers=20
the same area as the ta-format document.

IMO, the ETSI TSL does not cover the same topic, even=20
partly.
The ETSI TSL is based on a =
pull=20
model, where TAM is based on a push model.
Their goals are=20
different.

(...)

Note: I=92m not proposing this at =
this time.=20
I just want the PKIX list to consider this. My mind is not made up=20
yet.

Denis

/Stefan

As part of the WGLC I would =
like the=20
WG to consider adding more overall metadata to

On 09-05=
-04=20
3:58 PM, "Stefan Santesson" <[email-masked]> wrote:

The authors of the TA format specification =
has asked=20
for a WGLC on the current document:
http=
://tools.ietf.org/html/draft-ietf-pkix-ta-format-02

This=20
last call will run for 2 weeks and ends on Monday, May=20
18.

------=_NextPart_09050515261720413524155_002--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45DCSH1036688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 06:12:28 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45DCSV7036687; Tue, 5 May 2009 06:12:28 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45DCFED036654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 May 2009 06:12:27 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 59923 invoked from network); 5 May 2009 13:12:19 -0000
Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 5 May 2009 13:12:19 -0000
Received: (qmail 49013 invoked from network); 5 May 2009 13:12:13 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 May 2009 13:12:13 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Tue, 05 May 2009 15:12:13 +0200
Subject: Re: WGLC for draft-ietf-pkix-ta-format-02
From: Stefan Santesson
To: Stefan Santesson , pkix
Message-ID:
Thread-Topic: WGLC for draft-ietf-pkix-ta-format-02
Thread-Index: AcnMwF/PuoliB31Rc0O6GHXenP4NtgAwrryU
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3324381134_35648566"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> 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_3324381134_35648566
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

At the meeting in San Francisco I pointed to the ETSI TSL standard as
something we at least should take a look at as it partly covers the same
area as the ta-format document.

Both these standards has the capacity to provide a signed list of trust
anchors accompanied by relevant parameters and trust data.
The TLS standards (ETSI 102 231) covers a lot of stuff that is not relevant
for a ta-format standard, but there is one thing we may want to consider.

The TSL file has some overall data for the whole list such as:

* Version identifier
* Issuer=20
* issue date and time
* Next update

This might also be useful data in a TrustAnchorList.
If the TA list represent the =B3current=B2 compiled list of trust anchors for a
system or environment, then it could be useful to know when that list was
issued, and optionally, when a new list will be available.

A version identifier is often a good protocol design feature.
The issuer might be redundant, but could be useful to locate the signer=B9s
certificate.

To some extent this could be overlapped by the CMS wrapper, but there could
be a point carrying the data in the actual TA list if the CMS wrapper is
stripped off after signature verification.

Note: I=B9m not proposing this at this time. I just want the PKIX list to
consider this. My mind is not made up yet.

/Stefan

As part of the WGLC I would like the WG to consider adding more overall
metadata to =20

On 09-05-04 3:58 PM, "Stefan Santesson" wrote:

> The authors of the TA format specification has asked for a WGLC on the cu=
rrent
> document:
> http://tools.ietf.org/html/draft-ietf-pkix-ta-format-02
>=20
> This last call will run for 2 weeks and ends on Monday, May 18.
> =20

--B_3324381134_35648566
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: WGLC for draft-ietf-pkix-ta-format-02

At the meeting in San Francisco I pointed to the ETSI TSL standard as some=
thing we at least should take a look at as it partly covers the same area as=
the ta-format document.

Both these standards has the capacity to provide a signed list of trust anc=
hors accompanied by relevant parameters and trust data.

The TLS standards (ETSI 102 231) covers a lot of stuff that is not relevant=
for a ta-format standard, but there is one thing we may want to consider.

The TSL file has some overall data for the whole list such as:

Version identifier

Issuer

issue date and time

Next update

This might also be useful data in a TrustAnchorList<=
/FONT>.

If the TA list represent the “current” compiled list of trust a=
nchors for a system or environment, then it could be useful to know when tha=
t list was issued, and optionally, when a new list will be available.

A version identifier is often a good protocol design feature.

The issuer might be redundant, but could be useful to locate the signerR=
17;s certificate.

To some extent this could be overlapped by the CMS wrapper, but there could=
be  a point carrying the data in the actual TA list if the CMS wrapper=
is stripped off after signature verification.

Note: I’m not proposing this at this time. I just want the PKIX list =
to consider this. My mind is not made up yet.

/Stefan

As part of the WGLC I would like the WG to consider adding more overall met=
adata to

On 09-05-04 3:58 PM, "Stefan Santesson" <[email-masked]> wrote:

<=
SPAN STYLE=3D'font-size:11pt'>The authors of the TA format specification has a=
sked for a WGLC on the current document:

http://to=
ols.ietf.org/html/draft-ietf-pkix-ta-format-02

This last call will run for 2 weeks and ends on Monday, May 18.

--B_3324381134_35648566--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45D4kLx036138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 06:04:47 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45D4kfY036137; Tue, 5 May 2009 06:04:46 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45D4Z9s036116 for ; Tue, 5 May 2009 06:04:46 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 8CBF39A4780; Tue, 5 May 2009 09:04:52 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id rRwxtS4U1KNY; Tue, 5 May 2009 09:04:34 -0400 (EDT)
Received: from THINKPADR52.vigilsec.com (dhcp-26-110.ripemtg.ripe.net [193.0.26.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E16C19A4725; Tue, 5 May 2009 09:04:50 -0400 (EDT)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 05 May 2009 09:03:17 -0400
To: Paul Hoffman
From: Russ Housley
Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
Cc: [email-masked]
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul:

We clearly disagree. I still believe that logotypes are needed to
make useful user interfaces. We have not seen logotypes take off in
the marketplece, and I am hoping that the use of a single image
instead of multiple images will remove an impediment.

Russ

At 07:01 PM 4/30/2009, Paul Hoffman wrote:

>At 12:31 AM +0200 5/1/09, Stefan Santesson wrote:
> >On 09-04-30 7:42 PM, "Paul Hoffman" wrote:
> > > - Note that only one person has supported the idea, even
> obliquely, since the
> >> request was posted.
> >>
> >
> >First of all that is a premature assessment. Very little time has passed so
> >far.
>
>That is for the co-chairs to decide. Hopefully, you have recused
>yourself from this decision.
>
> >Secondly you are wrong. This draft is supported also by the editors. That
> >makes it five. Only one person so far has voiced against.
>
>There is a reasonable assumption in the IETF that all the co-authors
>on a draft support it. The question for WG adoption is whether
>*others* support the inclusion in the WG.
>
> > > - Given the extremely thin adoption of RFC 3709, it is
> inappropriate for the
> >> WG to take on a major extension to that RFC.
> >>
> >
> >Thin adoption of RFC 3709 is not a problem at all.
>
>We disagree, strongly.
>
> >One of the problems with
> >just providing logotypes with 3709 is that the solution is incomplete. The
> >certificate image offers a complete solution.
>
>Which implementers have said "oh, if you only included Postscript,
>then we would have done 3709"?
>
> >The problem is important and need a solution. Building on RFC 3709 offers an
> >easy solution.
>
>We disagree, strongly.
>
> > > As an individual submission:
> >>
> >> - This proposes that compliant PKIX validators need to include
> at least one
> >> complex image-display mechanism. These mechanisms have been
> error-prone in
> >> the past, sometimes leading to the execution of arbitrary code on the host
> >> system. Forcing, or even suggesting, this be deployed as part of
> PKIX seems
> >> needlessly dangerous for very little value.
> >>
> >
> >I don't understand the problem.
>
>Clearly.
>
> >We are talking about having the option to
> >display a signed image from a trusted source. As if that would be a lot more
> >dangerous than displaying images in your browser from untrusted sources.
>
>To date, the CAs in the root pile have been trusted to issue
>certificates that reflect a proper binding between an end entity and
>a public key. There was some risk of them creating certificates with
>malicious formatting, but that was considered easy to detect. You
>are now proposing that those hundred of CAs be automatically trusted
>to format the art portions of their certificates correctly. That is
>a very different level of trust.
>
>Even if a CA formats the certificate in a way they think is correct,
>there is a chance that the named party will have given them
>information that will cause the display mechanism to crash and
>possibly execute arbitrary code. That isn't possible today with any
>sensible ASN.1 parser.
>
> > > - The rationale from the introduction of the document for
> showing pictures
> >> instead of words is wrong. If you want to fix the words the user
> sees, fix the
> >> words, don't pretend that a picture it is sorta-kinda based on the current
> >> words but not really will lead to better security.
> >>
> >
> >I don't have to pretend. We have at least 3 image formats that is very well
> >suited to display a mix of text and graphics. The feature achieved is
> >usability more than security. To the extent security can benefit from a more
> >user friendly UI, this is also providing better security.
>
>This does not explain why you don't try to just fix the problems
>that you claim are the base for this extension. No one *needs*
>pictures; they need accurate information about the identified party.
>That can be done in text, yes?
>
> > > - "The previous RFC failed so now we want to extend it to make it more
> > > complicated" just sounds silly for a standard. The fact that it
> has been done
> > > in the IETF before doesn't mean we should make the same mistake again.
> > >
> >
> >Not at all. It is the total opposite. Just adding logotypes didn't make the
> >task to provide a understandable UI easy enough. So we need to make the
> >solution easier and complete.
> >
> >A UI just using RFC 3709 would have to:
> > - Decide where to place the logotypes on the screen relative to the text
> > - Decide how to scale the images relative to each other and to the text
> > - Come up with display text describing the content of each attribute
> > - Decide which naming attributes and other names to display
> > - Figure out how to serve the users language preferences with respect to
> >display text.
> >
> >A UI using the certificate image in this new draft, can instead do the
> >following
> > - Display the certificate Image
> >
> >I would call that easier, not more complicated.
>
>You come from the assumption that logotypes are actually useful, not
>just (to use your terms) "user friendly" and based on "usability
>more than security".
>
> >I would understand your violent disagreement more Paul, if you could offer
> >an alternative solution.
>
>I already did that in the last message, but let me try again. If the
>problem is that the names in certificates are not right, fix them.
>Specify "display text describing the content of each attribute",
>"decide which naming attributes and other names to display", and
>"figure out how to serve the users language preferences with respect
>to display text". None of that takes graphics, much less more
>complicated graphics than has already failed.
>
>--Paul Hoffman, Director
>--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44J4TBk069147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 12:04:29 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44J4T5D069146; Mon, 4 May 2009 12:04:29 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44J4GTI069134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 12:04:28 -0700 (MST) (envelope-from [email-masked])
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 n44J3C2G008084; Mon, 4 May 2009 15:03:13 -0400
Message-ID: <[email-masked]>
Date: Mon, 04 May 2009 15:03:12 -0400
From: "David A. Cooper"
User-Agent: Thunderbird 2.0.0.21 (X11/20090330)
MIME-Version: 1.0
To: Stephen Farrell , Sharon Boeyen , Russ Housley , Tim Polk , [email-masked], Stephen Kent , Stefan Santesson , [email-masked], pkix
Subject: Re: [Technical Errata Reported] RFC5280 (1774)
References: <[email-masked]>
In-Reply-To: <[email-masked]>
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: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I believe that this errata should be rejected as the correction already
appears in RFC 5280 as step (1) in Section 6.3.3.

In the proposed errata, the step is labeled (l) but appears before step
(a), which places it as the first step in the loop rather than the final
step in the loop. This step must appear as the final step since the
union cannot be computed until after the interim_reasons_mask is
computed. Successful completion of the algorithm would also require
running through the loop using a new distribution point after the
revocation status had been determined just to update the reasons_mask.

So, while the errata against RFC 3280 correctly noted that a step was
missing, the step was incorrectly placed at the beginning rather than
the end of the loop. RFC 5280 includes the step from the errata at the
correct place in the algorithm.

Dave

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=1774
>
> --------------------------------------
> Type: Technical
> Reported by: Takashi Ito
>
> Section: 6.3
>
> Original Text
> -------------
> For each distribution point (DP) in the certificate CRL distribution
> points extension, for each corresponding CRL in the local CRL cache,
> while ((reasons_mask is not all-reasons) and (cert_status is
> UNREVOKED)) perform the following:
>
> (a) Update the local CRL cache by obtaining a complete CRL, a
> delta CRL, or both, as required:
>
>
> Corrected Text
> --------------
> For each distribution point (DP) in the certificate CRL distribution
> points extension, for each corresponding CRL in the local CRL cache,
> while ((reasons_mask is not all-reasons) and (cert_status is
> UNREVOKED)) perform the following:
>
> (l) Set the reasons_mask state variable to the union of
> its previous value and the value of the interim_reasons_mask
> state variable.
>
> (a) Update the local CRL cache by obtaining a complete CRL, a
> delta CRL, or both, as required:
>
> Notes
> -----
> This was reported in 2002 for RFC 3280, which this document obsoletes. The correction did not make it in to RFC 5280, and therefore applies to RFC 5280 as well.
>
> 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
>
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44IZKxw066892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 11:35:20 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44IZKfE066891; Mon, 4 May 2009 11:35:20 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44IZ7G8066877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 11:35:17 -0700 (MST) (envelope-from [email-masked])
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n44IS3ve010965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 May 2009 11:28:04 -0700 (PDT)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n44IS08N010932; Mon, 4 May 2009 11:28:00 -0700 (PDT)
Date: Mon, 4 May 2009 11:28:00 -0700 (PDT)
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Technical Errata Reported] RFC5280 (1774)
From: RFC Errata System
Cc: [email-masked], [email-masked], [email-masked]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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=1774

--------------------------------------
Type: Technical
Reported by: Takashi Ito

Section: 6.3

Original Text
-------------
For each distribution point (DP) in the certificate CRL distribution
points extension, for each corresponding CRL in the local CRL cache,
while ((reasons_mask is not all-reasons) and (cert_status is
UNREVOKED)) perform the following:

(a) Update the local CRL cache by obtaining a complete CRL, a
delta CRL, or both, as required:

Corrected Text
--------------
For each distribution point (DP) in the certificate CRL distribution
points extension, for each corresponding CRL in the local CRL cache,
while ((reasons_mask is not all-reasons) and (cert_status is
UNREVOKED)) perform the following:

(l) Set the reasons_mask state variable to the union of
its previous value and the value of the interim_reasons_mask
state variable.

(a) Update the local CRL cache by obtaining a complete CRL, a
delta CRL, or both, as required:

Notes
-----
This was reported in 2002 for RFC 3280, which this document obsoletes. The correction did not make it in to RFC 5280, and therefore applies to RFC 5280 as well.

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

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44DwM0m045721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 06:58:22 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44DwL2w045720; Mon, 4 May 2009 06:58:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44DwJDE045706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 06:58:20 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 92814 invoked from network); 4 May 2009 13:58:23 -0000
Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 4 May 2009 13:58:23 -0000
Received: (qmail 47207 invoked from network); 4 May 2009 13:58:18 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 May 2009 13:58:18 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Mon, 04 May 2009 15:58:17 +0200
Subject: WGLC for draft-ietf-pkix-ta-format-02
From: Stefan Santesson
To: pkix
Message-ID:
Thread-Topic: WGLC for draft-ietf-pkix-ta-format-02
Thread-Index: AcnMwF/PuoliB31Rc0O6GHXenP4Ntg==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3324297498_30582366"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> 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_3324297498_30582366
Content-type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit

The authors of the TA format specification has asked for a WGLC on the
current document:
http://tools.ietf.org/html/draft-ietf-pkix-ta-format-02

This last call will run for 2 weeks and ends on Monday, May 18.

--B_3324297498_30582366
Content-type: text/html;
charset="US-ASCII"
Content-transfer-encoding: quoted-printable

WGLC for draft-ietf-pkix-ta-format-02

The authors of the TA format specification has asked for a WGLC on the cur=
rent document:

http://to=
ols.ietf.org/html/draft-ietf-pkix-ta-format-02

This last call will run for 2 weeks and ends on Monday, May 18.

--B_3324297498_30582366--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44DgaJ6044310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 06:42:36 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44Dgam9044308; Mon, 4 May 2009 06:42:36 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44DgPRS044290 for ; Mon, 4 May 2009 06:42:35 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M0yR6-0007Zn-F3; Mon, 04 May 2009 09:42:24 -0400
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Mon, 4 May 2009 09:42:15 -0400
To: "David A. Cooper"
From: Stephen Kent
Subject: Re: WG Last Call on draft-ietf-pkix-tac-03
Cc: ??? , pkix , Stephen Farrell
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 10:27 AM -0400 4/3/09, David A. Cooper wrote:
>I think that Stephen makes a great point. Stephen's point is that in
>many cases it is possible to learn someone's true identity even if
>one is only provided the IP address from which the person was
>communicating. So, it would not matter that the TAC protocol does
>not provide the AI with any identity information.
>
>I also do not agree that the TAC cannot be sent directly from the BI
>to the user. The protocol could be reworked to address Stephen's
>concern. The basic idea for the protocol would be as follows:
>
>step 1: The user creates a certificate request message and encrypts
>it with a session key, which is in turn encrypted using the AI's
>public key.
>
>step 2: The user authenticates to the BI and provides the BI with
>the encrypted certificate request message.
>
>step 3: The BI creates a Token for the user and sends the Token and
>the encrypted certificate request message to the AI over a channel
>that is protected using two-way authenticated TLS.
>
>step 4: The AI decrypts the certificate request message and creates
>the TBSCertificate.
>
>(If it is considered necessary): steps 5 and 6: The AI and the BI
>jointly sign the TBSCertificate using the blinded, split signature
>scheme.
>
>step 7: The AI encrypts the signed certificate (TAC) using the
>session key that was created by the user in step 1 and sends the
>encrypted TAC and the Token to the BI.
>
>step 8: The BI sends the encrypted TAC to the user.
>
>[Note that to maximize privacy, the encrypted certificate request
>message and the encrypted TAC could both be padded to a fixed length
>to ensure that the BI could not learn anything from the lengths of
>these messages.]
>
>I wrote out this protocol fairly quickly, so I may not have gotten
>all of the details correct, but I think the basic idea is correct.
>It seems to retain all of the properties of the current protocol
>while also helping to address the flaw that Stephen identified.

Dave,

The "flaw" that Stehen cited is already addressed in the Security
Considerations text, in a more general context, e.g., the same issue
arises when a user contacts a web site using a TAC. We're not going
to mitigate that concern by changing the TAC model as you suggest
above.

The WG needs to decide if it is worthwhile asking the authors to
re-design the model and the protocols for this (minor) benefit. I for
one am not convinced that the additional work and delay is worthwhile.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44DgaVo044309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 06:42:36 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44Dga1G044307; Mon, 4 May 2009 06:42:36 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44DgOSA044288 for ; Mon, 4 May 2009 06:42:35 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M0yR5-0007Zn-Cv; Mon, 04 May 2009 09:42:23 -0400
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Mon, 4 May 2009 09:31:28 -0400
To: Stephen Farrell
From: Stephen Kent
Subject: Re: WG Last Call on draft-ietf-pkix-tac-03
Cc: IETF-pkix
Content-Type: text/html; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Re: WG Last Call on
draft-ietf-pkix-tac-03

At 2:56 PM +0100 4/2/09, Stephen Farrell wrote:

Stefan Santesson wrote:

> The authors of Traceable Anonymous Certificate

> draft-ietf-pkix-tac-03.txt has requested WGLC.

> http://tools.ietf.org/html/draft-ietf-pkix-tac-03

A couple of comments:

#1: Top of p7:

"To effect issuance of the TAC, the AI interacts with

the BI, over a secure channel, to jointly create the
signature on

the TAC, and sends the signed TAC to the user.

The AI does this without learning the user's real
identity

(either from the user or from the BI)."

If the AI sends the TAC to the user, then it will know some

form of identity for that user, even if that's only an IP

address. (And with the likes of SAVI, that could well be

enough to establish a real
identity.)

We already note in the Security Considerations section that the
anonymity guarantees offered by the TAC model may be undermined by
lower layer protocol info of this sort.

It
also may be possible to determine the identity of a user via
information

carried by lower level protocols, or by other, application-specific
means.

For
example, the IP address of the user might be used to identify
him/her.

So, this is not a new concern and I think it is adequately
addressed by the current Security Considerations text.

I'd have thought it'd be much better to
return the TAC

via the BI and not require any
user<->AI direct connections?

The BI knows the user's true identity, but is not supposed to
know the ID that appears in the Subject field of the TAC (or the rest
of the cert content). So, the BI cannot hand the cert back to the user
in plaintext form.

#2: Section 5.2 claims that the AI can't unilaterally fool

the BI into revealing the real identity. But the only thing

that stops that seems to be the RP client identity verified

by the BI when the RP establishes a mutual-auth TLS connection

to the BI.

So how can the BI really know that its not the AI making
that

connection?

Yes, it is the two-way authenticated TLS connection via which the
identity is revealed that is intended to prevent the AI from
requesting the  user ID unilaterally. There is an assumption
(that we can make explicit) that the cert issued to the RP (typically
a web site) was issued by an independent CA, not affiliated with the
TAC.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44DVJPh043477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 06:31:19 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44DVJts043476; Mon, 4 May 2009 06:31:19 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.208]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44DV7YB043454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 06:31:18 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-ex3.fr.colt.net (smtp-ex3.fr.colt.net [213.41.78.196]) by smtp-ft4.fr.colt.net (8.13.8/8.13.8/Debian-3) with ESMTP id n44DV1TQ007793; Mon, 4 May 2009 15:31:01 +0200
Received: from host.104.92.68.195.rev.coltfrance.com ([195.68.92.104] helo=[172.30.24.37]) by smtp-ex3.fr.colt.net with esmtp (Exim) (envelope-from ) id 1M0yG5-0006PR-1M; Mon, 04 May 2009 15:31:03 +0200
Message-ID: <[email-masked]>
Date: Mon, 04 May 2009 15:30:43 +0200
From: Jean-Marc Desperrier
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090501 SeaMonkey/2.0b1pre
MIME-Version: 1.0
To: Stefan Santesson
CC: pkix
Subject: Re: WG Last Call on draft-ietf-pkix-tac-03
References:
In-Reply-To:
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-ACL-Warn: 2/2 recipients OK.
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stefan Santesson wrote:
> *) The term “Anonymous Issuer”.
> *I believe that I proposed this term to be changed to “Anonymity Issuer”
> and that this proposal was accepted. “Anonymous Issuer” may fool the
> reader to believe that the issuer is anonymous which is not the case.

Both sound a bit strange to me.

Wouldn't "Anonymising Issuer" be the term that's already in usage in
similar scheme ?

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44BkmaF035978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 04:46:48 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n44BkmEH035977; Mon, 4 May 2009 04:46:48 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n44BkS91035954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 04:46:45 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 12483 invoked from network); 4 May 2009 11:46:31 -0000
Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 4 May 2009 11:46:31 -0000
Received: (qmail 17888 invoked from network); 4 May 2009 11:46:26 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 May 2009 11:46:26 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Mon, 04 May 2009 13:46:25 +0200
Subject: Re: WG Last Call on draft-ietf-pkix-tac-03
From: Stefan Santesson
To: "David A. Cooper" , ??? , pkix , Stephen Farrell
Message-ID:
Thread-Topic: WG Last Call on draft-ietf-pkix-tac-03
Thread-Index: AcnMrfPk9vFJDCfoOU+tNpdm9rQSLA==
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3324289586_30127135"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> 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_3324289586_30127135
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Before closing this WGLC.

I have not seen any reply to David Copper=B9s comment as part of this WGLC.
I think this model is a valid alternative.

Does the authors intend to make a response?

I would also like to add the following comments:

1) The term =B3Anonymous Issuer=B2.
I believe that I proposed this term to be changed to =B3Anonymity Issuer=B2 and
that this proposal was accepted. =B3Anonymous Issuer=B2 may fool the reader to
believe that the issuer is anonymous which is not the case.

2) Short version flow description
This is just a suggestion to the authors to increase the readability of the
document.
I would suggest that the document was rearranged slightly to first provide =
a
short description if the certificate issuance and name recovery flows
without any juicy technical details. Then I would provide the technical
details of each step in a following section. This would make it a lot easie=
r
and faster to understand the basic architecture.

3) Nit from section 5.1 step 4
The following text is a bit confusing
"Token is the value of the certificate request"

A reader may misunderstand this to mean that the certificate request IS the
token.
The token is carried in the certificate request, which is slightly
different.

4) Conceptual question
I have another conceptual question.

Wouldn=B9t it be possible to achieve the same anonymity assurance without
doing the blind signature (step 4-5).
This is also the question using Stephen=B9s and David=B9s altered model.

The AI already knows that the request is genuine because the user provides =
a
valid token.=20
The AI can now issue an anonymous certificate that is unknown to BI. In cas=
e
of problems, AI releases the token that can be sent to BI for identificatio=
n
of the user.

What extra level of assurance for anonymity is given to the user by the
threshold signature scheme?

I can see that it prevents AI from issuing certificates on its own, and thu=
s
is an assurance that there actually exist a BI record that the BI will hono=
r
in case of problems, but if AI was trusted to only issue valid certificates
based on valid tokens, then what is the gain?

The follow up question is: If there as a reasonable mode where this protoco=
l
can be used without deploying the threshold signature scheme, then wouldn=B9t
it be valid to describe that as an optional scenario within which the basic
protocol can be used?

/Stefan

On 09-04-03 4:27 PM, "David A. Cooper" wrote:

> I think that Stephen makes a great point.=A0 Stephen's point is that in man=
y
> cases it is possible to learn someone's true identity even if one is only
> provided the IP address from which the person was communicating.=A0 So, it =
would
> not matter that the TAC protocol does not provide the AI with any identit=
y
> information.
>=20
> I also do not agree that the TAC cannot be sent directly from the BI to t=
he
> user.=A0 The protocol could be reworked to address Stephen's concern.=A0 The =
basic
> idea for the protocol would be as follows:
>=20
> step 1: The user creates a certificate request message and encrypts it wi=
th a
> session key, which is in turn encrypted using the AI's public key.
>=20
> step 2: The user authenticates to the BI and provides the BI with the
> encrypted certificate request message.
>=20
> step 3: The BI creates a Token for the user and sends the Token and the
> encrypted certificate request message to the AI over a channel that is
> protected using two-way authenticated TLS.
>=20
> step 4: The AI decrypts the certificate request message and creates the
> TBSCertificate.
>=20
> (If it is considered necessary): steps 5 and 6:=A0 The AI and the BI jointl=
y
> sign the TBSCertificate using the blinded, split signature scheme.
>=20
> step 7: The AI encrypts the signed certificate (TAC) using the session ke=
y
> that was created by the user in step 1 and sends the encrypted TAC and th=
e
> Token to the BI.
>=20
> step 8: The BI sends the encrypted TAC to the user.
>=20
> [Note that to maximize privacy, the encrypted certificate request message=
and
> the encrypted TAC could both be padded to a fixed length to ensure that t=
he BI
> could not learn anything from the lengths of these messages.]
>=20
> I wrote out this protocol fairly quickly, so I may not have gotten all of=
the
> details correct, but I think the basic idea is correct.=A0 It seems to reta=
in
> all of the properties of the current protocol while also helping to addre=
ss
> the flaw that Stephen identified.
>=20
> Dave
>=20
> SangHwan Park wrote:
>> =20
>> =20
>>=20
>> Dear Stephen,
>> =20
>> =A0
>> =20
>> Thank you for the comments.
>> =20
>> =A0
>> =20
>> I=B9ve included my responses inline below.
>> =20
>> =A0
>> =20
>>> > A couple of comments:
>> =20
>> =A0
>> =20
>>> >#1: Top of p7:
>> =20
>>> >=A0 "To effect issuance of the TAC, the AI interacts with
>> =20
>>> >=A0=A0 the BI, over a secure channel, to jointly create the signature on
>> =20
>>> >=A0=A0 the TAC, and sends the signed TAC to the user.
>> =20
>>> >=A0
>> =20
>>> >=A0=A0 The AI does this without learning the user's real identity
>> =20
>>> >=A0=A0 (either from the user or from the BI)."
>> =20
>>> >=A0
>> =20
>>> >If the AI sends the TAC to the user, then it will know some
>> =20
>>> >form of identity for that user, even if that's only an IP
>> =20
>>> >address. (And with the likes of SAVI, that could well be
>> =20
>>> >enough to establish a real identity.)
>> =20
>>> >=A0
>> =20
>>> >I'd have thought it'd be much better to return the TAC
>> =20
>>> >via the BI and not require any user<->AI direct connections?
>> =20
>> =A0
>> =20
>> According to the concept of separation of CA authorities in this documen=
t, BI
>> only identify user=B9s real identity and AI only issue TAC with the help o=
f BI
>> without disclosing user=B9s real identity. As you suggested if we allow BI=
to
>> send TAC to users not from AI, BI can trace user=B9s real identity
>> unilaterally. It means it is against our concept. And AI can=B9t trace the=
ir
>> real identity with IP address alone, collected in the issuance process
>> because AI does not have any identity information for users. For this re=
ason,
>> it makes sense to require AI to send TAC to users.
>> =20
>> =A0
>> =20
>=20
>=20

--B_3324289586_30127135
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: WG Last Call on draft-ietf-pkix-tac-03

Before closing this WGLC.

I have not seen any reply to David Copper’s comment as part of this W=
GLC.

I think this model is a valid alternative.

Does the authors intend to make a response?

I would also like to add the following comments:

1) The term “Anonymous Issuer”.

I believe that I proposed this term to be changed to “Anonymity I=
ssuer” and that this proposal was accepted. “Anonymous Issuer=
221; may fool the reader to believe that the issuer is anonymous which is no=
t the case.

2) Short version flow description

This is just a suggestion to the authors to increase the readability of=
the document.

I would suggest that the document was rearranged slightly to first provide =
a short description if the certificate issuance and name recovery flows with=
out any juicy technical details. Then I would provide the technical details =
of each step in a following section. This would make it a lot easier and fas=
ter to understand the basic architecture.

3) Nit from section 5.1 step 4

The following text is a bit confusing

"Token is the value of the certificate request"

A reader may misunderstand this to mean that the certificate request IS the=
token.

The token is carried in the certificate request, which is slightly differen=
t.

4) Conceptual question

I have another conceptual question.

Wouldn’t it be possible to achieve the same anonymity assurance witho=
ut doing the blind signature (step 4-5).

This is also the question using Stephen’s and David’s altered m=
odel.

The AI already knows that the request is genuine because the user provides =
a valid token.

The AI can now issue an anonymous certificate that is unknown to BI. In cas=
e of problems, AI releases the token that can be sent to BI for identificati=
on of the user.

What extra level of assurance for anonymity is given to the user by the thr=
eshold signature scheme?

I can see that it prevents AI from issuing certificates on its own, and thu=
s is an assurance that there actually exist a BI record that the BI will hon=
or in case of problems, but if AI was trusted to only issue valid certificat=
es based on valid tokens, then what is the gain?

The follow up question is: If there as a reasonable mode where this protoco=
l can be used without deploying the threshold signature scheme, then wouldn&=
#8217;t it be valid to describe that as an optional scenario within which th=
e basic protocol can be used?

/Stefan

On 09-04-03 4:27 PM, "David A. Cooper" <[email-masked]> wrote:

<=
SPAN STYLE=3D'font-size:11pt'>I think that Stephen makes a great point.=A0 Steph=
en's point is that in many cases it is possible to learn someone's true iden=
tity even if one is only provided the IP address from which the person was c=
ommunicating.=A0 So, it would not matter that the TAC protocol does not provid=
e the AI with any identity information.

I also do not agree that the TAC cannot be sent directly from the BI to the=
user.=A0 The protocol could be reworked to address Stephen's concern.=A0 The ba=
sic idea for the protocol would be as follows:

step 1: The user creates a certificate request message and encrypts it with=
a session key, which is in turn encrypted using the AI's public key.

step 2: The user authenticates to the BI and provides the BI with the encry=
pted certificate request message.

step 3: The BI creates a Token for the user and sends the Token and the enc=
rypted certificate request message to the AI over a channel that is protecte=
d using two-way authenticated TLS.

step 4: The AI decrypts the certificate request message and creates the TBS=
Certificate.

(If it is considered necessary): steps 5 and 6:=A0 The AI and the BI jointly =
sign the TBSCertificate using the blinded, split signature scheme.

step 7: The AI encrypts the signed certificate (TAC) using the session key =
that was created by the user in step 1 and sends the encrypted TAC and the T=
oken to the BI.

step 8: The BI sends the encrypted TAC to the user.

[Note that to maximize privacy, the encrypted certificate request message a=
nd the encrypted TAC could both be padded to a fixed length to ensure that t=
he BI could not learn anything from the lengths of these messages.]

I wrote out this protocol fairly quickly, so I may not have gotten all of t=
he details correct, but I think the basic idea is correct.=A0 It seems to reta=
in all of the properties of the current protocol while also helping to addre=
ss the flaw that Stephen identified.

Dave

SangHwan Park wrote:

<=
SPAN STYLE=3D'font-size:11pt'>

Dear Stephen,

=A0

Thank you for the commen=
ts.

=A0

I’<=
FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">ve included my responses inli=
ne below.

=A0

> A couple of comment=
s:

=A0

>#1: Top of p7:

>=A0 "To effect is=
suance of the TAC, the AI interacts with

>=A0=A0 the BI, over a se=
cure channel, to jointly create the signature on

>=A0=A0 the TAC, and send=
s the signed TAC to the user.

>=A0

>=A0=A0 The AI does this =
without learning the user's real identity

>=A0=A0 (either from the =
user or from the BI)."

>=A0

>If the AI sends the =
TAC to the user, then it will know some

>form of identity for=
that user, even if that's only an IP

>address. (And with t=
he likes of SAVI, that could well be

>enough to establish =
a real identity.)

>=A0

>I'd have thought it'=
d be much better to return the TAC

>via the BI and not r=
equire any user<->AI direct connections?

=A0

Ac=
cording to the concept of separation of CA authorities in this document, BI =
only identify user’s real identity and AI only issue T=
AC with the help of BI without disclosing userR=
17;s real identity. A=
s you suggested if we allow BI to send TAC to users not from AI, BI can trac=
e user’s real identity unilaterally. It means it is against our c=
oncept. And AI can’t trace their real identity with IP address al=
one, collected in the issuance process because AI does not have any identity=
information for users. For this reason, it makes sense to require AI to sen=
d TAC to users.

=A0

=

--B_3324289586_30127135--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n42ELdSJ098313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 May 2009 07:21:39 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n42ELd3g098312; Sat, 2 May 2009 07:21:39 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n42ELS5K098301 for ; Sat, 2 May 2009 07:21:38 -0700 (MST) (envelope-from [email-masked])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) id 49CCDA070054012A; Sat, 2 May 2009 16:21:27 +0200
Message-ID: <1612FCDE5AE54374A868CF5EDF8546B7@AndersPC>
From: "Anders Rundgren"
To: "Stefan Santesson" ,
References:
In-Reply-To:
Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
Date: Sat, 2 May 2009 16:22:00 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stefan,

>Credential selection is not competing with information card. On the contrary
>it would be extremely helpful for the Information Card solution if every
>certificate came with a preset image. It would save users the trouble to
>understand what a particular certificate is before choosing an image for it.

I believe it is rather the opposite; PKI folks should take a closer look
on Information Cards and consider adapting their model. After all,
Information Cards were developed with the consumer in mind.

FWIW, this is at least the path I'm walking with my KeyGen2 effort.
It is true that I'm (currently) alone in this work but OTOH the PKI
community has proved (over and over again...) that it is incapable of
doing anything creative on the client-side of PKI in browsers so it
may indeed be what you in the end actually get due to a lack of
credible alternatives. That the target is the quickly-moving mobile
phone-market rather than the technically and market-wise stagnant
PC-market is also a factor to consider. Here KeyGen2 does a
much better job than any static certificate image scheme could ever
do since the former caters for the entire process, including device
characteristics regarding credential selection images.

Open Source + Economic Downturn + Pretty Good Design is a
lethal combination :-)

Anders

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n42D7wqK094716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 May 2009 06:07:58 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n42D7wMp094715; Sat, 2 May 2009 06:07:58 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n42D7i9X094689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 2 May 2009 06:07:56 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 8124 invoked from network); 2 May 2009 13:07:48 -0000
Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 2 May 2009 13:07:48 -0000
Received: (qmail 46657 invoked from network); 2 May 2009 13:07:42 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 2 May 2009 13:07:42 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Sat, 02 May 2009 15:07:42 +0200
Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
From: Stefan Santesson
To: Anders Rundgren ,
Message-ID:
Thread-Topic: I-D ACTION:draft-santesson-pkix-certimage-00.txt
Thread-Index: AcnLJvn7yvP0SGavLUO/tUMHX8UgAQ==
In-Reply-To:
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Anders,

If one use case is valid for you that is fine with me and even that is a
good reason to proceed.

Others, including me, see all three use cases as valid. I don't recall
explicitly mentioning peer-to-peer support. Signature verification also
exist in business to consumer scenarios. Signed software, udates and
manifests are ne common cases.

Credential selection is not competing with information card. On the contrary
it would be extremely helpful for the Information Card solution if every
certificate came with a preset image. It would save users the trouble to
understand what a particular certificate is before choosing an image for it.

On 09-05-01 10:03 AM, "Anders Rundgren" wrote:

>
> As I wrote in an earlier posting I have nothing against this as an
> PKIX WG item. I would though like to point out some additional
> issues. Effectively the proposed draft as well as RFC3709 support
> three independent use-cases.
>
> 1. Recognition of for example a web-site server-certificate issuer.
> That seems like a good application.
>
> 2. Credential selection. I remain unconvinced that such
> information should be featured in the form of public URLs in
> certificates since the purpose is guiding end-users. Microsoft's
> recently introduced Information Cards provides a "cert-image"
> but this image is never transferred to any other party.
>
> 3. Peer-to-peer RP support. Although it is a nice
> idea standardizing (per CA) the information you send to
> arbitrary contacts it also seems pretty difficult; some people
> apparently feel comfortable publishing their entire life on
> Facebook while other groups of people prefer using
> unintelligible aliases. This part appears to be outside
> of what CAs should be dealing with, with passports as an
> exception. For the latter standards already exist AFAIK.
>
> Regarding #3 I believe this is rather a case for attribute
> certificates (not necessarily in the X.509 flavor), where you
> in a message optionally include URLs to published ACs holding
> additional information about you that is relevant for the relation
> to the specific RP.
>
>
> I would therefore consider dropping use-case 2 and 3 since
> the recognition of web-sites is an issue that affects the entire
> Internet ecosystem, it is good enough alone as a WG item.
>
> Anders
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4182qT0000279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 May 2009 01:02:52 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4182qL9000278; Fri, 1 May 2009 01:02:52 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4182eqX000264 for ; Fri, 1 May 2009 01:02:52 -0700 (MST) (envelope-from [email-masked])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn1.fre.skanova.net (7.3.129) id 49CCDA0D0051F6BA for [email-masked]; Fri, 1 May 2009 10:02:40 +0200
Message-ID:
From: "Anders Rundgren"
To:
References:
In-Reply-To:
Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
Date: Fri, 1 May 2009 10:03:10 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

As I wrote in an earlier posting I have nothing against this as an
PKIX WG item. I would though like to point out some additional
issues. Effectively the proposed draft as well as RFC3709 support
three independent use-cases.

1. Recognition of for example a web-site server-certificate issuer.
That seems like a good application.

2. Credential selection. I remain unconvinced that such
information should be featured in the form of public URLs in
certificates since the purpose is guiding end-users. Microsoft's
recently introduced Information Cards provides a "cert-image"
but this image is never transferred to any other party.

3. Peer-to-peer RP support. Although it is a nice
idea standardizing (per CA) the information you send to
arbitrary contacts it also seems pretty difficult; some people
apparently feel comfortable publishing their entire life on
Facebook while other groups of people prefer using
unintelligible aliases. This part appears to be outside
of what CAs should be dealing with, with passports as an
exception. For the latter standards already exist AFAIK.

Regarding #3 I believe this is rather a case for attribute
certificates (not necessarily in the X.509 flavor), where you
in a message optionally include URLs to published ACs holding
additional information about you that is relevant for the relation
to the specific RP.

I would therefore consider dropping use-case 2 and 3 since
the recognition of web-sites is an issue that affects the entire
Internet ecosystem, it is good enough alone as a WG item.

Anders