From owner-ietf-pkix@mail.imc.org Mon Aug 07 18:06:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GADEY-0003lo-GK
for pkix-archive@lists.ietf.org; Mon, 07 Aug 2006 18:06:02 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GADEX-0000lM-1f
for pkix-archive@lists.ietf.org; Mon, 07 Aug 2006 18:06:02 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77L4XTh053841;
Mon, 7 Aug 2006 14:04:33 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k77L4XqM053838;
Mon, 7 Aug 2006 14:04:33 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from carter-zimmerman.mit.edu ([192.42.249.121])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77L4TcY053804
for ; Mon, 7 Aug 2006 14:04:33 -0700 (MST)
(envelope-from hartmans@mit.edu)
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
id 7D20FE00C0; Mon, 7 Aug 2006 17:04:21 -0400 (EDT)
From: Sam Hartman
To: ietf-pkix@imc.org
Subject: AD review comments for draft-ietf-pkix-scvp-27
Date: Mon, 07 Aug 2006 17:04:21 -0400
Message-ID:
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Hello.
As part of the publication process for draft-ietf-pkix-scvp-27 I have
reviewed the draft as the AD bringing it to the IESG.
I've found a few issues that I believe need to be handled before the
draft can be last called at the IETF level. In many cases
clarifications of text will be sufficient to address these issues.
There are a few concerns about interoperability though.
Section 3: The text does not state a good reason why
anyExtendedKeyUsage is not sufficient for a cert to be used to sign
scvp requests. Please either provide such a reason or require
servers to accept this keyPurposeID. If you believe that some
environments may have a good reason to reject anyExtendedKeyUsage but
others will not, then state that servers SHOULD accept the usage and describe these differences.
> All SCVP clients MUST support SignedData for signed requests and
> responses. SCVP clients SHOULD support AuthenticatedData for MAC
> protected requests and responses.
What are the requirements for servers?
How does a client obtain the server's key agreement public key? The
section 3 text says that the client must do so but does not describe
how. Is a normative mechanism required here? If not, you still need
to describe possible methods.
Section 3.1
The text claims the version must be increased for any change in syntax
or semantics. Do I need to increase the version number when I define
an extension? If not, please note this.
Section 3.2 The ASN.1 tagging for the Query type looks strange. There
is no context tag 0; not all optional fields are tagged. What is the
style being used here?
In 3.2.4.5 and 3.2.4.6, if the server does not support these flags,
must it error if they are set or can it ignore them? The text is
unclear. Later text implies that the server should generate an error
if these features are requested but they are not available; if so,
please clarify this text.
Section 3.2.4.9 does not provide sufficient semantics to meet the
needs of common applications. For example
draft-ietf-cat-kerberos-pk-init requires that pk-init certificates
have the ExtendedKeyUsage extension in some cases. SCVP itself does
not currently permit the anyExtendedKeyUsage value, so SCVP doesn't
even provide good enough extendedKeyUsage handling to validate SCVP
server certificates. At a minimum support is required for cases where
EKU needs to be present and where anyKeyUsage is not acceptable.
Are all clients guaranteed to interoperate with all servers? It seems
there is an incomplete overlap between DPD and DPV and it is not clear
that servers are required to support one of these configurations.
It's not clear that this meets RFC 2026's definition of
interoperability. If so, that needs to be fixed.
Section 4:
> 1. A success response to a request made over a protected transport
> such as TLS. These responses SHOULD NOT be protected by the
> server.
Why is that a should? IT seems useful to protect such responses so
that for example they can be included by relaying scvp servers in
their responses while still preserving authentication. In general,
TLS does not provide data origin authentication to third parties, but
protected responses do.
Section 6.1:
> The syntax and semantics of the vpResponseVersion item are the same
> as cvRequestVersion as described in section 3.1. The
> vpResponseVersion used MUST be the same as the vpRequestVersion
> unless the client has used a value greater than the values the
> server supports. If the client submits a vpRequestVersion greater
> than the version supported by the server, the server MUST return a
> vpResponseVersion using the highest version number the server
> supports as the version number.
Why is the above text necessary? Shouldn't clients use the oldest
vpversion in their request to discover what vpversions the server
supports? The above text is potentially hard to implement because it
assumes that future validation policy requests are backward compatible when parsed by an old parser.
i'm also not convinced that the above text is implementable given the
current ASN.1 syntax with a modern ASN.1 toolchain--one that treats
extra fields in a sequence as an error. You can definitely implement
parsing all the versions you support by trying to parse each version
separately, but I'm not convinced that with such a tool chain you can
implement parsing part of a structure that is newer than you support.
How does a client discover what WantBacks and Checks a server
supports?
MIME
* the change controller for all IETF standards track mime
registrations should be the IESG
There is a required parameter (format) on all the mime types that is
neither documented nor used in the HTTP samples. I suspect this is
not actually desired..
I think vp-request and vp-response are too generic of subtype names;
you can try to convince the ietf-types folks that they should accept
this but I suspect you will run into trouble.
From owner-ietf-pkix@mail.imc.org Fri Aug 11 04:29:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GBSOB-0002XA-UZ
for pkix-archive@lists.ietf.org; Fri, 11 Aug 2006 04:29:07 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GBSO9-0000bj-G1
for pkix-archive@lists.ietf.org; Fri, 11 Aug 2006 04:29:07 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7B7J84C090424;
Fri, 11 Aug 2006 00:19:08 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7B7J8lm090423;
Fri, 11 Aug 2006 00:19:08 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7B7J6ES090407
for ; Fri, 11 Aug 2006 00:19:07 -0700 (MST)
(envelope-from hoytkesterson@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=dk20050327; d=earthlink.net;
b=J8VRPHD3nDveHpC0ZsT+9bTs/5OQgGTnT8pVHTpumucbIwo/IJgVWPY+zXEBqXdH;
h=Received:Mime-Version:Message-Id:Date:To:From:Subject:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [130.13.81.129] (helo=[192.168.0.4])
by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34)
id 1GBRHl-0001Gq-5v; Fri, 11 Aug 2006 03:18:25 -0400
Mime-Version: 1.0
Message-Id:
Date: Fri, 11 Aug 2006 00:18:13 -0700
To: Recipient List Suppressed:;
From: Hoyt L Kesterson II
Subject: The fifth edition of ITU-T X.509 / ISO/IEC 9594:2005
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47871f28e14d885ed8ced6d9a1e5188aabb716ab06a37b9c70b350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 130.13.81.129
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
The fifth edition of ITU-T X.509 / ISO/IEC 9594:2005 has been
published. It is available electronically and will soon be available
as hard copy.
As before, ITU-T allows the downloading of three documents at no
charge. The procedures have changed since I last described this
service. Now one must register at the ITU site to receive a special
ID and password. This is described at
http://www.itu.int/publications/template.aspx?media=download&target=/publications/EBookshop.html
or go to the ITU-T main page at http://www.itu.int/home/index.html
and follow the link to "Electronic Bookshop"
Once you have your special ID and password, download the August 2005
(08/05) edition from
http://www.itu.int/rec/T-REC-X.509/en
For languages other than English, one will follow a different path.
Note that this is a copyrighted document. One should not further
distribute the document. Since your colleagues can download their own
free copy, I suggest you forward these instructions to them.
Once registered, you are permitted to download three free documents.
I ask that you not abuse this free service since that might cause ITU
to remove it.
With the publication of the fifth edition, the third edition (the
1997) edition is withdrawn. This means that only the fourth and fifth
editions will be supported, i.e. defect resolution.
My thanks to all of you out there who contributed to this work.
hoyt
From owner-ietf-pkix@mail.imc.org Tue Aug 15 06:11:40 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GCvtc-0007Io-JM
for pkix-archive@lists.ietf.org; Tue, 15 Aug 2006 06:11:40 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GCvta-0001FY-4s
for pkix-archive@lists.ietf.org; Tue, 15 Aug 2006 06:11:40 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7F90V06086723;
Tue, 15 Aug 2006 02:00:31 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7F90V8l086721;
Tue, 15 Aug 2006 02:00:31 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from b.mx.secunet.com (b.mx.secunet.com [213.68.205.162])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7F90S33086678
for ; Tue, 15 Aug 2006 02:00:31 -0700 (MST)
(envelope-from Johannes.Merkle@secunet.com)
Received: from localhost (localhost [127.0.0.1])
by b.mx.secunet.com (Postfix) with ESMTP id 310DF186E;
Tue, 15 Aug 2006 10:59:26 +0200 (CEST)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200])
by b.mx.secunet.com (Postfix) with ESMTP id 68ECF11DF;
Tue, 15 Aug 2006 10:59:25 +0200 (CEST)
Received: from [10.208.1.212] ([10.208.1.212]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 15 Aug 2006 11:00:16 +0200
Message-ID: <44E18D1F.5090201@secunet.com>
Date: Tue, 15 Aug 2006 11:00:15 +0200
From: Johannes Merkle
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: New contribution specifying ECC domain parameters
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Aug 2006 09:00:16.0439 (UTC) FILETIME=[39F8CC70:01C6C049]
X-Virus-Scanned: by secunet
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
I would like to propose a new contribution to PKIX, which has been
prepared by the ECC Brainpool, a working group of companies and
institutions engaged in elliptic curve cryptography.
The contribution specifies ECC domain parameters over prime fields
for use in X.509 conforming PKIs. It can be downloaded here
http://www.ecc-brainpool.org/download/draft_pkix_additional_ecc_dp.txt
We are aware that the domain parameters recommended by ANSI X9.62
are already widely employed. The specification of additional
parameters is motivated by the following facts:
1. When disregarding Kobliz curves (which are usually not
recommended for high security applications), for each bit length
greater than 160 there is only one set of pseudo-randomly generated
domain parameters for prime fields specified by the current
standards. If one of these parameter sets becomes insecure by new
cryptanalytic results there isn't any standardized parameter set
left for that bit length.
2. Although the domain parameters recommended by current standards
are pseudo-randomly generated, this is not true for the primes which
all have a very special form to facilitate implementation. Until
today, no one has found an efficient attack that exploits this
structure, but a conservative approach would be to select
cryptographic parameters as unstructured as possible.
3. Current standards do not motivate the selection of the seeds.
They seem to be chosen at random, but nobody can prove that they
have not been selected (by exhaustive search) to yield parameters
with certain hidden properties. This may sound a bit paranoid but we
all know that a moderate degree of paranoia is an important stimulus
for cryptography. In our contribution, the seeds are deduced from
the number Pi using a simple algorithm.
4. Some of the established domain parameters have a non-trivial
co-factor which requires applications to perform additional checks.
Further differences to the domain parameter specifications of X9.62 are:
5. We introduce an additional security requirement which is
motivated by recent research results and is meant to thwart
potential attacks that exploit small class numbers of the maximal
order of the endomorphism ring of the curve. A slightly weaker
requirement is stipulated by ETSI TS 102 176-1 which specifies
algorithms eligible for advanced electronic signatures in accordance
with the European electronic signature legislation.
6. X9.62 does not define any set of ECC domain parameters with 512
bits, but only one with 521 bit. Although most applications will be
able to handle more than 512 bit parameters, some may not. We
propose a parameter set with "natural" length of 512 bit.
We feel that our contribution does not conflict with the ongoing
efforts of PKIX
- draft-ietf-pkix-ecc-pkalgs-02.txt
- draft-ietf-pkix-sha2-dsa-ecdsa-00.txt
but rather complements them. It does not define any new ASN.1 syntax
but recommends complying with draft-ietf-pkix-ecc-pkalgs-02.txt.
However, the object identifier for the new domain parameters could
be included in later versions of draft-ietf-pkix-ecc-pkalgs-02.txt.
Kind regards,
Johannes Merkle
From owner-ietf-pkix@mail.imc.org Wed Aug 16 14:58:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GDQbR-0006WJ-0W
for pkix-archive@lists.ietf.org; Wed, 16 Aug 2006 14:58:57 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GDQbP-0001Lb-FJ
for pkix-archive@lists.ietf.org; Wed, 16 Aug 2006 14:58:56 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7GHSDt6010228;
Wed, 16 Aug 2006 10:28:13 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7GHSDX4010227;
Wed, 16 Aug 2006 10:28:13 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7GHS96Z010216
for ; Wed, 16 Aug 2006 10:28:12 -0700 (MST)
(envelope-from hoytkesterson@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=dk20050327; d=earthlink.net;
b=AwylIZEwdNjhcUaLGHRiorKLy2HrsyiwdbvgRv1gB4qyqe3u6OlRlgNwcTBIIhvV;
h=Received:Mime-Version:Message-Id:Date:To:From:Subject:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [130.13.81.129] (helo=[192.168.0.4])
by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34)
id 1GDPBY-0003Aj-6h
for ietf-pkix@imc.org; Wed, 16 Aug 2006 13:28:08 -0400
Mime-Version: 1.0
Message-Id:
Date: Wed, 16 Aug 2006 10:27:49 -0700
To: ietf-pkix@imc.org
From: Hoyt L Kesterson II
Subject: The fifth edition of ITU-T X.509 / ISO/IEC 9594:2005
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47871f28e14d885ed8c0f7aa7d6fcfe6ac2b01af78322fd8cec350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 130.13.81.129
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
I sent this once before but never saw it come back from the list.
The fifth edition of ITU-T X.509 / ISO/IEC 9594:2005 has been
published. It is available electronically and will soon be available
as hard copy.
As before, ITU-T allows the downloading of three documents at no
charge. The procedures have changed since I last described this
service. Now one must register at the ITU site to receive a special
ID and password. This is described at
http://www.itu.int/publications/template.aspx?media=download&target=/publications/EBookshop.html
or go to the ITU-T main page at http://www.itu.int/home/index.html
and follow the link to "Electronic Bookshop"
Once you have your special ID and password, download the August 2005
(08/05) edition from
http://www.itu.int/rec/T-REC-X.509/en
For languages other than English, one will follow a different path.
Note that this is a copyrighted document. One should not further
distribute the document. Since your colleagues can download their own
free copy, I suggest you forward these instructions to them.
Once registered, you are permitted to download three free documents.
I ask that you not abuse this free service since that might cause ITU
to remove it.
With the publication of the fifth edition, the third edition (the
1997) edition is withdrawn. This means that only the fourth and fifth
editions will be supported, i.e. defect resolution.
My thanks to all of you out there who contributed to this work.
hoyt
From owner-ietf-pkix@mail.imc.org Wed Aug 16 21:50:21 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GDX1Y-0005w7-Vx
for pkix-archive@lists.ietf.org; Wed, 16 Aug 2006 21:50:20 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GDVMw-0001PZ-Ol
for pkix-archive@lists.ietf.org; Wed, 16 Aug 2006 20:04:18 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by chiedprmail1.ietf.org with esmtp (Exim 4.43)
id 1GDV83-0007ki-7u
for pkix-archive@lists.ietf.org; Wed, 16 Aug 2006 19:48:58 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7GMgbDi062453;
Wed, 16 Aug 2006 15:42:37 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7GMgbsl062452;
Wed, 16 Aug 2006 15:42:37 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.204])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7GMgYqL062444
for ; Wed, 16 Aug 2006 15:42:37 -0700 (MST)
(envelope-from openmacnews@gmail.com)
Received: by nz-out-0102.google.com with SMTP id 13so398389nzp
for ; Wed, 16 Aug 2006 15:42:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=beta; d=gmail.com;
h=received:message-id:date:from:reply-to:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding;
b=I/0QQ59Pj4MNifJ9jkH3IDpa2jbTAeqvxcsiIR7vsT2QgNOhiZw1hSUF+FoOPqQ3fYNDglMsKJKC79pXwBLyAzeDkdeeJIZQFIoRw6bKNuHX8CVVZwSz9CO9B10uWrXaXVxzSFGsW0S19ioP9lrShkh9s+flPByc/+k/mXZ2CiI=
Received: by 10.65.114.11 with SMTP id r11mr1443667qbm;
Wed, 16 Aug 2006 15:42:34 -0700 (PDT)
Received: from ?172.30.11.6? ( [70.231.29.225])
by mx.gmail.com with ESMTP id q13sm628283qbq.2006.08.16.15.42.33;
Wed, 16 Aug 2006 15:42:34 -0700 (PDT)
Message-ID: <44E39F58.30309@gmail.com>
Date: Wed, 16 Aug 2006 15:42:32 -0700
From: Richard
Reply-To: openmacnews@gmail.com
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.5) Gecko/20060719 Thunderbird/1.5.0.5 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: stumped by SKID/AKID mistmatch ... advice?
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
hi all,
i'm fairly sure "i'm close", but am currently stymied trying to figure
out a 'mismatch' error. i've googled, read the openssl man, read thru a
bunch of this list (e.g.,
http://www.imc.org/ietf-pkix/old-archive-03/msg01181.html), read the
draft spec (e.g.,
http://www3.ietf.org/proceedings/03nov/I-D/draft-ietf-pkix-certpathbuild-01.txt
(Certification Path Building)), etc etc.
bottom line, no dice.
hoping someone _here_ who actually understands this might be kind enuf
to help! or, at least, point me to a good resource :-)
i've installed:
% openssl version
OpenSSL 0.9.8b 04 May 2006
on OSX 10.4.7.
i've created my "own" CA.
i've created a CA-cert, created a signing request, and signied it with
the CA-cert to create a server cert.
i've organized as:
% setenv my_CERT_DIR "/var/CERTS"
% setenv my_CA_CERT "${my_CERT_DIR}/main.CA.cert.rsa.pem"
% setenv my_SVR_CERT "${my_CERT_DIR}/mail.testdomain.com.cert.rsa.pem"
% setenv my_SVR_KEY "${my_CERT_DIR}/mail.testdomain.com.privkey.rsa.pem"
i've created the usual hash symlinks to trust the CA-cert ...
% sudo -u ssluser ln -sf ${my_CA_CERT} `openssl x509 -hash -noout -in
${my_CA_CERT}`.0
and verifying the CA-cert:
% openssl verify -verbose -issuer_checks -purpose sslserver -CAfile
${my_CA_CERT} ${my_CA_CERT}
/var/CERTS/main.CA.cert.rsa.pem: OK
all's OK.
however, checking the SVR-cert:
% openssl verify -verbose -issuer_checks -purpose sslserver -CAfile
${my_CA_CERT} ${my_SVR_CERT}
reports:
/var/CERTS/mail.testdomain.com.cert.rsa.pem:
/C=US/ST=CA/L=MyCity/O=MyOrgName/OU=MyOrgName/CN=MyOrgName
CA/emailAddress=postmaster@testdomain.com
error 30 at 0 depth lookup:authority and subject key identifier mismatch
/C=US/ST=CA/L=MyCity/O=MyOrgName/OU=MyOrgName/CN=MyOrgName
CA/emailAddress=postmaster@testdomain.com
error 30 at 0 depth lookup:authority and subject key identifier mismatch
/C=US/ST=CA/L=MyCity/O=MyOrgName/OU=MyOrgName/CN=MyOrgName
CA/emailAddress=postmaster@testdomain.com
error 30 at 0 depth lookup:authority and subject key identifier mismatch
OK
huh ???
checking in "openssl.cnf", i've:
===============
...
[ ca ]
default_ca = CA_default
...
[ CA_default ]
...
x509_extensions = usr_cert
policy = policy_match
...
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
...
[ req ]
...
x509_extensions = v3_ca
req_extensions = v3_req
...
[ usr_cert ]
basicConstraints=CA:FALSE
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
...
[ v3_req ]
basicConstraints = CA:FALSE
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
...
[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true
===============
which i *thought* was correct to correctly ensure all identifier matches.
apparently, i'm mistaken :-/
any wisdom/suggestions is much appreciated!
thanks,
richard
- --
/"\
\ / ASCII Ribbon Campaign
X against HTML email, vCards
/ \ & micro$oft attachments
[GPG] OpenMacNews at gmail dot com
fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iEYEAREDAAYFAkTjn1gACgkQlffdvTZxCMbAmgCeOstkAM4TXd8YovLCbg4Ebdu5
Fk0AnielKwcJLL2bsfpZvOPtvMWuqMkz
=+sJR
-----END PGP SIGNATURE-----
From owner-ietf-pkix@mail.imc.org Wed Aug 23 09:48:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GFt5P-0004Sq-WF
for pkix-archive@lists.ietf.org; Wed, 23 Aug 2006 09:48:04 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GFt5O-00066y-JI
for pkix-archive@lists.ietf.org; Wed, 23 Aug 2006 09:48:03 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NCco1v012040;
Wed, 23 Aug 2006 05:38:50 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7NCco5k012039;
Wed, 23 Aug 2006 05:38:50 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mallaury.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NCclqV011998
for ; Wed, 23 Aug 2006 05:38:49 -0700 (MST)
(envelope-from julien.stern@cryptolog.com)
Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81])
by mallaury.nerim.net (Postfix) with ESMTP id 7F69F4F414
for ; Wed, 23 Aug 2006 14:38:37 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
by uranus.cry.pto (Postfix) with ESMTP id 63E794413D
for ; Wed, 23 Aug 2006 14:38:54 +0200 (CEST)
Received: from uranus.cry.pto ([127.0.0.1])
by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 05639-09 for ;
Wed, 23 Aug 2006 14:38:50 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4])
by uranus.cry.pto (Postfix) with SMTP id 625F444006
for ; Wed, 23 Aug 2006 14:38:49 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 23 Aug 2006 14:38:40 +0200
From: "Julien Stern"
Date: Wed, 23 Aug 2006 14:38:40 +0200
To: ietf-pkix@imc.org
Subject: Clarifications on SubjectAltNameExtension handling in RFC3280 / X509
Message-ID: <20060823123839.GE5344@cryptolog.com>
Mail-Followup-To: Julien Stern ,
ietf-pkix@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6+20040907i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Folks,
Sorry to bother if the topic is very familiar to some of you,
but I failed to find definitive answers in the RFCs or in X.509.
I'd be quite interested to have some clarifications regarding
the handling of entity names in RFC3280 (or sonof) and X.509.
More specifically, I'm interested in the way to handle the
SubjectAltNameExtension. This extension allows to give several
alternative names to an entity.
When RFC3280/X509 talk about the "same" entity, does this mean
i) The same certificate
ii) Two certificates with the same SubjectDN
iii) Two certificates with the same SubjectDN and the same
SubjectAltNameExtension
iv) Two certificates with at least one identifier in
SubjectDN/SubjectAltNameExtension that match
v) Something else
Also, do RFC3280 and X.509 really have the same semantic on that matter?
Is RFC3280 putting additional constraints (Trust Anchors?) on the match?
Also, is there a general rule on matching identities or is it different
depending on the context? Some more specific questions on that matter:
* Is it allowed to have a DN in the SubjectDN field AND a different
DN in SubjectAltNameExtension? If so, should we check both for name
equality?
* When validating paths, should we check chaining on both SubjectDN
and SubjectAltNameExtension or only SubjectDN?
* When both SubjectDN are empty, how do we chain certificates?
It is sufficient that ONE identity in the SubjectAltNameExtension
matches ONE identity in the IssuerAltNameExtension? Or should ALL
identities match?
* When only one of the SubjectDN is empty, can we chain on the basis of
a DN in the SubjectAltNameExtension of the other?
* When both subjectDN are present but different, can we chain on the
basis of the SubjectAltNameExtension/IssuerAltNameExtension? Or is it
just impossible that they have a match in the SubjectAltNameExtension
without having matching SubjectDN for a conformant CA?
* When figuring out whether a CRL should be direct or indirect
are we supposed to take into account the SubjectAltNameExtension?
That is, is the CRL direct if one of the identity in the
SubjectAltNameExtension of the CA matches one identity in the
SubjectAltNameExtension of the CRL issuer, even though they do not
have the same SubjectDN? Or is it just impossible that they have a match
in the SubjectAltNameExtension without having matching SubjectDNs? What
if one of the SubjectDN is empty? Or both?
* Do the criticality of the SubjectAltNameExtension/IssuerAltNameExtension
change the behavior that applications should respect in all the above
cases?
Thank you very much for any insight.
--
Julien
From owner-ietf-pkix@mail.imc.org Wed Aug 23 12:28:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GFvb2-000318-53
for pkix-archive@lists.ietf.org; Wed, 23 Aug 2006 12:28:52 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GFvb0-00059w-J6
for pkix-archive@lists.ietf.org; Wed, 23 Aug 2006 12:28:52 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NFNmqt036754;
Wed, 23 Aug 2006 08:23:48 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7NFNm81036753;
Wed, 23 Aug 2006 08:23:48 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NFNk5E036747
for ; Wed, 23 Aug 2006 08:23:47 -0700 (MST)
(envelope-from david.cooper@nist.gov)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93])
by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k7NFNc6W023182;
Wed, 23 Aug 2006 11:23:39 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72])
by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id k7NFNUsH023729;
Wed, 23 Aug 2006 11:23:30 -0400 (EDT)
Message-ID: <44EC7319.7020804@nist.gov>
Date: Wed, 23 Aug 2006 11:24:09 -0400
From: "David A. Cooper"
User-Agent: Thunderbird 1.5.0.5 (X11/20060804)
MIME-Version: 1.0
To: Julien Stern , ietf-pkix@imc.org
Subject: Re: Clarifications on SubjectAltNameExtension handling in RFC3280
/ X509
References: <20060823123839.GE5344@cryptolog.com>
In-Reply-To: <20060823123839.GE5344@cryptolog.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
Julien,
See responses in-line.
Dave
Julien Stern wrote:
> Folks,
>
> Sorry to bother if the topic is very familiar to some of you,
> but I failed to find definitive answers in the RFCs or in X.509.
>
> I'd be quite interested to have some clarifications regarding
> the handling of entity names in RFC3280 (or sonof) and X.509.
>
> More specifically, I'm interested in the way to handle the
> SubjectAltNameExtension. This extension allows to give several
> alternative names to an entity.
>
> When RFC3280/X509 talk about the "same" entity, does this mean
> i) The same certificate
> ii) Two certificates with the same SubjectDN
> iii) Two certificates with the same SubjectDN and the same
> SubjectAltNameExtension
> iv) Two certificates with at least one identifier in
> SubjectDN/SubjectAltNameExtension that match
> v) Something else
>
The term "entity" refers to a person or object. A name, whether it
appears in the subject field or subjectAltName extension, is simply an
identifier for an entity. Here is what X.509 says in clause 8.3.2.1
(Subject alternative name extension):
For every name form used in the GeneralName type, there shall be a
name registration
system that ensures that any name used unambiguously identifies one
entity to both
certificate issuer and certificate users.
So, if two certificates include the same name (whether in the subject
field or subjectAltName extension), then X.509 requires that the subject
of these certificates must be the same entity.
> Also, do RFC3280 and X.509 really have the same semantic on that matter?
> Is RFC3280 putting additional constraints (Trust Anchors?) on the match?
>
There is no difference between RFC 3280 and X.509 on this matter.
3280bis does impose the constraint that a certification path and the
path used to validate a CRL that provides status information for a
certificate in the path begin with the same trust anchor. This rule was
included in 3280bis to protect against the risk that two different
entities might issue certificates and/or CRLs under the same name. This
would be a violation of both 3280bis and X.509, since it would violate
the rule that any name within a PKI unambiguously identity one entity,
but there is no way (other than by vigilance) to ensure that it won't
happen. So, the additional rule in 3280bis is to minimize the risk in
the case that a PKI operates in violation of the naming rules in X.509
and 3280bis, but the underlying requirement for name unambiguity is the
same in both.
> Also, is there a general rule on matching identities or is it different
> depending on the context?
>
I believe that X.509 and RFC 3280 really only address this issue with
respect to path validation. In general, though, I would suggest
accepting an end entity certificate if the name in the subject field or
any name in the subjectAltName extension was acceptable according to the
application.
> Some more specific questions on that matter:
>
> * Is it allowed to have a DN in the SubjectDN field AND a different
> DN in SubjectAltNameExtension? If so, should we check both for name
> equality?
>
A certificate may have a DN in both places. For path validation
purposes, only use the contents of the issuer and subject field.
> * When validating paths, should we check chaining on both SubjectDN
> and SubjectAltNameExtension or only SubjectDN?
>
Only the subject DN.
> * When both SubjectDN are empty, how do we chain certificates?
> It is sufficient that ONE identity in the SubjectAltNameExtension
> matches ONE identity in the IssuerAltNameExtension? Or should ALL
> identities match?
>
Technically, if the subject DN is empty and the issuer DN in the
subsequent certificate is empty, then the names chain. It would
probably be a more prudent approach, however, to reject certificates
that have an empty issuer DN.
> * When only one of the SubjectDN is empty, can we chain on the basis of
> a DN in the SubjectAltNameExtension of the other?
>
No.
> * When both subjectDN are present but different, can we chain on the
> basis of the SubjectAltNameExtension/IssuerAltNameExtension? Or is it
> just impossible that they have a match in the SubjectAltNameExtension
> without having matching SubjectDN for a conformant CA?
>
No. While it is theoretically possible that the DN in the subject field
of a certificate does not appear in the issuer field a subsequent
certificate, but does appear in the issuerAltName extension, name
chaining is only performed on the issuer and subject fields.
> * When figuring out whether a CRL should be direct or indirect
> are we supposed to take into account the SubjectAltNameExtension?
> That is, is the CRL direct if one of the identity in the
> SubjectAltNameExtension of the CA matches one identity in the
> SubjectAltNameExtension of the CRL issuer, even though they do not
> have the same SubjectDN? Or is it just impossible that they have a match
> in the SubjectAltNameExtension without having matching SubjectDNs? What
> if one of the SubjectDN is empty? Or both?
>
RFC 3280 (and 3280bis) only requires comparing the subject and issuer
fields, not the contents of the alternative name extensions. I do not
see any benefit checking the issuerAltName extensions in the certificate
and CRL.
> * Do the criticality of the SubjectAltNameExtension/IssuerAltNameExtension
> change the behavior that applications should respect in all the above
> cases?
>
I don't think so. Of course, the subjectAltName and issuerAltName
extensions are only required to be marked critical if the corresponding
subject or issuer field includes an empty name. Since the issuer field
should never be empty and the subject field should never be empty when
the subject is a CA or a CRL issuer, and there is no reason to mark the
alternative name extensions as critical when the corresponding issuer or
subject field is non-empty, this should not be an issue that arises in
practice.
> Thank you very much for any insight.
>
> --
> Julien
>
>
>
From owner-ietf-pkix@mail.imc.org Wed Aug 23 13:46:49 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GFwoT-0001ii-KI
for pkix-archive@lists.ietf.org; Wed, 23 Aug 2006 13:46:49 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GFwoS-000649-2S
for pkix-archive@lists.ietf.org; Wed, 23 Aug 2006 13:46:49 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NGQHtw044508;
Wed, 23 Aug 2006 09:26:17 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7NGQHjF044507;
Wed, 23 Aug 2006 09:26:17 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NGQDBj044499
for ; Wed, 23 Aug 2006 09:26:16 -0700 (MST)
(envelope-from julien.stern@cryptolog.com)
Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81])
by kraid.nerim.net (Postfix) with ESMTP id 66AEB40E85
for ; Wed, 23 Aug 2006 18:26:11 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
by uranus.cry.pto (Postfix) with ESMTP id 43F204413D
for ; Wed, 23 Aug 2006 18:26:21 +0200 (CEST)
Received: from uranus.cry.pto ([127.0.0.1])
by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 07475-02 for ;
Wed, 23 Aug 2006 18:25:50 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4])
by uranus.cry.pto (Postfix) with SMTP id 7358C44006
for ; Wed, 23 Aug 2006 18:25:49 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 23 Aug 2006 18:25:40 +0200
From: "Julien Stern"
Date: Wed, 23 Aug 2006 18:25:40 +0200
To: ietf-pkix@imc.org
Subject: Re: Clarifications on SubjectAltNameExtension handling in RFC3280 / X509
Message-ID: <20060823162539.GK5344@cryptolog.com>
Mail-Followup-To: Julien Stern ,
ietf-pkix@imc.org
References: <20060823123839.GE5344@cryptolog.com> <44EC7319.7020804@nist.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44EC7319.7020804@nist.gov>
User-Agent: Mutt/1.5.6+20040907i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
David,
many thanks for your prompt and clear replies.
A few more question are in-line.
Regards,
--
Julien
On Wed, Aug 23, 2006 at 11:24:09AM -0400, David A. Cooper wrote:
> Julien,
>
> See responses in-line.
>
> Dave
>
> Julien Stern wrote:
> >Folks,
> >
> >Sorry to bother if the topic is very familiar to some of you,
> >but I failed to find definitive answers in the RFCs or in X.509.
> >
> >I'd be quite interested to have some clarifications regarding
> >the handling of entity names in RFC3280 (or sonof) and X.509.
>
> [snipped crystal clear explanation on entity names]
> >Also, do RFC3280 and X.509 really have the same semantic on that matter?
> >Is RFC3280 putting additional constraints (Trust Anchors?) on the match?
>
> There is no difference between RFC 3280 and X.509 on this matter.
> 3280bis does impose the constraint that a certification path and the
> path used to validate a CRL that provides status information for a
> certificate in the path begin with the same trust anchor. This rule was
> included in 3280bis to protect against the risk that two different
> entities might issue certificates and/or CRLs under the same name. This
> would be a violation of both 3280bis and X.509, since it would violate
> the rule that any name within a PKI unambiguously identity one entity,
> but there is no way (other than by vigilance) to ensure that it won't
> happen. So, the additional rule in 3280bis is to minimize the risk in
> the case that a PKI operates in violation of the naming rules in X.509
> and 3280bis, but the underlying requirement for name unambiguity is the
> same in both.
OK. Found. Point 6.3.3 (f) of 3280bis.
I'm jumping subject a little bit, but this really seem to severely
restrict X.509 on two points:
- Section 8.1.5, last paragraph where it is explicitely mentionned
that an entity can choose to have two different trust anchors for
Certificate and CRL signing
- All the indirect CRL framework (not necessarily as they could
still chain, but likely)
Wouldn't it be better to only ask that they chain up to Trust Anchors
that have the same name instead?
> [snipped questions on chaining]
> >* When figuring out whether a CRL should be direct or indirect
> >are we supposed to take into account the SubjectAltNameExtension?
> >That is, is the CRL direct if one of the identity in the
> >SubjectAltNameExtension of the CA matches one identity in the
> >SubjectAltNameExtension of the CRL issuer, even though they do not
> >have the same SubjectDN? Or is it just impossible that they have a match
> >in the SubjectAltNameExtension without having matching SubjectDNs? What
> >if one of the SubjectDN is empty? Or both?
> >
> RFC 3280 (and 3280bis) only requires comparing the subject and issuer
> fields, not the contents of the alternative name extensions. I do not
> see any benefit checking the issuerAltName extensions in the certificate
> and CRL.
Well, I wondered about this point because of the wording of X.509:
B.5.1.4
If the cRLIssuer field is present in the relative extension (CRL
distribution point or freshest CRL extension) of the certificate, the
CRL shall be signed by the CRL Issuer identified in the CRL distribution
point extension or freshest CRL extension of the certificate and the CRL
shall contain the indirectCRL field in the issuing distribution point
extension.
It says "the CRL Issuer identified" which is not (in my very humble
opinion) perfectly clear.
RFC3280bis says:
6.3.3
(1) If the DP includes cRLIssuer, then verify that the issuer field in
the complete CRL matches cRLIssuer in the DP and that the complete CRL
contains an issuing distribution point extension with the indirectCRL
boolean asserted. Otherwise, verify that the CRL issuer matches the
certificate issuer.
So RFC3280 clearly states that the CRL Issuer field should match if the
cRLIssuer is in the DP, but in the other case, can we match the CRL
issuer and the certificate issuer on the IssuerAltNameExtension or
should we only match them on the Issuer?
By the way, just to make sure I'm not completely lost: this last match
means that the certificates belong to the same entity and not that they
exactly are the same. Right?
> [snipped question on criticality]
To summarize:
1) When we chain, we only consider SubjectDN and IssuerDN. Period.
2) in RFC3280 (and son), a SubjectDN of a non-EE cannot be empty,
therefore, a IssuerDN can never be empty
3) So, The only remaining issue I have is: whenever the RFC says
that we should have a match between two issuers, does this mean that
they should have the same SubjectDN or can/should we also check the
SubjectAltNameExtension ?
Like in these three snippets from 3280bis:
-----
5.2.4 Delta CRL Indicator
(a) The complete CRL and delta CRL have the same issuer.
-----
6.3.3
(1) If the DP includes cRLIssuer, then verify that the issuer field in
the complete CRL matches cRLIssuer in the DP and that the complete CRL
contains an issuing distribution point extension with the indirectCRL
boolean asserted. Otherwise, verify that the CRL issuer matches the
certificate issuer.
-----
6.3.3
(c) If use-deltas is set, verify the issuer and scope of the
delta CRL as follows:
(1) Verify that the delta CRL issuer matches complete CRL
issuer.
From owner-ietf-pkix@mail.imc.org Thu Aug 24 18:35:44 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GGNnc-0004xX-QO
for pkix-archive@lists.ietf.org; Thu, 24 Aug 2006 18:35:44 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GGNnb-00083H-8p
for pkix-archive@lists.ietf.org; Thu, 24 Aug 2006 18:35:44 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7OLK49a041147;
Thu, 24 Aug 2006 14:20:04 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7OLK4OU041146;
Thu, 24 Aug 2006 14:20:04 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7OLK3ks041139
for ; Thu, 24 Aug 2006 14:20:04 -0700 (MST)
(envelope-from david.cooper@nist.gov)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93])
by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k7OLJuSN004341
for ; Thu, 24 Aug 2006 17:19:57 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72])
by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id k7OLJ5H0007021
for ; Thu, 24 Aug 2006 17:19:05 -0400 (EDT)
Message-ID: <44EE17F4.5060403@nist.gov>
Date: Thu, 24 Aug 2006 17:19:48 -0400
From: "David A. Cooper"
User-Agent: Thunderbird 1.5.0.5 (X11/20060817)
MIME-Version: 1.0
To: pkix
Subject: Confusion about encoding of attributes that use the DirectoryString
type
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
All,
It has come to the 3280bis design team's attention that there has been
considerable confusing with respect the the rules in RFC 3280 (and
3280bis) about the choice of string type to use when encoding attributes
of type DirectoryString. The source of the confusion is the syntax used
in Appendix A of RFC 3280 (and 3280bis) to describe attributes that use
the DirectoryString encoding. For example, the common name attribute
appears in Appendix A as:
-- Naming attributes of type X520CommonName
id-at-commonName AttributeType ::= { id-at 3 }
X520CommonName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-common-name)),
printableString PrintableString (SIZE (1..ub-common-name)),
universalString UniversalString (SIZE (1..ub-common-name)),
utf8String UTF8String (SIZE (1..ub-common-name)),
bmpString BMPString (SIZE (1..ub-common-name)) }
The editors of RFC 3280 (and RFC 2459) chose to use this syntax so that
the size constraints could be included in the ASN.1 without the need to
use a parameterized type definition. The X.520 definition of
DirectoryString includes a parameter that can be used to specify the
maximum allowable string length and the definition of each attribute
instantiates that parameter with the maximum allowable string length for
that attribute. Since not all ASN.1 compilers can process parameterized
type definitions, the PKIX profile uses the syntax show above, which has
the same encoding and semantics as the syntax used in X.520 but is
easier for ASN.1 compilers to process.
The problem with the syntax used in Appendix A of RFC 3280 is that the
word "DirectoryString" does not appear. So, many people were unaware
that attributes such as common name used the DirectoryString type and so
did not know that the rules in section 4.1.2.4 for the encoding of
attributes that used the DirectoryString type applied to these attributes.
The 3280bis design team has discussed this issue and agrees that the
ASN.1 in Appendix A should not be changed since using the syntax from
X.520 would result in incompatibility with some ASN.1 compilers.
Instead, the design team recommends adding comments into the ASN.1
module prior to the definition of each attribute that uses the
DirectoryString type that clarifies that the attribute uses the
DirectoryString type. A new paragraph can also be added to Appendix B
(ASN.1 Notes) explaining the situation.
Below is a portion of Appendix A with additional comments added for the
attributes types shown as well as the new paragraph proposed for Appendix B.
-- Naming attributes of type X520name
id-at-name AttributeType ::= { id-at 41 }
id-at-surname AttributeType ::= { id-at 4 }
id-at-givenName AttributeType ::= { id-at 42 }
id-at-initials AttributeType ::= { id-at 43 }
id-at-generationQualifier AttributeType ::= { id-at 44 }
-- Naming attributes of type X520Name:
-- X520name ::= DirectoryString (SIZE (1..ub-name))
--
-- Expanded to avoid parameterized type:
X520name ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-name)),
printableString PrintableString (SIZE (1..ub-name)),
universalString UniversalString (SIZE (1..ub-name)),
utf8String UTF8String (SIZE (1..ub-name)),
bmpString BMPString (SIZE (1..ub-name)) }
-- Naming attributes of type X520CommonName
id-at-commonName AttributeType ::= { id-at 3 }
-- Naming attributes of type X520CommonName:
-- X520CommonName :== DirectoryName (SIZE (1..ub-common-name))
--
-- Expanded to avoid parameterized type:
X520CommonName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-common-name)),
printableString PrintableString (SIZE (1..ub-common-name)),
universalString UniversalString (SIZE (1..ub-common-name)),
utf8String UTF8String (SIZE (1..ub-common-name)),
bmpString BMPString (SIZE (1..ub-common-name)) }
The following paragraph is proposed for inclusion in Appendix B:
For many of the attribute types defined in [X.520], the
AttributeValue uses
the DirectoryString type. Of the attributes specified in Appendix
A, the name,
surname, givenName, initials, generationQualifier, commonName,
localityName,
stateOrProvinceName, organizationName, organizationalUnitName,
title, and
pseudonym attributes all use the DirectoryString type. X.520 uses
a parameterized
type definition [X.683] of DirectoryString to specify the syntax
for each of these
attributes. The parameter is used to indicate the maximum string
length allowed for
the attribute. In Appendix A, in order to avoid the use of
parameterized type
definitions, the DirectoryString type written in its expanded form
for the definition
of each of these attribute types. So, the ASN.1 in Appendix A
describes the syntax
for each of these attributes as being a CHOICE of TeletexString,
PrintableString,
UniversalString, UTF8String, and BMPString, with the appropriate
constraints on
the string length applied to each of types in the CHOICE, rather
than using the
ASN.1 type DirectoryString to describe the syntax.
From owner-ietf-pkix@mail.imc.org Thu Aug 24 18:37:14 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GGNp4-0006Nk-Q2
for pkix-archive@lists.ietf.org; Thu, 24 Aug 2006 18:37:14 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GGNp3-0008SI-DT
for pkix-archive@lists.ietf.org; Thu, 24 Aug 2006 18:37:14 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7OLg1vp042993;
Thu, 24 Aug 2006 14:42:01 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7OLg1AH042992;
Thu, 24 Aug 2006 14:42:01 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7OLg099042983
for ; Thu, 24 Aug 2006 14:42:01 -0700 (MST)
(envelope-from david.cooper@nist.gov)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93])
by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k7OLfv9N015442
for ; Thu, 24 Aug 2006 17:41:57 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72])
by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id k7OLfRJB015352
for ; Thu, 24 Aug 2006 17:41:27 -0400 (EDT)
Message-ID: <44EE1D32.8080608@nist.gov>
Date: Thu, 24 Aug 2006 17:42:10 -0400
From: "David A. Cooper"
User-Agent: Thunderbird 1.5.0.5 (X11/20060817)
MIME-Version: 1.0
To: pkix
Subject: Inconsistencies between RFC 3280 and X.509/X.520
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
All,
In researching the confusion related to RFC 3280's description of the
encoding of attributes that use the DirectoryString type, I encountered
two places in the ASN.1 modules in RFC 3280 (and 3280bis) that are
inconsistent with either X.509 or X.520. (I have not thoroughly
compared these documents, so I cannot guarantee that there are not any
other inconsistencies.)
First, in X.520 the value of ub-name is 64 whereas in RFC 3280 the value
of ub-name is 32768. ub-name is used to specify the maximum length of
the following attributes: name, surname, givenName, initial, and
generationQualifier.
Second, X.509 defines EDIParty as:
EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString {ub-name} OPTIONAL,
partyName [1] DirectoryString {ub-name} }
whereas RFC 3280 defines EDIParty as
EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString OPTIONAL,
partyName [1] DirectoryString }
So, in X.509 there is a size constraint on both the nameAssigner and
partyName strings (they must be between 1 and 64 characters). In RFC
3280, there is no constraint on the length of the strings.
I would like to modify 3280bis so that it is consistent with X.509 and
X.520. However, since the ASN.1 that appears in 3280bis is the same as
the ASN.1 in RFC 3280 and RFC 2459, I want to ensure that changing these
items to be consistent with X.509 and X.520 will not cause any backwards
compatibility issues.
So, I would like to know if changing the ASN.1 in 3280bis would cause
problems for any existing implementations. For example, if there are
systems that use the attributes mentioned above with string lengths that
violate length constraints in X.520.
Thanks,
Dave
From owner-ietf-pkix@mail.imc.org Thu Aug 24 20:05:11 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GGPCA-0006nC-W2
for pkix-archive@lists.ietf.org; Thu, 24 Aug 2006 20:05:10 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GGPC5-0005lQ-Vs
for pkix-archive@lists.ietf.org; Thu, 24 Aug 2006 20:05:10 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7ON0Lqq051889;
Thu, 24 Aug 2006 16:00:21 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7ON0LLl051887;
Thu, 24 Aug 2006 16:00:21 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7ON0KGJ051802
for ; Thu, 24 Aug 2006 16:00:21 -0700 (MST)
(envelope-from chokhani@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C6C7D1.0E098FD0"
Subject: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
Date: Thu, 24 Aug 2006 16:00:09 -0700
Message-ID: <82D5657AE1F54347A734BDD33637C8790449215A@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
Thread-Index: AcbH0QwdbSkSpm4wQjGILp865sH6UA==
From: "Santosh Chokhani"
To:
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.2 (/)
X-Scan-Signature: e06437eb72f6703f11713d345be8298a
This is a multi-part message in MIME format.
------_=_NextPart_001_01C6C7D1.0E098FD0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
All,
=20
The new version of X.509 (2005 Edition) permits initial values other
than infinity and null for permitted and excluded subtrees respectively.
=20
Should we also revise 3280Bis to include these options so that the
relying parties can constrain the trust anchors?
=20
I would consider infinity and null values only for the two respective
fields still compliant with the applicable standard.
=20
Thanks in advance for your opinion.
Santosh Chokhani=20
Orion Security Solutions, Inc.=20
1489 Chain Bridge Road, Suite 300=20
McLean, Virginia 22101=20
(703) 917-0060 Ext. 35 (voice)=20
(703) 917-0260 (Fax)=20
chokhani@orionsec.com=20
Visit our Web site=20
http://www.orionsec.com =20
=20
------_=_NextPart_001_01C6C7D1.0E098FD0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
All,
The
new version of X.509 (2005 Edition) permits initial values other than =
infinity
and null for permitted and excluded subtrees =
respectively.
Should
we also revise 3280Bis to include these options so that the relying =
parties can
constrain the trust anchors?
I
would consider infinity and null values only for the two respective =
fields
still compliant with the applicable =
standard.
Thanks
in advance for your opinion.
Santosh =
Chokhani
Orion
Security Solutions, Inc.
1489 Chain Bridge Road, =
Suite 300
McLean, Virginia
22101
(703)
917-0060 =
Ext. =
35 (voice)
(703)
917-0260
(Fax)
chokhani@orionsec.com =
Visit
our Web site
http://www.orionsec.com
------_=_NextPart_001_01C6C7D1.0E098FD0--
From owner-ietf-pkix@mail.imc.org Thu Aug 24 20:39:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GGPjg-0000XQ-Mo
for pkix-archive@lists.ietf.org; Thu, 24 Aug 2006 20:39:48 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GGPjd-00063r-Vg
for pkix-archive@lists.ietf.org; Thu, 24 Aug 2006 20:39:48 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7ONm7LJ055247;
Thu, 24 Aug 2006 16:48:07 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7ONm7UN055246;
Thu, 24 Aug 2006 16:48:07 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host.eb2bcom.com (eb2bcom.com [72.232.34.10] (may be forged))
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7ONm3cV055228
for ; Thu, 24 Aug 2006 16:48:06 -0700 (MST)
(envelope-from steven.legg@eb2bcom.com)
Received: from [203.206.165.210] (helo=[192.168.1.156])
by host.eb2bcom.com with esmtpa (Exim 4.52)
id 1GGOvV-0001hW-Ki; Fri, 25 Aug 2006 09:47:57 +1000
Message-ID: <44EE3AA9.80708@eb2bcom.com>
Date: Fri, 25 Aug 2006 09:47:53 +1000
From: Steven Legg
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper"
CC: pkix
Subject: Re: Inconsistencies between RFC 3280 and X.509/X.520
References: <44EE1D32.8080608@nist.gov>
In-Reply-To: <44EE1D32.8080608@nist.gov>
Content-Type: text/plain; charset=us-ascii; 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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
David,
The annex of X.520 in which ub-name and the other upper bounds are defined has
always been non-normative. The particular values to which the upper bounds are
set are merely suggestions, and implementations are free to set whatever upper
bounds they like. Thus RFC 3280 is not incorrect in setting ub-name to
something other than 64.
Regards,
Steven
David A. Cooper wrote:
>
> All,
>
> In researching the confusion related to RFC 3280's description of the
> encoding of attributes that use the DirectoryString type, I encountered
> two places in the ASN.1 modules in RFC 3280 (and 3280bis) that are
> inconsistent with either X.509 or X.520. (I have not thoroughly
> compared these documents, so I cannot guarantee that there are not any
> other inconsistencies.)
>
> First, in X.520 the value of ub-name is 64 whereas in RFC 3280 the value
> of ub-name is 32768. ub-name is used to specify the maximum length of
> the following attributes: name, surname, givenName, initial, and
> generationQualifier.
>
> Second, X.509 defines EDIParty as:
>
> EDIPartyName ::= SEQUENCE {
> nameAssigner [0] DirectoryString {ub-name} OPTIONAL,
> partyName [1] DirectoryString {ub-name} }
>
> whereas RFC 3280 defines EDIParty as
>
> EDIPartyName ::= SEQUENCE {
> nameAssigner [0] DirectoryString OPTIONAL,
> partyName [1] DirectoryString }
>
> So, in X.509 there is a size constraint on both the nameAssigner and
> partyName strings (they must be between 1 and 64 characters). In RFC
> 3280, there is no constraint on the length of the strings.
>
> I would like to modify 3280bis so that it is consistent with X.509 and
> X.520. However, since the ASN.1 that appears in 3280bis is the same as
> the ASN.1 in RFC 3280 and RFC 2459, I want to ensure that changing these
> items to be consistent with X.509 and X.520 will not cause any backwards
> compatibility issues.
>
> So, I would like to know if changing the ASN.1 in 3280bis would cause
> problems for any existing implementations. For example, if there are
> systems that use the attributes mentioned above with string lengths that
> violate length constraints in X.520.
>
> Thanks,
>
> Dave
>
>
From owner-ietf-pkix@mail.imc.org Fri Aug 25 20:15:55 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GGlq7-0004m0-4X
for pkix-archive@lists.ietf.org; Fri, 25 Aug 2006 20:15:55 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GGlq5-000529-I9
for pkix-archive@lists.ietf.org; Fri, 25 Aug 2006 20:15:55 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7PNAaiK010935;
Fri, 25 Aug 2006 16:10:36 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7PNAaAL010934;
Fri, 25 Aug 2006 16:10:36 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7PNAY6F010920
for ; Fri, 25 Aug 2006 16:10:35 -0700 (MST)
(envelope-from tgindin@us.ibm.com)
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
by e2.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k7PNASL6026981
for ; Fri, 25 Aug 2006 19:10:28 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7PNASeu227930
for ; Fri, 25 Aug 2006 19:10:28 -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 k7PNAS61026710
for ; Fri, 25 Aug 2006 19:10:28 -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 k7PNARa3026704;
Fri, 25 Aug 2006 19:10:27 -0400
In-Reply-To: <44EE17F4.5060403@nist.gov>
To: "David A. Cooper"
Cc: pkix
MIME-Version: 1.0
Subject: Re: Confusion about encoding of attributes that use the DirectoryString
type
X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006
From: Tom Gindin
Message-ID:
Date: Fri, 25 Aug 2006 19:10:25 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at
08/25/2006 19:10:26,
Serialize complete at 08/25/2006 19:10:26
Content-Type: text/plain; charset="US-ASCII"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
David:
Does it make sense to point out that the DirectoryString rules
apply to all CHOICES containing both TeletexString and BMPString as types?
Both Teletex and BMP appear inside CHOICES which don't contain the other
one, but they only appear together in DirectoryString's AFAIK.
Tom Gindin
"David A. Cooper"
Sent by: owner-ietf-pkix@mail.imc.org
08/24/2006 05:19 PM
To: pkix
cc:
Subject: Confusion about encoding of attributes that use
the DirectoryString type
All,
It has come to the 3280bis design team's attention that there has been
considerable confusing with respect the the rules in RFC 3280 (and
3280bis) about the choice of string type to use when encoding attributes
of type DirectoryString. The source of the confusion is the syntax used
in Appendix A of RFC 3280 (and 3280bis) to describe attributes that use
the DirectoryString encoding. For example, the common name attribute
appears in Appendix A as:
-- Naming attributes of type X520CommonName
id-at-commonName AttributeType ::= { id-at 3 }
X520CommonName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-common-name)),
printableString PrintableString (SIZE (1..ub-common-name)),
universalString UniversalString (SIZE (1..ub-common-name)),
utf8String UTF8String (SIZE (1..ub-common-name)),
bmpString BMPString (SIZE (1..ub-common-name)) }
The editors of RFC 3280 (and RFC 2459) chose to use this syntax so that
the size constraints could be included in the ASN.1 without the need to
use a parameterized type definition. The X.520 definition of
DirectoryString includes a parameter that can be used to specify the
maximum allowable string length and the definition of each attribute
instantiates that parameter with the maximum allowable string length for
that attribute. Since not all ASN.1 compilers can process parameterized
type definitions, the PKIX profile uses the syntax show above, which has
the same encoding and semantics as the syntax used in X.520 but is
easier for ASN.1 compilers to process.
The problem with the syntax used in Appendix A of RFC 3280 is that the
word "DirectoryString" does not appear. So, many people were unaware
that attributes such as common name used the DirectoryString type and so
did not know that the rules in section 4.1.2.4 for the encoding of
attributes that used the DirectoryString type applied to these attributes.
The 3280bis design team has discussed this issue and agrees that the
ASN.1 in Appendix A should not be changed since using the syntax from
X.520 would result in incompatibility with some ASN.1 compilers.
Instead, the design team recommends adding comments into the ASN.1
module prior to the definition of each attribute that uses the
DirectoryString type that clarifies that the attribute uses the
DirectoryString type. A new paragraph can also be added to Appendix B
(ASN.1 Notes) explaining the situation.
Below is a portion of Appendix A with additional comments added for the
attributes types shown as well as the new paragraph proposed for Appendix
B.
-- Naming attributes of type X520name
id-at-name AttributeType ::= { id-at 41 }
id-at-surname AttributeType ::= { id-at 4 }
id-at-givenName AttributeType ::= { id-at 42 }
id-at-initials AttributeType ::= { id-at 43 }
id-at-generationQualifier AttributeType ::= { id-at 44 }
-- Naming attributes of type X520Name:
-- X520name ::= DirectoryString (SIZE (1..ub-name))
--
-- Expanded to avoid parameterized type:
X520name ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-name)),
printableString PrintableString (SIZE (1..ub-name)),
universalString UniversalString (SIZE (1..ub-name)),
utf8String UTF8String (SIZE (1..ub-name)),
bmpString BMPString (SIZE (1..ub-name)) }
-- Naming attributes of type X520CommonName
id-at-commonName AttributeType ::= { id-at 3 }
-- Naming attributes of type X520CommonName:
-- X520CommonName :== DirectoryName (SIZE (1..ub-common-name))
--
-- Expanded to avoid parameterized type:
X520CommonName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-common-name)),
printableString PrintableString (SIZE (1..ub-common-name)),
universalString UniversalString (SIZE (1..ub-common-name)),
utf8String UTF8String (SIZE (1..ub-common-name)),
bmpString BMPString (SIZE (1..ub-common-name)) }
The following paragraph is proposed for inclusion in Appendix B:
For many of the attribute types defined in [X.520], the
AttributeValue uses
the DirectoryString type. Of the attributes specified in Appendix
A, the name,
surname, givenName, initials, generationQualifier, commonName,
localityName,
stateOrProvinceName, organizationName, organizationalUnitName,
title, and
pseudonym attributes all use the DirectoryString type. X.520 uses
a parameterized
type definition [X.683] of DirectoryString to specify the syntax
for each of these
attributes. The parameter is used to indicate the maximum string
length allowed for
the attribute. In Appendix A, in order to avoid the use of
parameterized type
definitions, the DirectoryString type written in its expanded form
for the definition
of each of these attribute types. So, the ASN.1 in Appendix A
describes the syntax
for each of these attributes as being a CHOICE of TeletexString,
PrintableString,
UniversalString, UTF8String, and BMPString, with the appropriate
constraints on
the string length applied to each of types in the CHOICE, rather
than using the
ASN.1 type DirectoryString to describe the syntax.
From owner-ietf-pkix@mail.imc.org Mon Aug 28 23:22:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GHuBN-0001Q3-9U
for pkix-archive@lists.ietf.org; Mon, 28 Aug 2006 23:22:33 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GHuBL-0007i7-UF
for pkix-archive@lists.ietf.org; Mon, 28 Aug 2006 23:22:33 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7T1Ot8s089566;
Mon, 28 Aug 2006 18:24:55 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7T1OtqT089565;
Mon, 28 Aug 2006 18:24:55 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7T1OojX089556
for ; Mon, 28 Aug 2006 18:24:54 -0700 (MST)
(envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 29 Aug 2006 02:24:49 +0100
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"
Subject: Withdrawing 1998 edition of Directory Specification
Date: Tue, 29 Aug 2006 02:24:29 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Withdrawing 1998 edition of Directory Specification
Thread-Index: AcbKycNfSvxgk42yRqS+x7GbgxVxYwAPxmKw
From: "Stefan Santesson"
To:
X-OriginalArrivalTime: 29 Aug 2006 01:24:49.0423 (UTC) FILETIME=[EB9591F0:01C6CB09]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k7T1OsjX089560
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
ISO is planning to withdraw the 1998 version (3rd edition) of the
Directory specification.
This has already been done by ITU and ISO now request input on whether
it would be OK for them to do the same.
With 2005 version available, the two latest versions will be maintained
even though the 1998 version is withdrawn.
Does anyone on this list have any reason to object to this?
Stefan Santesson
Senior Program Manager
Windows Security, Standards
From owner-ietf-pkix@mail.imc.org Thu Aug 31 11:48:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GIomI-0001cd-Bj
for pkix-archive@lists.ietf.org; Thu, 31 Aug 2006 11:48:26 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GIomG-0003dD-Nk
for pkix-archive@lists.ietf.org; Thu, 31 Aug 2006 11:48:26 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VEOast029331;
Thu, 31 Aug 2006 07:24:36 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VEOa19029330;
Thu, 31 Aug 2006 07:24:36 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from sottccs2.entrust.com (sottccs2.entrust.com [216.191.252.16])
by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7VEOYp6029307
for ; Thu, 31 Aug 2006 07:24:35 -0700 (MST)
(envelope-from robert.zuccherato@entrust.com)
Received: (qmail 30740 invoked from network); 31 Aug 2006 14:24:23 -0000
Received: from robert.zuccherato@entrust.com by sottccs2.entrust.com with EntrustECS-Server-8.0;31 Aug 2006 14:24:23 -0000
Received: from sottmxs00.entrust.com (10.4.61.22)
by sottccs2.entrust.com with SMTP; 31 Aug 2006 14:24:23 -0000
Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72)
id ; Thu, 31 Aug 2006 10:24:25 -0400
Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F07F9CD14@sottmxs05.entrust.com>
From: Robert Zuccherato
To: "'Russ Housley'" , ietf-pkix@imc.org
Cc: "'Daniel Brown'"
Subject: RE: Elliptic Curve Cryptography with PKIX
Date: Thu, 31 Aug 2006 10:24:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C6CD09.28D2D066"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0
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.
------_=_NextPart_001_01C6CD09.28D2D066
Content-Type: text/plain
It's been more than a few months now since Russ posted this message and I
haven't seen any further discussion on the topic. As I said back in April,
my preference would be for PKIX to use the AlgorithmIdentifier in the
already approved X9.62 standard, since I don't think it is helpful to have
more than one AlgorithmIdentifier defined.
However, whatever we decide to do, I think that we should resolve the issue
and advance the draft as quickly as possible. Developers of ECC
applications need to know which AlgorithmIdentifier to use.
Does anyone else have any opinions on this topic? When can we hope to see a
new ID?
Robert Zuccherato.
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley
> Sent: May 3, 2006 3:01 PM
> To: ietf-pkix@imc.org
> Subject: RE: Elliptic Curve Cryptography with PKIX
>
>
>
> RFC 3280 does not provide as much guidance as I would like. Section
> 4.1.2.7 says the following about the Subject Public Key Info field:
>
> This field is used to carry the public key and identify
> the algorithm
> with which the key is used (e.g., RSA, DSA, or
> Diffie-Hellman). The
> algorithm is identified using the AlgorithmIdentifier structure
> specified in section 4.1.1.2. The object identifiers for the
> supported algorithms and the methods for encoding the public key
> materials (public key and parameters) are specified in [PKIXALGS].
>
> Section 4.1.1.2 includes these words:
>
> The algorithm identifier is used to identify a cryptographic
> algorithm. The OBJECT IDENTIFIER component identifies
> the algorithm
> (such as DSA with SHA-1). The contents of the optional parameters
> field will vary according to the algorithm identified.
>
> It does not really provide much guidance to developers of
> AlgorithmIdentifiers.
>
> I characterize the X9.62 approach as using the OBJECT IDENTIFIER to
> name a class of elliptic curve algorithms, and then using a portion
> of the parameters to list the members of that class that are
> acceptable for the subject public key.
>
> I am very interested to know how this fits with real implementations.
>
> My suspicion is that implementation that support key agreement are
> used to looking into the parameter to determine if the public key is
> a member of the same group. This is needed for static-static
> Diffie-Hellman (in discrete log or elliptic curve). This is also
> needed for MQV (and KEA, if anyone cares anymore).
>
> My suspicion is that digital signature validation does not anticipate
> constraints in the public key algorithm parameters. An underlying
> crypto routine may need the parameters, but the signature is not
> going to fail because of a constraint in the parameters, which could
> happen in this proposed syntax.
>
> I would greatly appreciate some insight from implementors.
>
> Russ
>
------_=_NextPart_001_01C6CD09.28D2D066
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
RE: Elliptic Curve Cryptography with PKIX
It's been more than a few months now since Russ =
posted this message and I haven't seen any further discussion on the =
topic. As I said back in April, my preference would be for PKIX =
to use the AlgorithmIdentifier in the already approved X9.62 standard, =
since I don't think it is helpful to have more than one =
AlgorithmIdentifier defined.
However, whatever we decide to do, I think that we =
should resolve the issue and advance the draft as quickly as =
possible. Developers of ECC applications need to know which =
AlgorithmIdentifier to use.
Does anyone else have any opinions on this =
topic? When can we hope to see a new ID?
Robert =
Zuccherato.
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
> [mailto:owner-ietf-pkix@mail=
.imc.org] On Behalf Of Russ Housley
> Sent: May 3, 2006 3:01 PM
> To: ietf-pkix@imc.org
> Subject: RE: Elliptic Curve Cryptography with =
PKIX
>
>
>
> RFC 3280 does not provide as much guidance as I =
would like. Section
> 4.1.2.7 says the following about the =
Subject Public Key Info field:
>
> This field is used to =
carry the public key and identify
> the algorithm
> with which the key is =
used (e.g., RSA, DSA, or
> Diffie-Hellman). The
> algorithm is identified =
using the AlgorithmIdentifier structure
> specified in section =
4.1.1.2. The object identifiers for the
> supported algorithms =
and the methods for encoding the public key
> materials (public key =
and parameters) are specified in [PKIXALGS].
>
> Section 4.1.1.2 includes these words:
>
> The algorithm =
identifier is used to identify a cryptographic
> algorithm. The =
OBJECT IDENTIFIER component identifies
> the algorithm
> (such as DSA with =
SHA-1). The contents of the optional parameters
> field will vary =
according to the algorithm identified.
>
> It does not really provide much guidance to =
developers of
> AlgorithmIdentifiers.
>
> I characterize the X9.62 approach as using the =
OBJECT IDENTIFIER to
> name a class of elliptic curve algorithms, and =
then using a portion
> of the parameters to list the members of that =
class that are
> acceptable for the subject public key.
>
> I am very interested to know how this fits with =
real implementations.
>
> My suspicion is that implementation that =
support key agreement are
> used to looking into the parameter to determine =
if the public key is
> a member of the same group. This is =
needed for static-static
> Diffie-Hellman (in discrete log or elliptic =
curve). This is also
> needed for MQV (and KEA, if anyone cares =
anymore).
>
> My suspicion is that digital signature =
validation does not anticipate
> constraints in the public key algorithm =
parameters. An underlying
> crypto routine may need the parameters, but the =
signature is not
> going to fail because of a constraint in the =
parameters, which could
> happen in this proposed syntax.
>
> I would greatly appreciate some insight from =
implementors.
>
> Russ
>
------_=_NextPart_001_01C6CD09.28D2D066--
From owner-ietf-pkix@mail.imc.org Thu Aug 31 11:51:23 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GIop9-0002y5-8I
for pkix-archive@lists.ietf.org; Thu, 31 Aug 2006 11:51:23 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GIop7-00044Y-NR
for pkix-archive@lists.ietf.org; Thu, 31 Aug 2006 11:51:23 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VElwAM033429;
Thu, 31 Aug 2006 07:47:58 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VElwAl033428;
Thu, 31 Aug 2006 07:47:58 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2])
by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7VElreG033414
for ; Thu, 31 Aug 2006 07:47:57 -0700 (MST)
(envelope-from housley@vigilsec.com)
Received: (qmail 16372 invoked by uid 0); 31 Aug 2006 14:47:49 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.235.104)
by woodstock.binhost.com with SMTP; 31 Aug 2006 14:47:49 -0000
Message-Id: <7.0.0.16.2.20060831104558.03e96c18@vigilsec.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Thu, 31 Aug 2006 10:47:41 -0400
To: Robert Zuccherato
From: Russ Housley
Subject: RE: Elliptic Curve Cryptography with PKIX
Cc: "'Daniel Brown'" , ietf-pkix@imc.org
In-Reply-To: <7A3E1242FA9989439AD1F9B2D71C287F07F9CD14@sottmxs05.entrust
.com>
References: <7A3E1242FA9989439AD1F9B2D71C287F07F9CD14@sottmxs05.entrust.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
My opinion has not changed. I believe that we need to follow the
precedent set by RFC 4055.
In my opinion, this situation is a result of the ANSI X9 process not
allowing public review of their draft documents. However, I do not
expect this policy to change.
Russ
At 10:24 AM 8/31/2006, Robert Zuccherato wrote:
It's been more than
a few months now since Russ posted this message and I haven't seen any
further discussion on the topic. As I said back in April, my
preference would be for PKIX to use the AlgorithmIdentifier in the
already approved X9.62 standard, since I don't think it is helpful to
have more than one AlgorithmIdentifier defined.
However, whatever we decide to do, I think that we should
resolve the issue and advance the draft as quickly as possible.
Developers of ECC applications need to know which AlgorithmIdentifier to
use.
Does anyone else have any opinions on this topic? When
can we hope to see a new ID?
Robert
Zuccherato.
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
>
[
mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley
> Sent: May 3, 2006 3:01 PM
> To: ietf-pkix@imc.org
> Subject: RE: Elliptic Curve Cryptography with
PKIX
>
>
>
> RFC 3280 does not provide as much guidance as I would
like. Section
> 4.1.2.7 says the following about the Subject
Public Key Info field:
>
> This field is used to carry the
public key and identify
> the algorithm
> with which the key is used
(e.g., RSA, DSA, or
> Diffie-Hellman). The
> algorithm is identified using
the AlgorithmIdentifier structure
> specified in section
4.1.1.2. The object identifiers for the
> supported algorithms and the
methods for encoding the public key
> materials (public key and
parameters) are specified in [PKIXALGS].
>
> Section 4.1.1.2 includes these words:
>
> The algorithm identifier is
used to identify a cryptographic
> algorithm. The OBJECT
IDENTIFIER component identifies
> the algorithm
> (such as DSA with SHA-1).
The contents of the optional parameters
> field will vary according to
the algorithm identified.
>
> It does not really provide much guidance to developers
of
> AlgorithmIdentifiers.
>
> I characterize the X9.62 approach as using the OBJECT
IDENTIFIER to
> name a class of elliptic curve algorithms, and then
using a portion
> of the parameters to list the members of that class
that are
> acceptable for the subject public key.
>
> I am very interested to know how this fits with real
implementations.
>
> My suspicion is that implementation that support key
agreement are
> used to looking into the parameter to determine if the
public key is
> a member of the same group. This is needed for
static-static
> Diffie-Hellman (in discrete log or elliptic
curve). This is also
> needed for MQV (and KEA, if anyone cares
anymore).
>
> My suspicion is that digital signature validation does
not anticipate
> constraints in the public key algorithm
parameters. An underlying
> crypto routine may need the parameters, but the
signature is not
> going to fail because of a constraint in the
parameters, which could
> happen in this proposed syntax.
>
> I would greatly appreciate some insight from
implementors.
>
> Russ
>
From owner-ietf-pkix@mail.imc.org Thu Aug 31 13:16:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GIq9L-000458-Om
for pkix-archive@lists.ietf.org; Thu, 31 Aug 2006 13:16:19 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GIq9K-0003KK-An
for pkix-archive@lists.ietf.org; Thu, 31 Aug 2006 13:16:19 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGAVRS044863;
Thu, 31 Aug 2006 09:10:31 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VGAVMp044862;
Thu, 31 Aug 2006 09:10:31 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail.ca.certicom.com (nat194.certicom.com [66.48.18.194])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGAQoj044832
for ; Thu, 31 Aug 2006 09:10:30 -0700 (MST)
(envelope-from DBrown@certicom.com)
Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1])
by mail.ca.certicom.com (Postfix) with ESMTP id CF40F100233CF;
Thu, 31 Aug 2006 12:10:20 -0400 (EDT)
Received: from mail.ca.certicom.com ([127.0.0.1])
by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 14727-77; Thu, 31 Aug 2006 12:10:15 -0400 (EDT)
Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24])
by mail.ca.certicom.com (Postfix) with ESMTP id 223601006B06B;
Thu, 31 Aug 2006 12:10:15 -0400 (EDT)
In-Reply-To: <7.0.0.16.2.20060831104558.03e96c18@vigilsec.com>
To: Russ Housley
Cc: ietf-pkix@imc.org, Robert Zuccherato
Subject: RE: Elliptic Curve Cryptography with PKIX
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
Message-ID:
From: Daniel Brown
Date: Thu, 31 Aug 2006 12:09:15 -0400
X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at
08/31/2006 12:09:10 PM,
Serialize complete at 08/31/2006 12:09:10 PM
Content-Type: multipart/alternative; boundary="=_alternative 005928D8852571DB_="
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.5 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
This is a multipart message in MIME format.
--=_alternative 005928D8852571DB_=
Content-Type: text/plain; charset="US-ASCII"
Russ,
The X9.62 syntax follows the precedent set by 4055, in the sense that it
identifies the algorithm for which the public key is to be used in the
subject public key info field.
Section 3.3 of RFC 4055, item 3 in the list, clearly states that an
signature validation implementation MUST check the parameters field of the
subject public key info field algorithm identitifer when validating a
signature, i.e. to see if it conforms used the correct hash, salt size
specified in the cert. This seems to contradict you final paragraph
(copied below).
Dan Brown
(905) 501-3857
http://www.certicom.com
owner-ietf-pkix@mail.imc.org wrote on 08/31/2006 10:47:41 AM:
> My opinion has not changed. I believe that we need to follow the
> precedent set by RFC 4055.
>
> In my opinion, this situation is a result of the ANSI X9 process not
> allowing public review of their draft documents. However, I do not
> expect this policy to change.
>
> Russ
> ...
> >
> > My suspicion is that digital signature validation does not anticipate
> > constraints in the public key algorithm parameters. An underlying
> > crypto routine may need the parameters, but the signature is not
> > going to fail because of a constraint in the parameters, which could
> > happen in this proposed syntax.
> >
--=_alternative 005928D8852571DB_=
Content-Type: text/html; charset="US-ASCII"
Russ,
The X9.62 syntax follows the precedent
set by 4055, in the sense that it identifies the algorithm for which the
public key is to be used in the subject public key info field.
Section 3.3 of RFC 4055, item 3 in the
list, clearly states that an signature validation implementation MUST check
the parameters field of the subject public key info field algorithm identitifer
when validating a signature, i.e. to see if it conforms used the correct
hash, salt size specified in the cert. This seems to contradict you
final paragraph (copied below).
Dan Brown
(905) 501-3857
http://www.certicom.com
owner-ietf-pkix@mail.imc.org wrote on 08/31/2006 10:47:41
AM:
> My opinion has not changed. I believe that we need to follow
the
> precedent set by RFC 4055.
>
> In my opinion, this situation is a result of the ANSI X9 process not
> allowing public review of their draft documents. However, I
do not
> expect this policy to change.
>
> Russ
> ...
> >
> > My suspicion is that digital signature validation does not anticipate
> > constraints in the public key algorithm parameters. An
underlying
> > crypto routine may need the parameters, but the signature is
not
> > going to fail because of a constraint in the parameters, which
could
> > happen in this proposed syntax.
> >
--=_alternative 005928D8852571DB_=--
From owner-ietf-pkix@mail.imc.org Thu Aug 31 13:28:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GIqKi-0008EN-08
for pkix-archive@lists.ietf.org; Thu, 31 Aug 2006 13:28:04 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GIqKf-00044T-J6
for pkix-archive@lists.ietf.org; Thu, 31 Aug 2006 13:28:03 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGb045050143;
Thu, 31 Aug 2006 09:37:00 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VGb0Uw050142;
Thu, 31 Aug 2006 09:37:00 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2])
by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7VGaxZH050129
for ; Thu, 31 Aug 2006 09:36:59 -0700 (MST)
(envelope-from housley@vigilsec.com)
Received: (qmail 17953 invoked by uid 0); 31 Aug 2006 16:36:54 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.235.104)
by woodstock.binhost.com with SMTP; 31 Aug 2006 16:36:54 -0000
Message-Id: <7.0.0.16.2.20060831123401.07871730@vigilsec.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Thu, 31 Aug 2006 12:36:34 -0400
To: ietf-pkix@imc.org
From: Russ Housley
Subject: RE: Elliptic Curve Cryptography with PKIX
In-Reply-To:
References: <7.0.0.16.2.20060831104558.03e96c18@vigilsec.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
So, let's find out. Can developers of software that validates
certificates and digital signatures tell us how the proposed parameter
syntax would impact their code?
Russ
At 12:09 PM 8/31/2006, Daniel Brown wrote:
Russ,
The X9.62 syntax follows the precedent set by 4055, in the
sense that it identifies the algorithm for which the public key is to be
used in the subject public key info field.
Section 3.3 of RFC 4055, item 3 in the list, clearly states
that an signature validation implementation MUST check the parameters
field of the subject public key info field algorithm identitifer when
validating a signature, i.e. to see if it conforms used the correct hash,
salt size specified in the cert. This seems to contradict you final
paragraph (copied below).
Dan Brown
(905) 501-3857
http://www.certicom.com
owner-ietf-pkix@mail.imc.org
wrote on 08/31/2006 10:47:41 AM:
> My opinion has not changed. I believe that we need to follow
the
> precedent set by RFC 4055.
>
> In my opinion, this situation is a result of the ANSI X9 process
not
> allowing public review of their draft documents. However, I do
not
> expect this policy to change.
>
> Russ
> ...
> >
> > My suspicion is that digital signature validation does not
anticipate
> > constraints in the public key algorithm parameters. An
underlying
> > crypto routine may need the parameters, but the signature is
not
> > going to fail because of a constraint in the parameters, which
could
> > happen in this proposed syntax.
> >
From owner-ietf-pkix@mail.imc.org Thu Aug 31 13:47:50 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GIqdq-0002oT-EL
for pkix-archive@lists.ietf.org; Thu, 31 Aug 2006 13:47:50 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GIqdp-00061y-Oj
for pkix-archive@lists.ietf.org; Thu, 31 Aug 2006 13:47:50 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGqvqY052823;
Thu, 31 Aug 2006 09:52:57 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VGqvSm052822;
Thu, 31 Aug 2006 09:52:57 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from ns0.gdgsc.com (ns0.GDGSC.Com [192.160.62.68])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGqn91052784
for ; Thu, 31 Aug 2006 09:52:56 -0700 (MST)
(envelope-from Richard.Waterhouse@gdc4s.com)
Received: from NDHMC4SXCH.gdc4s.com (ndhmc4sxch02.gdc4s.com [155.95.153.220])
by newman.gdgsc.com (PMDF V6.2 #31127)
with ESMTP id <0J4V00FNSG7SYQ@newman.gdgsc.com> for ietf-pkix@imc.org; Thu,
31 Aug 2006 12:52:40 -0400 (EDT)
Date: Thu, 31 Aug 2006 12:52:38 -0400
From: "Waterhouse, Richard"
Subject: RE: Elliptic Curve Cryptography with PKIX
In-reply-to: <7.0.0.16.2.20060831104558.03e96c18@vigilsec.com>
To: Russ Housley ,
Robert Zuccherato
Cc: Daniel Brown , ietf-pkix@imc.org
Message-id:
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: multipart/alternative;
boundary="----_=_NextPart_001_01C6CD1D.DE49D9E3"
Thread-Topic: Elliptic Curve Cryptography with PKIX
Thread-Index: AcbNEcqvaho5xnKDQIuSTR4P611ClAACydUg
Content-class: urn:content-classes:message
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91
This is a multi-part message in MIME format.
------_=_NextPart_001_01C6CD1D.DE49D9E3
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I liked the approach Mr Brown was proposing some time back though I =
don't know where it stands today. I need to, for example, restrict a key =
to be used with ECMQV. (I also need to, for example, inform the other =
end that the key is based on the NIST p384 curve.)
-----Original Message-----
From: owner-ietf-pkix@mail.imc.org =
[mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Russ Housley
Sent: Thursday, August 31, 2006 10:48 AM
To: Robert Zuccherato
Cc: 'Daniel Brown'; ietf-pkix@imc.org
Subject: RE: Elliptic Curve Cryptography with PKIX
My opinion has not changed. I believe that we need to follow the =
precedent set by RFC 4055.
In my opinion, this situation is a result of the ANSI X9 process not =
allowing public review of their draft documents. However, I do not =
expect this policy to change.
Russ
At 10:24 AM 8/31/2006, Robert Zuccherato wrote:
It's been more than a few months now since Russ posted this message and =
I haven't seen any further discussion on the topic. As I said back in =
April, my preference would be for PKIX to use the AlgorithmIdentifier in =
the already approved X9.62 standard, since I don't think it is helpful =
to have more than one AlgorithmIdentifier defined.
However, whatever we decide to do, I think that we should resolve the =
issue and advance the draft as quickly as possible. Developers of ECC =
applications need to know which AlgorithmIdentifier to use. =20
Does anyone else have any opinions on this topic? When can we hope to =
see a new ID?=20
Robert Zuccherato.=20
> -----Original Message-----=20
> From: owner-ietf-pkix@mail.imc.org=20
> [ =
mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley=20
> Sent: May 3, 2006 3:01 PM=20
> To: ietf-pkix@imc.org=20
> Subject: RE: Elliptic Curve Cryptography with PKIX=20
>=20
>=20
>=20
> RFC 3280 does not provide as much guidance as I would like. Section=20
> 4.1.2.7 says the following about the Subject Public Key Info field:=20
>=20
> This field is used to carry the public key and identify=20
> the algorithm=20
> with which the key is used (e.g., RSA, DSA, or=20
> Diffie-Hellman). The=20
> algorithm is identified using the AlgorithmIdentifier structure=20
> specified in section 4.1.1.2. The object identifiers for the=20
> supported algorithms and the methods for encoding the public key=20
> materials (public key and parameters) are specified in [PKIXALGS]. =
>=20
> Section 4.1.1.2 includes these words:=20
>=20
> The algorithm identifier is used to identify a cryptographic=20
> algorithm. The OBJECT IDENTIFIER component identifies=20
> the algorithm=20
> (such as DSA with SHA-1). The contents of the optional parameters =
> field will vary according to the algorithm identified.=20
>=20
> It does not really provide much guidance to developers of=20
> AlgorithmIdentifiers.=20
>=20
> I characterize the X9.62 approach as using the OBJECT IDENTIFIER to=20
> name a class of elliptic curve algorithms, and then using a portion=20
> of the parameters to list the members of that class that are=20
> acceptable for the subject public key.=20
>=20
> I am very interested to know how this fits with real implementations.=20
>=20
> My suspicion is that implementation that support key agreement are=20
> used to looking into the parameter to determine if the public key is=20
> a member of the same group. This is needed for static-static=20
> Diffie-Hellman (in discrete log or elliptic curve). This is also=20
> needed for MQV (and KEA, if anyone cares anymore).=20
>=20
> My suspicion is that digital signature validation does not anticipate=20
> constraints in the public key algorithm parameters. An underlying=20
> crypto routine may need the parameters, but the signature is not=20
> going to fail because of a constraint in the parameters, which could=20
> happen in this proposed syntax.=20
>=20
> I would greatly appreciate some insight from implementors.=20
>=20
> Russ=20
>=20
------_=_NextPart_001_01C6CD1D.DE49D9E3
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I=20
liked the approach Mr Brown was proposing some time back though I =
don't=20
know where it stands today. I need to, for example, restrict a key to be =
used=20
with ECMQV. (I also need to, for example, inform the other end that the =
key=20
is based on the NIST p384 curve.)
My opinion has not changed. I believe =
that we=20
need to follow the precedent set by RFC 4055.
In my opinion, =
this=20
situation is a result of the ANSI X9 process not allowing public =
review of=20
their draft documents. However, I do not expect this policy to=20
change.
Russ
At 10:24 AM 8/31/2006, Robert Zuccherato=20
wrote:
It's =
been more than=20
a few months now since Russ posted this message and I haven't seen =
any=20
further discussion on the topic. As I said back in April, my=20
preference would be for PKIX to use the AlgorithmIdentifier in the =
already=20
approved X9.62 standard, since I don't think it is helpful to have =
more than=20
one AlgorithmIdentifier defined.
However,=20
whatever we decide to do, I think that we should resolve the issue =
and=20
advance the draft as quickly as possible. Developers of ECC=20
applications need to know which AlgorithmIdentifier to use. =20
Does anyone else have any opinions on =
this=20
topic? When can we hope to see a new ID?=20
Robert=20
Zuccherato.
> -----Original=20
Message-----
> From: =
owner-ietf-pkix@mail.imc.org=20
> [=20
mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ =
Housley=20
> Sent: May 3, 2006 3:01 PM
>=20
To: ietf-pkix@imc.org
> Subject: RE: =
Elliptic=20
Curve Cryptography with PKIX
> =
>
>
> RFC=20
3280 does not provide as much guidance as I would like. =
Section=20
> 4.1.2.7 says the following about =
the =20
Subject Public Key Info field:
> =
> This field is used to carry =
the public=20
key and identify
> the algorithm =
> with which the key is used =
(e.g., RSA,=20
DSA, or
> Diffie-Hellman). =
The=20
> algorithm is =
identified using=20
the AlgorithmIdentifier structure
> specified in section =
4.1.1.2. The=20
object identifiers for the
> supported algorithms and the =
methods for=20
encoding the public key
> =20
materials (public key and parameters) are specified in =
[PKIXALGS].=20
>
> Section =
4.1.1.2 includes=20
these words:
>
> The algorithm identifier is =
used to=20
identify a cryptographic
> algorithm. The OBJECT =
IDENTIFIER=20
component identifies
> the =
algorithm=20
> (such as DSA with=20
SHA-1). The contents of the optional parameters =
> field will vary according to =
the=20
algorithm identified.
> =
> It does not really provide much guidance to developers =
of=20
> AlgorithmIdentifiers. =
>
> I characterize the =
X9.62 approach=20
as using the OBJECT IDENTIFIER to
> =
name a class=20
of elliptic curve algorithms, and then using a portion =
> of the parameters to list the members of that class =
that are=20
> acceptable for the subject public =
key.=20
>
> I am very =
interested to=20
know how this fits with real implementations.
>=20
> My suspicion is that implementation =
that=20
support key agreement are
> used to =
looking into=20
the parameter to determine if the public key is
>=20
a member of the same group. This is needed for static-static=20
> Diffie-Hellman (in discrete log or =
elliptic=20
curve). This is also
> needed for =
MQV (and=20
KEA, if anyone cares anymore).
> =
> My suspicion is that digital signature validation does =
not=20
anticipate
> constraints in the public =
key=20
algorithm parameters. An underlying
>=20
crypto routine may need the parameters, but the signature is not=20
> going to fail because of a constraint =
in the=20
parameters, which could
> happen in =
this proposed=20
syntax.
>
> I would=20
greatly appreciate some insight from implementors.
>
> Russ
>=20
------_=_NextPart_001_01C6CD1D.DE49D9E3--
From owner-ietf-pkix@mail.imc.org Thu Aug 31 14:59:49 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GIrlV-0001CJ-Jj
for pkix-archive@lists.ietf.org; Thu, 31 Aug 2006 14:59:49 -0400
Received: from balder-227.proper.com ([192.245.12.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GIrlU-0002hb-79
for pkix-archive@lists.ietf.org; Thu, 31 Aug 2006 14:59:49 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VI3h4h063849;
Thu, 31 Aug 2006 11:03:43 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost)
by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VI3hUM063848;
Thu, 31 Aug 2006 11:03:43 -0700 (MST)
(envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from nit.isi.edu (nit.isi.edu [128.9.160.116])
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VI3ehV063836
for ; Thu, 31 Aug 2006 11:03:42 -0700 (MST)
(envelope-from apache@nit.isi.edu)
Received: from nit.isi.edu (loopback [127.0.0.1])
by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k7VI3crA019485;
Thu, 31 Aug 2006 11:03:38 -0700
Received: (from apache@localhost)
by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k7VI3cWj019484;
Thu, 31 Aug 2006 11:03:38 -0700
Date: Thu, 31 Aug 2006 11:03:38 -0700
Message-Id: <200608311803.k7VI3cWj019484@nit.isi.edu>
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Subject: RFC 4630 on Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
A new Request for Comments is now available in online RFC libraries.
RFC 4630
Title: Update to DirectoryString Processing in
the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile
Author: R. Housley, S. Santesson
Status: Standards Track
Date: August 2006
Mailbox: housley@vigilsec.com,
stefans@microsoft.com
Pages: 6
Characters: 12539
Updates: RFC3280
See-Also:
I-D Tag: draft-ietf-pkix-cert-utf8-03.txt
URL: http://www.rfc-editor.org/rfc/rfc4630.txt
This document updates the handling of DirectoryString in the Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile, which is published in RFC 3280. The
use of UTF8String and PrintableString are the preferred encoding.
The requirement for exclusive use of UTF8String after December 31,
2003 is removed. [STANDARDS TRACK]
This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.
This is now a Proposed Standard Protocol.
STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and
suggestions for improvements.Please refer to the current edition of the
Internet Official Protocol Standards (STD 1) for the standardization
state and status of this protocol. Distribution of this memo is
unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute
...
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VI3h4h063849; Thu, 31 Aug 2006 11:03:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VI3hUM063848; Thu, 31 Aug 2006 11:03:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VI3ehV063836 for ; Thu, 31 Aug 2006 11:03:42 -0700 (MST) (envelope-from apache@nit.isi.edu)
Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k7VI3crA019485; Thu, 31 Aug 2006 11:03:38 -0700
Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k7VI3cWj019484; Thu, 31 Aug 2006 11:03:38 -0700
Date: Thu, 31 Aug 2006 11:03:38 -0700
Message-Id: <200608311803.k7VI3cWj019484@nit.isi.edu>
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Subject: RFC 4630 on Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
A new Request for Comments is now available in online RFC libraries.
RFC 4630
Title: Update to DirectoryString Processing in
the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile
Author: R. Housley, S. Santesson
Status: Standards Track
Date: August 2006
Mailbox: housley@vigilsec.com,
stefans@microsoft.com
Pages: 6
Characters: 12539
Updates: RFC3280
See-Also:
I-D Tag: draft-ietf-pkix-cert-utf8-03.txt
URL: http://www.rfc-editor.org/rfc/rfc4630.txt
This document updates the handling of DirectoryString in the Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile, which is published in RFC 3280. The
use of UTF8String and PrintableString are the preferred encoding.
The requirement for exclusive use of UTF8String after December 31,
2003 is removed. [STANDARDS TRACK]
This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.
This is now a Proposed Standard Protocol.
STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and
suggestions for improvements.Please refer to the current edition of the
Internet Official Protocol Standards (STD 1) for the standardization
state and status of this protocol. Distribution of this memo is
unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute
...
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGqvqY052823; Thu, 31 Aug 2006 09:52:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VGqvSm052822; Thu, 31 Aug 2006 09:52:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from ns0.gdgsc.com (ns0.GDGSC.Com [192.160.62.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGqn91052784 for ; Thu, 31 Aug 2006 09:52:56 -0700 (MST) (envelope-from Richard.Waterhouse@gdc4s.com)
Received: from NDHMC4SXCH.gdc4s.com (ndhmc4sxch02.gdc4s.com [155.95.153.220]) by newman.gdgsc.com (PMDF V6.2 #31127) with ESMTP id <0J4V00FNSG7SYQ@newman.gdgsc.com> for ietf-pkix@imc.org; Thu, 31 Aug 2006 12:52:40 -0400 (EDT)
Date: Thu, 31 Aug 2006 12:52:38 -0400
From: "Waterhouse, Richard"
Subject: RE: Elliptic Curve Cryptography with PKIX
In-reply-to: <7.0.0.16.2.20060831104558.03e96c18@vigilsec.com>
To: Russ Housley , Robert Zuccherato
Cc: Daniel Brown , ietf-pkix@imc.org
Message-id:
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C6CD1D.DE49D9E3"
Thread-Topic: Elliptic Curve Cryptography with PKIX
Thread-Index: AcbNEcqvaho5xnKDQIuSTR4P611ClAACydUg
Content-class: urn:content-classes:message
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
This is a multi-part message in MIME format.
------_=_NextPart_001_01C6CD1D.DE49D9E3
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I liked the approach Mr Brown was proposing some time back though I =
don't know where it stands today. I need to, for example, restrict a key =
to be used with ECMQV. (I also need to, for example, inform the other =
end that the key is based on the NIST p384 curve.)
-----Original Message-----
From: owner-ietf-pkix@mail.imc.org =
[mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Russ Housley
Sent: Thursday, August 31, 2006 10:48 AM
To: Robert Zuccherato
Cc: 'Daniel Brown'; ietf-pkix@imc.org
Subject: RE: Elliptic Curve Cryptography with PKIX
My opinion has not changed. I believe that we need to follow the =
precedent set by RFC 4055.
In my opinion, this situation is a result of the ANSI X9 process not =
allowing public review of their draft documents. However, I do not =
expect this policy to change.
Russ
At 10:24 AM 8/31/2006, Robert Zuccherato wrote:
It's been more than a few months now since Russ posted this message and =
I haven't seen any further discussion on the topic. As I said back in =
April, my preference would be for PKIX to use the AlgorithmIdentifier in =
the already approved X9.62 standard, since I don't think it is helpful =
to have more than one AlgorithmIdentifier defined.
However, whatever we decide to do, I think that we should resolve the =
issue and advance the draft as quickly as possible. Developers of ECC =
applications need to know which AlgorithmIdentifier to use. =20
Does anyone else have any opinions on this topic? When can we hope to =
see a new ID?=20
Robert Zuccherato.=20
> -----Original Message-----=20
> From: owner-ietf-pkix@mail.imc.org=20
> [ =
mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley=20
> Sent: May 3, 2006 3:01 PM=20
> To: ietf-pkix@imc.org=20
> Subject: RE: Elliptic Curve Cryptography with PKIX=20
>=20
>=20
>=20
> RFC 3280 does not provide as much guidance as I would like. Section=20
> 4.1.2.7 says the following about the Subject Public Key Info field:=20
>=20
> This field is used to carry the public key and identify=20
> the algorithm=20
> with which the key is used (e.g., RSA, DSA, or=20
> Diffie-Hellman). The=20
> algorithm is identified using the AlgorithmIdentifier structure=20
> specified in section 4.1.1.2. The object identifiers for the=20
> supported algorithms and the methods for encoding the public key=20
> materials (public key and parameters) are specified in [PKIXALGS]. =
>=20
> Section 4.1.1.2 includes these words:=20
>=20
> The algorithm identifier is used to identify a cryptographic=20
> algorithm. The OBJECT IDENTIFIER component identifies=20
> the algorithm=20
> (such as DSA with SHA-1). The contents of the optional parameters =
> field will vary according to the algorithm identified.=20
>=20
> It does not really provide much guidance to developers of=20
> AlgorithmIdentifiers.=20
>=20
> I characterize the X9.62 approach as using the OBJECT IDENTIFIER to=20
> name a class of elliptic curve algorithms, and then using a portion=20
> of the parameters to list the members of that class that are=20
> acceptable for the subject public key.=20
>=20
> I am very interested to know how this fits with real implementations.=20
>=20
> My suspicion is that implementation that support key agreement are=20
> used to looking into the parameter to determine if the public key is=20
> a member of the same group. This is needed for static-static=20
> Diffie-Hellman (in discrete log or elliptic curve). This is also=20
> needed for MQV (and KEA, if anyone cares anymore).=20
>=20
> My suspicion is that digital signature validation does not anticipate=20
> constraints in the public key algorithm parameters. An underlying=20
> crypto routine may need the parameters, but the signature is not=20
> going to fail because of a constraint in the parameters, which could=20
> happen in this proposed syntax.=20
>=20
> I would greatly appreciate some insight from implementors.=20
>=20
> Russ=20
>=20
------_=_NextPart_001_01C6CD1D.DE49D9E3
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I=20
liked the approach Mr Brown was proposing some time back though I =
don't=20
know where it stands today. I need to, for example, restrict a key to be =
used=20
with ECMQV. (I also need to, for example, inform the other end that the =
key=20
is based on the NIST p384 curve.)
My opinion has not changed. I believe =
that we=20
need to follow the precedent set by RFC 4055.
In my opinion, =
this=20
situation is a result of the ANSI X9 process not allowing public =
review of=20
their draft documents. However, I do not expect this policy to=20
change.
Russ
At 10:24 AM 8/31/2006, Robert Zuccherato=20
wrote:
It's =
been more than=20
a few months now since Russ posted this message and I haven't seen =
any=20
further discussion on the topic. As I said back in April, my=20
preference would be for PKIX to use the AlgorithmIdentifier in the =
already=20
approved X9.62 standard, since I don't think it is helpful to have =
more than=20
one AlgorithmIdentifier defined.
However,=20
whatever we decide to do, I think that we should resolve the issue =
and=20
advance the draft as quickly as possible. Developers of ECC=20
applications need to know which AlgorithmIdentifier to use. =20
Does anyone else have any opinions on =
this=20
topic? When can we hope to see a new ID?=20
Robert=20
Zuccherato.
> -----Original=20
Message-----
> From: =
owner-ietf-pkix@mail.imc.org=20
> [=20
mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ =
Housley=20
> Sent: May 3, 2006 3:01 PM
>=20
To: ietf-pkix@imc.org
> Subject: RE: =
Elliptic=20
Curve Cryptography with PKIX
> =
>
>
> RFC=20
3280 does not provide as much guidance as I would like. =
Section=20
> 4.1.2.7 says the following about =
the =20
Subject Public Key Info field:
> =
> This field is used to carry =
the public=20
key and identify
> the algorithm =
> with which the key is used =
(e.g., RSA,=20
DSA, or
> Diffie-Hellman). =
The=20
> algorithm is =
identified using=20
the AlgorithmIdentifier structure
> specified in section =
4.1.1.2. The=20
object identifiers for the
> supported algorithms and the =
methods for=20
encoding the public key
> =20
materials (public key and parameters) are specified in =
[PKIXALGS].=20
>
> Section =
4.1.1.2 includes=20
these words:
>
> The algorithm identifier is =
used to=20
identify a cryptographic
> algorithm. The OBJECT =
IDENTIFIER=20
component identifies
> the =
algorithm=20
> (such as DSA with=20
SHA-1). The contents of the optional parameters =
> field will vary according to =
the=20
algorithm identified.
> =
> It does not really provide much guidance to developers =
of=20
> AlgorithmIdentifiers. =
>
> I characterize the =
X9.62 approach=20
as using the OBJECT IDENTIFIER to
> =
name a class=20
of elliptic curve algorithms, and then using a portion =
> of the parameters to list the members of that class =
that are=20
> acceptable for the subject public =
key.=20
>
> I am very =
interested to=20
know how this fits with real implementations.
>=20
> My suspicion is that implementation =
that=20
support key agreement are
> used to =
looking into=20
the parameter to determine if the public key is
>=20
a member of the same group. This is needed for static-static=20
> Diffie-Hellman (in discrete log or =
elliptic=20
curve). This is also
> needed for =
MQV (and=20
KEA, if anyone cares anymore).
> =
> My suspicion is that digital signature validation does =
not=20
anticipate
> constraints in the public =
key=20
algorithm parameters. An underlying
>=20
crypto routine may need the parameters, but the signature is not=20
> going to fail because of a constraint =
in the=20
parameters, which could
> happen in =
this proposed=20
syntax.
>
> I would=20
greatly appreciate some insight from implementors.
>
> Russ
>=20
------_=_NextPart_001_01C6CD1D.DE49D9E3--
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGb045050143; Thu, 31 Aug 2006 09:37:00 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VGb0Uw050142; Thu, 31 Aug 2006 09:37:00 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7VGaxZH050129 for ; Thu, 31 Aug 2006 09:36:59 -0700 (MST) (envelope-from housley@vigilsec.com)
Received: (qmail 17953 invoked by uid 0); 31 Aug 2006 16:36:54 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.235.104) by woodstock.binhost.com with SMTP; 31 Aug 2006 16:36:54 -0000
Message-Id: <7.0.0.16.2.20060831123401.07871730@vigilsec.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Thu, 31 Aug 2006 12:36:34 -0400
To: ietf-pkix@imc.org
From: Russ Housley
Subject: RE: Elliptic Curve Cryptography with PKIX
In-Reply-To:
References: <7.0.0.16.2.20060831104558.03e96c18@vigilsec.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
So, let's find out. Can developers of software that validates
certificates and digital signatures tell us how the proposed parameter
syntax would impact their code?
Russ
At 12:09 PM 8/31/2006, Daniel Brown wrote:
Russ,
The X9.62 syntax follows the precedent set by 4055, in the
sense that it identifies the algorithm for which the public key is to be
used in the subject public key info field.
Section 3.3 of RFC 4055, item 3 in the list, clearly states
that an signature validation implementation MUST check the parameters
field of the subject public key info field algorithm identitifer when
validating a signature, i.e. to see if it conforms used the correct hash,
salt size specified in the cert. This seems to contradict you final
paragraph (copied below).
Dan Brown
(905) 501-3857
http://www.certicom.com
owner-ietf-pkix@mail.imc.org
wrote on 08/31/2006 10:47:41 AM:
> My opinion has not changed. I believe that we need to follow
the
> precedent set by RFC 4055.
>
> In my opinion, this situation is a result of the ANSI X9 process
not
> allowing public review of their draft documents. However, I do
not
> expect this policy to change.
>
> Russ
> ...
> >
> > My suspicion is that digital signature validation does not
anticipate
> > constraints in the public key algorithm parameters. An
underlying
> > crypto routine may need the parameters, but the signature is
not
> > going to fail because of a constraint in the parameters, which
could
> > happen in this proposed syntax.
> >
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGAVRS044863; Thu, 31 Aug 2006 09:10:31 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VGAVMp044862; Thu, 31 Aug 2006 09:10:31 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail.ca.certicom.com (nat194.certicom.com [66.48.18.194]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGAQoj044832 for ; Thu, 31 Aug 2006 09:10:30 -0700 (MST) (envelope-from DBrown@certicom.com)
Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id CF40F100233CF; Thu, 31 Aug 2006 12:10:20 -0400 (EDT)
Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14727-77; Thu, 31 Aug 2006 12:10:15 -0400 (EDT)
Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 223601006B06B; Thu, 31 Aug 2006 12:10:15 -0400 (EDT)
In-Reply-To: <7.0.0.16.2.20060831104558.03e96c18@vigilsec.com>
To: Russ Housley
Cc: ietf-pkix@imc.org, Robert Zuccherato
Subject: RE: Elliptic Curve Cryptography with PKIX
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
Message-ID:
From: Daniel Brown
Date: Thu, 31 Aug 2006 12:09:15 -0400
X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 08/31/2006 12:09:10 PM, Serialize complete at 08/31/2006 12:09:10 PM
Content-Type: multipart/alternative; boundary="=_alternative 005928D8852571DB_="
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
This is a multipart message in MIME format.
--=_alternative 005928D8852571DB_=
Content-Type: text/plain; charset="US-ASCII"
Russ,
The X9.62 syntax follows the precedent set by 4055, in the sense that it
identifies the algorithm for which the public key is to be used in the
subject public key info field.
Section 3.3 of RFC 4055, item 3 in the list, clearly states that an
signature validation implementation MUST check the parameters field of the
subject public key info field algorithm identitifer when validating a
signature, i.e. to see if it conforms used the correct hash, salt size
specified in the cert. This seems to contradict you final paragraph
(copied below).
Dan Brown
(905) 501-3857
http://www.certicom.com
owner-ietf-pkix@mail.imc.org wrote on 08/31/2006 10:47:41 AM:
> My opinion has not changed. I believe that we need to follow the
> precedent set by RFC 4055.
>
> In my opinion, this situation is a result of the ANSI X9 process not
> allowing public review of their draft documents. However, I do not
> expect this policy to change.
>
> Russ
> ...
> >
> > My suspicion is that digital signature validation does not anticipate
> > constraints in the public key algorithm parameters. An underlying
> > crypto routine may need the parameters, but the signature is not
> > going to fail because of a constraint in the parameters, which could
> > happen in this proposed syntax.
> >
--=_alternative 005928D8852571DB_=
Content-Type: text/html; charset="US-ASCII"
Russ,
The X9.62 syntax follows the precedent
set by 4055, in the sense that it identifies the algorithm for which the
public key is to be used in the subject public key info field.
Section 3.3 of RFC 4055, item 3 in the
list, clearly states that an signature validation implementation MUST check
the parameters field of the subject public key info field algorithm identitifer
when validating a signature, i.e. to see if it conforms used the correct
hash, salt size specified in the cert. This seems to contradict you
final paragraph (copied below).
Dan Brown
(905) 501-3857
http://www.certicom.com
owner-ietf-pkix@mail.imc.org wrote on 08/31/2006 10:47:41
AM:
> My opinion has not changed. I believe that we need to follow
the
> precedent set by RFC 4055.
>
> In my opinion, this situation is a result of the ANSI X9 process not
> allowing public review of their draft documents. However, I
do not
> expect this policy to change.
>
> Russ
> ...
> >
> > My suspicion is that digital signature validation does not anticipate
> > constraints in the public key algorithm parameters. An
underlying
> > crypto routine may need the parameters, but the signature is
not
> > going to fail because of a constraint in the parameters, which
could
> > happen in this proposed syntax.
> >
--=_alternative 005928D8852571DB_=--
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VElwAM033429; Thu, 31 Aug 2006 07:47:58 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VElwAl033428; Thu, 31 Aug 2006 07:47:58 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7VElreG033414 for ; Thu, 31 Aug 2006 07:47:57 -0700 (MST) (envelope-from housley@vigilsec.com)
Received: (qmail 16372 invoked by uid 0); 31 Aug 2006 14:47:49 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.235.104) by woodstock.binhost.com with SMTP; 31 Aug 2006 14:47:49 -0000
Message-Id: <7.0.0.16.2.20060831104558.03e96c18@vigilsec.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Thu, 31 Aug 2006 10:47:41 -0400
To: Robert Zuccherato
From: Russ Housley
Subject: RE: Elliptic Curve Cryptography with PKIX
Cc: "'Daniel Brown'" , ietf-pkix@imc.org
In-Reply-To: <7A3E1242FA9989439AD1F9B2D71C287F07F9CD14@sottmxs05.entrust .com>
References: <7A3E1242FA9989439AD1F9B2D71C287F07F9CD14@sottmxs05.entrust.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
My opinion has not changed. I believe that we need to follow the
precedent set by RFC 4055.
In my opinion, this situation is a result of the ANSI X9 process not
allowing public review of their draft documents. However, I do not
expect this policy to change.
Russ
At 10:24 AM 8/31/2006, Robert Zuccherato wrote:
It's been more than
a few months now since Russ posted this message and I haven't seen any
further discussion on the topic. As I said back in April, my
preference would be for PKIX to use the AlgorithmIdentifier in the
already approved X9.62 standard, since I don't think it is helpful to
have more than one AlgorithmIdentifier defined.
However, whatever we decide to do, I think that we should
resolve the issue and advance the draft as quickly as possible.
Developers of ECC applications need to know which AlgorithmIdentifier to
use.
Does anyone else have any opinions on this topic? When
can we hope to see a new ID?
Robert
Zuccherato.
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
>
[
mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley
> Sent: May 3, 2006 3:01 PM
> To: ietf-pkix@imc.org
> Subject: RE: Elliptic Curve Cryptography with
PKIX
>
>
>
> RFC 3280 does not provide as much guidance as I would
like. Section
> 4.1.2.7 says the following about the Subject
Public Key Info field:
>
> This field is used to carry the
public key and identify
> the algorithm
> with which the key is used
(e.g., RSA, DSA, or
> Diffie-Hellman). The
> algorithm is identified using
the AlgorithmIdentifier structure
> specified in section
4.1.1.2. The object identifiers for the
> supported algorithms and the
methods for encoding the public key
> materials (public key and
parameters) are specified in [PKIXALGS].
>
> Section 4.1.1.2 includes these words:
>
> The algorithm identifier is
used to identify a cryptographic
> algorithm. The OBJECT
IDENTIFIER component identifies
> the algorithm
> (such as DSA with SHA-1).
The contents of the optional parameters
> field will vary according to
the algorithm identified.
>
> It does not really provide much guidance to developers
of
> AlgorithmIdentifiers.
>
> I characterize the X9.62 approach as using the OBJECT
IDENTIFIER to
> name a class of elliptic curve algorithms, and then
using a portion
> of the parameters to list the members of that class
that are
> acceptable for the subject public key.
>
> I am very interested to know how this fits with real
implementations.
>
> My suspicion is that implementation that support key
agreement are
> used to looking into the parameter to determine if the
public key is
> a member of the same group. This is needed for
static-static
> Diffie-Hellman (in discrete log or elliptic
curve). This is also
> needed for MQV (and KEA, if anyone cares
anymore).
>
> My suspicion is that digital signature validation does
not anticipate
> constraints in the public key algorithm
parameters. An underlying
> crypto routine may need the parameters, but the
signature is not
> going to fail because of a constraint in the
parameters, which could
> happen in this proposed syntax.
>
> I would greatly appreciate some insight from
implementors.
>
> Russ
>
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VEOast029331; Thu, 31 Aug 2006 07:24:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VEOa19029330; Thu, 31 Aug 2006 07:24:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from sottccs2.entrust.com (sottccs2.entrust.com [216.191.252.16]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7VEOYp6029307 for ; Thu, 31 Aug 2006 07:24:35 -0700 (MST) (envelope-from robert.zuccherato@entrust.com)
Received: (qmail 30740 invoked from network); 31 Aug 2006 14:24:23 -0000
Received: from robert.zuccherato@entrust.com by sottccs2.entrust.com with EntrustECS-Server-8.0;31 Aug 2006 14:24:23 -0000
Received: from sottmxs00.entrust.com (10.4.61.22) by sottccs2.entrust.com with SMTP; 31 Aug 2006 14:24:23 -0000
Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id ; Thu, 31 Aug 2006 10:24:25 -0400
Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F07F9CD14@sottmxs05.entrust.com>
From: Robert Zuccherato
To: "'Russ Housley'" , ietf-pkix@imc.org
Cc: "'Daniel Brown'"
Subject: RE: Elliptic Curve Cryptography with PKIX
Date: Thu, 31 Aug 2006 10:24:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6CD09.28D2D066"
Sender: owner-ietf-pkix@mail.imc.org
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.
------_=_NextPart_001_01C6CD09.28D2D066
Content-Type: text/plain
It's been more than a few months now since Russ posted this message and I
haven't seen any further discussion on the topic. As I said back in April,
my preference would be for PKIX to use the AlgorithmIdentifier in the
already approved X9.62 standard, since I don't think it is helpful to have
more than one AlgorithmIdentifier defined.
However, whatever we decide to do, I think that we should resolve the issue
and advance the draft as quickly as possible. Developers of ECC
applications need to know which AlgorithmIdentifier to use.
Does anyone else have any opinions on this topic? When can we hope to see a
new ID?
Robert Zuccherato.
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley
> Sent: May 3, 2006 3:01 PM
> To: ietf-pkix@imc.org
> Subject: RE: Elliptic Curve Cryptography with PKIX
>
>
>
> RFC 3280 does not provide as much guidance as I would like. Section
> 4.1.2.7 says the following about the Subject Public Key Info field:
>
> This field is used to carry the public key and identify
> the algorithm
> with which the key is used (e.g., RSA, DSA, or
> Diffie-Hellman). The
> algorithm is identified using the AlgorithmIdentifier structure
> specified in section 4.1.1.2. The object identifiers for the
> supported algorithms and the methods for encoding the public key
> materials (public key and parameters) are specified in [PKIXALGS].
>
> Section 4.1.1.2 includes these words:
>
> The algorithm identifier is used to identify a cryptographic
> algorithm. The OBJECT IDENTIFIER component identifies
> the algorithm
> (such as DSA with SHA-1). The contents of the optional parameters
> field will vary according to the algorithm identified.
>
> It does not really provide much guidance to developers of
> AlgorithmIdentifiers.
>
> I characterize the X9.62 approach as using the OBJECT IDENTIFIER to
> name a class of elliptic curve algorithms, and then using a portion
> of the parameters to list the members of that class that are
> acceptable for the subject public key.
>
> I am very interested to know how this fits with real implementations.
>
> My suspicion is that implementation that support key agreement are
> used to looking into the parameter to determine if the public key is
> a member of the same group. This is needed for static-static
> Diffie-Hellman (in discrete log or elliptic curve). This is also
> needed for MQV (and KEA, if anyone cares anymore).
>
> My suspicion is that digital signature validation does not anticipate
> constraints in the public key algorithm parameters. An underlying
> crypto routine may need the parameters, but the signature is not
> going to fail because of a constraint in the parameters, which could
> happen in this proposed syntax.
>
> I would greatly appreciate some insight from implementors.
>
> Russ
>
------_=_NextPart_001_01C6CD09.28D2D066
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
RE: Elliptic Curve Cryptography with PKIX
It's been more than a few months now since Russ =
posted this message and I haven't seen any further discussion on the =
topic. As I said back in April, my preference would be for PKIX =
to use the AlgorithmIdentifier in the already approved X9.62 standard, =
since I don't think it is helpful to have more than one =
AlgorithmIdentifier defined.
However, whatever we decide to do, I think that we =
should resolve the issue and advance the draft as quickly as =
possible. Developers of ECC applications need to know which =
AlgorithmIdentifier to use.
Does anyone else have any opinions on this =
topic? When can we hope to see a new ID?
Robert =
Zuccherato.
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
> [mailto:owner-ietf-pkix@mail=
.imc.org] On Behalf Of Russ Housley
> Sent: May 3, 2006 3:01 PM
> To: ietf-pkix@imc.org
> Subject: RE: Elliptic Curve Cryptography with =
PKIX
>
>
>
> RFC 3280 does not provide as much guidance as I =
would like. Section
> 4.1.2.7 says the following about the =
Subject Public Key Info field:
>
> This field is used to =
carry the public key and identify
> the algorithm
> with which the key is =
used (e.g., RSA, DSA, or
> Diffie-Hellman). The
> algorithm is identified =
using the AlgorithmIdentifier structure
> specified in section =
4.1.1.2. The object identifiers for the
> supported algorithms =
and the methods for encoding the public key
> materials (public key =
and parameters) are specified in [PKIXALGS].
>
> Section 4.1.1.2 includes these words:
>
> The algorithm =
identifier is used to identify a cryptographic
> algorithm. The =
OBJECT IDENTIFIER component identifies
> the algorithm
> (such as DSA with =
SHA-1). The contents of the optional parameters
> field will vary =
according to the algorithm identified.
>
> It does not really provide much guidance to =
developers of
> AlgorithmIdentifiers.
>
> I characterize the X9.62 approach as using the =
OBJECT IDENTIFIER to
> name a class of elliptic curve algorithms, and =
then using a portion
> of the parameters to list the members of that =
class that are
> acceptable for the subject public key.
>
> I am very interested to know how this fits with =
real implementations.
>
> My suspicion is that implementation that =
support key agreement are
> used to looking into the parameter to determine =
if the public key is
> a member of the same group. This is =
needed for static-static
> Diffie-Hellman (in discrete log or elliptic =
curve). This is also
> needed for MQV (and KEA, if anyone cares =
anymore).
>
> My suspicion is that digital signature =
validation does not anticipate
> constraints in the public key algorithm =
parameters. An underlying
> crypto routine may need the parameters, but the =
signature is not
> going to fail because of a constraint in the =
parameters, which could
> happen in this proposed syntax.
>
> I would greatly appreciate some insight from =
implementors.
>
> Russ
>
------_=_NextPart_001_01C6CD09.28D2D066--
Received: from juniperlearning.com (218-162-159-220.dynamic.hinet.net [218.162.159.220]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7V2jCeP000272 for ; Wed, 30 Aug 2006 19:45:19 -0700 (MST) (envelope-from jerkstuc@fdt.net)
Received: by 192.168.131.4 with SMTP id LEdvkO; for ; Wed, 30 Aug 2006 19:45:08 -0700
Message-ID: <000001c6cca7$788896e0$0483a8c0@rpvgtd>
Reply-To: "Guillermo Spotts"
From: "Guillermo Spotts"
To: ietf-pkix-archive@imc.org
Subject: Re: kuR Xpy
Date: Wed, 30 Aug 2006 19:45:08 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CC6C.CC29BEE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6CC6C.CC29BEE0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi
=20
All y i our PHAR g RM h ACY d l irec h tly from the m s anuf a actu d
rer,
Your c f hanc d e to eco k nomiz l e w z ith us
http://wionterfunmasde.com
e=20
d=20
s=20
going. I am Admiral Benbow, head of League Navy Security. Those
lid, now thrown aside. There was a heavy thud and Svinjar landed
clapping of approval. I bowed in Svinjars direction.
------=_NextPart_000_0001_01C6CC6C.CC29BEE0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi
All y i our PHAR g RM h ACY d l irec h tly from the m s anuf a actu d rer,
e
d
s
going. I am Admiral Benbow, head of League Navy Security. =
Those
lid, now thrown aside. There was a heavy thud and Svinjar =
landed
clapping of approval. I bowed in Svinjars =
direction.
------=_NextPart_000_0001_01C6CC6C.CC29BEE0--
Received: from cedtalent.com ([83.214.212.58]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7TIW2Ig019872 for ; Tue, 29 Aug 2006 11:32:07 -0700 (MST) (envelope-from neasecolom@cedtalent.com)
Received: by 192.168.60.107 with SMTP id qQmsopWBV; for ; Tue, 29 Aug 2006 11:31:53 -0700
Message-ID: <000001c6cb99$668c66b0$6b3ca8c0@yuytiv>
Reply-To: "Vonda Crowley"
From: "Vonda Crowley"
To: ietf-pkix-archive@imc.org
Subject: Re: zoRXse
Date: Tue, 29 Aug 2006 11:31:53 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CB5E.BA2D8EB0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6CB5E.BA2D8EB0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
Go y od news for you.
=20
PHA a RMA w CY d t ire h ctly from the ma i nufa n cture j r,
Eco n nomiz u e up t m o 6 f 0 % wit z h us http://heranrtionketer.com
, b=20
, q=20
, s=20
I called an early break. Get some racktime. Pack your bags. The music
and props are ready to go. We ship out at midnight. Transportation to
the spaceport leaves here an hour earlier-so dont be late.
------=_NextPart_000_0001_01C6CB5E.BA2D8EB0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
Go y =
od news for you.
PHA a =
RMA w =
CY d t =
ire h =
ctly from the ma i nufa n cture j r,
<=
P>, b =
, q =
, s =
I called an early break. Get some racktime. Pack your =
bags. The music
and props are ready to go. We ship out at midnight. Transportation =
to
the spaceport leaves here an hour earlier-so dont be =
late.
------=_NextPart_000_0001_01C6CB5E.BA2D8EB0--
Received: from ausum.com (lns-bzn-53-82-65-50-66.adsl.proxad.net [82.65.50.66]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7TAMAqc057303 for ; Tue, 29 Aug 2006 03:22:15 -0700 (MST) (envelope-from sonalallie@florida-water.com)
Received: by 192.168.150.30 with SMTP id risJNY; for ; Tue, 29 Aug 2006 03:22:11 -0700
Message-ID: <000001c6cb54$fd344370$1e96a8c0@yckgu>
Reply-To: "Canan Muncy"
From: "Canan Muncy"
To: ietf-pkix-archive@imc.org
Subject: Re: qupiRX
Date: Tue, 29 Aug 2006 03:22:11 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CB1A.50DA2660"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6CB1A.50DA2660
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
Goo o d news for you.
=20
PH y ARMA n CY di h rectl z y from the ma k nuf h actu m rer,
Eco s nom l ize up t h o 6 a 0 % w u ith us
http://jetunahsedunkadesin.com
, a=20
, c=20
, j=20
behind me-along with most of the squad of guards. Everyone wanted to
help: none of them knew a thing. But one name kept cropping up during
the questioning. Sjonvarp.
------=_NextPart_000_0001_01C6CB1A.50DA2660
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
Goo o d news for you.
PH y ARMA n CY di h rectl z y from the ma k nuf h actu m rer,
, a
, c
, j
behind me-along with most of the =
squad of guards. Everyone wanted to
help: none of them knew a thing. But one name kept cropping up =
during
the questioning. Sjonvarp.
------=_NextPart_000_0001_01C6CB1A.50DA2660--
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7T1Ot8s089566; Mon, 28 Aug 2006 18:24:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7T1OtqT089565; Mon, 28 Aug 2006 18:24:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7T1OojX089556 for ; Mon, 28 Aug 2006 18:24:54 -0700 (MST) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 02:24:49 +0100
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"
Subject: Withdrawing 1998 edition of Directory Specification
Date: Tue, 29 Aug 2006 02:24:29 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Withdrawing 1998 edition of Directory Specification
Thread-Index: AcbKycNfSvxgk42yRqS+x7GbgxVxYwAPxmKw
From: "Stefan Santesson"
To:
X-OriginalArrivalTime: 29 Aug 2006 01:24:49.0423 (UTC) FILETIME=[EB9591F0:01C6CB09]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k7T1OsjX089560
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
ISO is planning to withdraw the 1998 version (3rd edition) of the
Directory specification.
This has already been done by ITU and ISO now request input on whether
it would be OK for them to do the same.
With 2005 version available, the two latest versions will be maintained
even though the 1998 version is withdrawn.
Does anyone on this list have any reason to object to this?
Stefan Santesson
Senior Program Manager
Windows Security, Standards
Received: from hammerstattoo.com (49.Red-81-32-53.dynamicIP.rima-tde.net [81.32.53.49]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7S5VNuZ048719 for ; Sun, 27 Aug 2006 22:31:29 -0700 (MST) (envelope-from labree@foomp.com)
Received: by 192.168.185.228 with SMTP id zxVHWH; for ; Sun, 27 Aug 2006 22:31:12 -0700
Message-ID: <000001c6ca63$2cafa740$e4b9a8c0@ewmwbn>
Reply-To: "Lecia Migliore"
From: "Lecia Migliore"
To: ietf-pkix-archive@imc.org
Subject: Re: RXboxa
Date: Sun, 27 Aug 2006 22:31:12 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CA28.8050CF40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6CA28.8050CF40
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
Goo s d news for you.
=20
P m HARMAC t Y di k rec x tly from the m r anufa h cture d r,
Ec s onomi a ze up g to 6 i 0 % w v ith us http://polikeyuhadesun.com
, m=20
, s=20
, y=20
source of nourishment for all. Their fruit is the result of careful
gene mutation and transplant, rich in animal protein. They should not
be eaten raw because of the chance of trichinosis, but should be baked
------=_NextPart_000_0001_01C6CA28.8050CF40
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
Goo s d news for you.
P m HARMAC t Y di k rec x tly from the m r anufa h cture d r,
<=
P>, m , s
, y
source of nourishment for all. =
Their fruit is the result of careful
gene mutation and transplant, rich in animal protein. They should =
not
be eaten raw because of the chance of trichinosis, but should be =
baked
------=_NextPart_000_0001_01C6CA28.8050CF40--
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7QNDUVN008442; Sat, 26 Aug 2006 16:13:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7QNDUVH008441; Sat, 26 Aug 2006 16:13:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from t-mta2.odn.ne.jp (mfep2.odn.ne.jp [143.90.131.180]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7QNDScC008434 for ; Sat, 26 Aug 2006 16:13:28 -0700 (MST) (envelope-from jordi.palet@consulintel.es)
Received: from consulintel.es ([211.131.100.108]) by t-mta2.odn.ne.jp with ESMTP id <20060826231327147.HLMI.203523.t-mta2.odn.ne.jp@mta2.odn.ne.jp> for ; Sun, 27 Aug 2006 08:13:27 +0900
From: jordi.palet@consulintel.es
To: ietf-pkix@imc.org
Subject: test
Date: Sun, 27 Aug 2006 08:12:41 +0900
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_BF6E321B.F0BD5ADD"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-Id: <20060826231327147.HLMI.203523.t-mta2.odn.ne.jp@mta2.odn.ne.jp>
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
This is a multi-part message in MIME format.
------=_NextPart_000_0014_BF6E321B.F0BD5ADD
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit
ÅäÓg:Öƒä_ãÎ÷4˯‚¨ñ¨q[ª¾½â? nÄdêk’ñsJ˜¾³ýJÈÖü»ž·ÕµHfíŒåQ1‡b†H#—úʇ[#‘{šAÙ!÷c?qØþaŒÍ{jM9©53hç~8·Dœ¤Ì†
|h¼}ûRαíÆ~—:þ›3º°†ofŠj ônàèè¼AãÎv”Än¡ü…§.—žhèg[ô*þô˜õÔ!ÛîNÓ¡h¨â*sŽ§âµAÓlpñ3S?e
¶÷{´.Vc% ÀXâÎvã¬þŒ¸OŽÅ÷³vS¾ÅÁ²Mzý‡½S~ŒBWx»q°yÑ4Û°‘~>Kè´Pq¥Oz!äFÞ-ìÉ™x1÷
ÙÑè̪°uÕÁ‡
\,ÄKû-a{ç~ÄxšŽOmšf‡w5OZS*êf£f3z7“[¢ó ›%Í™TJ{oû9ÇX
ù÷‚S¬(3%U(cЊ§!6–G
Ð…VLær(ú²x
hb3S§8RÅ.d„3K®E; Fri, 25 Aug 2006 16:10:35 -0700 (MST) (envelope-from tgindin@us.ibm.com)
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k7PNASL6026981 for ; Fri, 25 Aug 2006 19:10:28 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7PNASeu227930 for ; Fri, 25 Aug 2006 19:10:28 -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 k7PNAS61026710 for ; Fri, 25 Aug 2006 19:10:28 -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 k7PNARa3026704; Fri, 25 Aug 2006 19:10:27 -0400
In-Reply-To: <44EE17F4.5060403@nist.gov>
To: "David A. Cooper"
Cc: pkix
MIME-Version: 1.0
Subject: Re: Confusion about encoding of attributes that use the DirectoryString type
X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006
From: Tom Gindin
Message-ID:
Date: Fri, 25 Aug 2006 19:10:25 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at 08/25/2006 19:10:26, Serialize complete at 08/25/2006 19:10:26
Content-Type: text/plain; charset="US-ASCII"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
David:
Does it make sense to point out that the DirectoryString rules
apply to all CHOICES containing both TeletexString and BMPString as types?
Both Teletex and BMP appear inside CHOICES which don't contain the other
one, but they only appear together in DirectoryString's AFAIK.
Tom Gindin
"David A. Cooper"
Sent by: owner-ietf-pkix@mail.imc.org
08/24/2006 05:19 PM
To: pkix
cc:
Subject: Confusion about encoding of attributes that use
the DirectoryString type
All,
It has come to the 3280bis design team's attention that there has been
considerable confusing with respect the the rules in RFC 3280 (and
3280bis) about the choice of string type to use when encoding attributes
of type DirectoryString. The source of the confusion is the syntax used
in Appendix A of RFC 3280 (and 3280bis) to describe attributes that use
the DirectoryString encoding. For example, the common name attribute
appears in Appendix A as:
-- Naming attributes of type X520CommonName
id-at-commonName AttributeType ::= { id-at 3 }
X520CommonName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-common-name)),
printableString PrintableString (SIZE (1..ub-common-name)),
universalString UniversalString (SIZE (1..ub-common-name)),
utf8String UTF8String (SIZE (1..ub-common-name)),
bmpString BMPString (SIZE (1..ub-common-name)) }
The editors of RFC 3280 (and RFC 2459) chose to use this syntax so that
the size constraints could be included in the ASN.1 without the need to
use a parameterized type definition. The X.520 definition of
DirectoryString includes a parameter that can be used to specify the
maximum allowable string length and the definition of each attribute
instantiates that parameter with the maximum allowable string length for
that attribute. Since not all ASN.1 compilers can process parameterized
type definitions, the PKIX profile uses the syntax show above, which has
the same encoding and semantics as the syntax used in X.520 but is
easier for ASN.1 compilers to process.
The problem with the syntax used in Appendix A of RFC 3280 is that the
word "DirectoryString" does not appear. So, many people were unaware
that attributes such as common name used the DirectoryString type and so
did not know that the rules in section 4.1.2.4 for the encoding of
attributes that used the DirectoryString type applied to these attributes.
The 3280bis design team has discussed this issue and agrees that the
ASN.1 in Appendix A should not be changed since using the syntax from
X.520 would result in incompatibility with some ASN.1 compilers.
Instead, the design team recommends adding comments into the ASN.1
module prior to the definition of each attribute that uses the
DirectoryString type that clarifies that the attribute uses the
DirectoryString type. A new paragraph can also be added to Appendix B
(ASN.1 Notes) explaining the situation.
Below is a portion of Appendix A with additional comments added for the
attributes types shown as well as the new paragraph proposed for Appendix
B.
-- Naming attributes of type X520name
id-at-name AttributeType ::= { id-at 41 }
id-at-surname AttributeType ::= { id-at 4 }
id-at-givenName AttributeType ::= { id-at 42 }
id-at-initials AttributeType ::= { id-at 43 }
id-at-generationQualifier AttributeType ::= { id-at 44 }
-- Naming attributes of type X520Name:
-- X520name ::= DirectoryString (SIZE (1..ub-name))
--
-- Expanded to avoid parameterized type:
X520name ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-name)),
printableString PrintableString (SIZE (1..ub-name)),
universalString UniversalString (SIZE (1..ub-name)),
utf8String UTF8String (SIZE (1..ub-name)),
bmpString BMPString (SIZE (1..ub-name)) }
-- Naming attributes of type X520CommonName
id-at-commonName AttributeType ::= { id-at 3 }
-- Naming attributes of type X520CommonName:
-- X520CommonName :== DirectoryName (SIZE (1..ub-common-name))
--
-- Expanded to avoid parameterized type:
X520CommonName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-common-name)),
printableString PrintableString (SIZE (1..ub-common-name)),
universalString UniversalString (SIZE (1..ub-common-name)),
utf8String UTF8String (SIZE (1..ub-common-name)),
bmpString BMPString (SIZE (1..ub-common-name)) }
The following paragraph is proposed for inclusion in Appendix B:
For many of the attribute types defined in [X.520], the
AttributeValue uses
the DirectoryString type. Of the attributes specified in Appendix
A, the name,
surname, givenName, initials, generationQualifier, commonName,
localityName,
stateOrProvinceName, organizationName, organizationalUnitName,
title, and
pseudonym attributes all use the DirectoryString type. X.520 uses
a parameterized
type definition [X.683] of DirectoryString to specify the syntax
for each of these
attributes. The parameter is used to indicate the maximum string
length allowed for
the attribute. In Appendix A, in order to avoid the use of
parameterized type
definitions, the DirectoryString type written in its expanded form
for the definition
of each of these attribute types. So, the ASN.1 in Appendix A
describes the syntax
for each of these attributes as being a CHOICE of TeletexString,
PrintableString,
UniversalString, UTF8String, and BMPString, with the appropriate
constraints on
the string length applied to each of types in the CHOICE, rather
than using the
ASN.1 type DirectoryString to describe the syntax.
Received: from easilink.com (host-84-222-144-112.cust-adsl.tiscali.it [84.222.144.112]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7PKDut9092936 for ; Fri, 25 Aug 2006 13:14:16 -0700 (MST) (envelope-from nereui@jugglers.com)
Received: by 192.168.90.58 with SMTP id CijtAA; for ; Fri, 25 Aug 2006 13:14:00 -0700
Message-ID: <000001c6c883$008bf100$3a5aa8c0@pinlb>
Reply-To: "Egil Rundle"
From: "Egil Rundle"
To: ietf-pkix-archive@imc.org
Subject: Re: RXdaqy
Date: Fri, 25 Aug 2006 13:14:00 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C848.542F62F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6C848.542F62F0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
Goo z d news for you.
=20
PHA l RM t ACY di y rectl i y from the ma n nu n factu w rer,
Ec t onom d ize up n to 6 p 0 % wit h h us http://qasedaxecin.com
, z=20
, o=20
, h=20
Indeed? I snorted through widened nostrils. Rather short on
education, particularly a knowledge of Esperanto, arent we? If you
must know, speaking in the vulgar argot of this planet-I was told that
------=_NextPart_000_0001_01C6C848.542F62F0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
Goo z d news for you.
PHA l RM t ACY di y rectl i y from the ma n nu n factu w rer,
, z
, o
, h
Indeed? I snorted through =
widened nostrils. Rather short on
education, particularly a knowledge of Esperanto, arent we? If =
you
must know, speaking in the vulgar argot of this planet-I was told =
that
------=_NextPart_000_0001_01C6C848.542F62F0--
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7ONm7LJ055247; Thu, 24 Aug 2006 16:48:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7ONm7UN055246; Thu, 24 Aug 2006 16:48:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host.eb2bcom.com (eb2bcom.com [72.232.34.10] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7ONm3cV055228 for ; Thu, 24 Aug 2006 16:48:06 -0700 (MST) (envelope-from steven.legg@eb2bcom.com)
Received: from [203.206.165.210] (helo=[192.168.1.156]) by host.eb2bcom.com with esmtpa (Exim 4.52) id 1GGOvV-0001hW-Ki; Fri, 25 Aug 2006 09:47:57 +1000
Message-ID: <44EE3AA9.80708@eb2bcom.com>
Date: Fri, 25 Aug 2006 09:47:53 +1000
From: Steven Legg
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper"
CC: pkix
Subject: Re: Inconsistencies between RFC 3280 and X.509/X.520
References: <44EE1D32.8080608@nist.gov>
In-Reply-To: <44EE1D32.8080608@nist.gov>
Content-Type: text/plain; charset=us-ascii; 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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
David,
The annex of X.520 in which ub-name and the other upper bounds are defined has
always been non-normative. The particular values to which the upper bounds are
set are merely suggestions, and implementations are free to set whatever upper
bounds they like. Thus RFC 3280 is not incorrect in setting ub-name to
something other than 64.
Regards,
Steven
David A. Cooper wrote:
>
> All,
>
> In researching the confusion related to RFC 3280's description of the
> encoding of attributes that use the DirectoryString type, I encountered
> two places in the ASN.1 modules in RFC 3280 (and 3280bis) that are
> inconsistent with either X.509 or X.520. (I have not thoroughly
> compared these documents, so I cannot guarantee that there are not any
> other inconsistencies.)
>
> First, in X.520 the value of ub-name is 64 whereas in RFC 3280 the value
> of ub-name is 32768. ub-name is used to specify the maximum length of
> the following attributes: name, surname, givenName, initial, and
> generationQualifier.
>
> Second, X.509 defines EDIParty as:
>
> EDIPartyName ::= SEQUENCE {
> nameAssigner [0] DirectoryString {ub-name} OPTIONAL,
> partyName [1] DirectoryString {ub-name} }
>
> whereas RFC 3280 defines EDIParty as
>
> EDIPartyName ::= SEQUENCE {
> nameAssigner [0] DirectoryString OPTIONAL,
> partyName [1] DirectoryString }
>
> So, in X.509 there is a size constraint on both the nameAssigner and
> partyName strings (they must be between 1 and 64 characters). In RFC
> 3280, there is no constraint on the length of the strings.
>
> I would like to modify 3280bis so that it is consistent with X.509 and
> X.520. However, since the ASN.1 that appears in 3280bis is the same as
> the ASN.1 in RFC 3280 and RFC 2459, I want to ensure that changing these
> items to be consistent with X.509 and X.520 will not cause any backwards
> compatibility issues.
>
> So, I would like to know if changing the ASN.1 in 3280bis would cause
> problems for any existing implementations. For example, if there are
> systems that use the attributes mentioned above with string lengths that
> violate length constraints in X.520.
>
> Thanks,
>
> Dave
>
>
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7ON0Lqq051889; Thu, 24 Aug 2006 16:00:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7ON0LLl051887; Thu, 24 Aug 2006 16:00:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7ON0KGJ051802 for ; Thu, 24 Aug 2006 16:00:21 -0700 (MST) (envelope-from chokhani@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C7D1.0E098FD0"
Subject: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
Date: Thu, 24 Aug 2006 16:00:09 -0700
Message-ID: <82D5657AE1F54347A734BDD33637C8790449215A@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
Thread-Index: AcbH0QwdbSkSpm4wQjGILp865sH6UA==
From: "Santosh Chokhani"
To:
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
This is a multi-part message in MIME format.
------_=_NextPart_001_01C6C7D1.0E098FD0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
All,
=20
The new version of X.509 (2005 Edition) permits initial values other
than infinity and null for permitted and excluded subtrees respectively.
=20
Should we also revise 3280Bis to include these options so that the
relying parties can constrain the trust anchors?
=20
I would consider infinity and null values only for the two respective
fields still compliant with the applicable standard.
=20
Thanks in advance for your opinion.
Santosh Chokhani=20
Orion Security Solutions, Inc.=20
1489 Chain Bridge Road, Suite 300=20
McLean, Virginia 22101=20
(703) 917-0060 Ext. 35 (voice)=20
(703) 917-0260 (Fax)=20
chokhani@orionsec.com=20
Visit our Web site=20
http://www.orionsec.com =20
=20
------_=_NextPart_001_01C6C7D1.0E098FD0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
All,
The
new version of X.509 (2005 Edition) permits initial values other than =
infinity
and null for permitted and excluded subtrees =
respectively.
Should
we also revise 3280Bis to include these options so that the relying =
parties can
constrain the trust anchors?
I
would consider infinity and null values only for the two respective =
fields
still compliant with the applicable =
standard.
Thanks
in advance for your opinion.
Santosh =
Chokhani
Orion
Security Solutions, Inc.
1489 Chain Bridge Road, =
Suite 300
McLean, Virginia
22101
(703)
917-0060 =
Ext. =
35 (voice)
(703)
917-0260
(Fax)
chokhani@orionsec.com =
Visit
our Web site
http://www.orionsec.com
------_=_NextPart_001_01C6C7D1.0E098FD0--
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7OLg1vp042993; Thu, 24 Aug 2006 14:42:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7OLg1AH042992; Thu, 24 Aug 2006 14:42:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7OLg099042983 for ; Thu, 24 Aug 2006 14:42:01 -0700 (MST) (envelope-from david.cooper@nist.gov)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k7OLfv9N015442 for ; Thu, 24 Aug 2006 17:41:57 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id k7OLfRJB015352 for ; Thu, 24 Aug 2006 17:41:27 -0400 (EDT)
Message-ID: <44EE1D32.8080608@nist.gov>
Date: Thu, 24 Aug 2006 17:42:10 -0400
From: "David A. Cooper"
User-Agent: Thunderbird 1.5.0.5 (X11/20060817)
MIME-Version: 1.0
To: pkix
Subject: Inconsistencies between RFC 3280 and X.509/X.520
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
All,
In researching the confusion related to RFC 3280's description of the
encoding of attributes that use the DirectoryString type, I encountered
two places in the ASN.1 modules in RFC 3280 (and 3280bis) that are
inconsistent with either X.509 or X.520. (I have not thoroughly
compared these documents, so I cannot guarantee that there are not any
other inconsistencies.)
First, in X.520 the value of ub-name is 64 whereas in RFC 3280 the value
of ub-name is 32768. ub-name is used to specify the maximum length of
the following attributes: name, surname, givenName, initial, and
generationQualifier.
Second, X.509 defines EDIParty as:
EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString {ub-name} OPTIONAL,
partyName [1] DirectoryString {ub-name} }
whereas RFC 3280 defines EDIParty as
EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString OPTIONAL,
partyName [1] DirectoryString }
So, in X.509 there is a size constraint on both the nameAssigner and
partyName strings (they must be between 1 and 64 characters). In RFC
3280, there is no constraint on the length of the strings.
I would like to modify 3280bis so that it is consistent with X.509 and
X.520. However, since the ASN.1 that appears in 3280bis is the same as
the ASN.1 in RFC 3280 and RFC 2459, I want to ensure that changing these
items to be consistent with X.509 and X.520 will not cause any backwards
compatibility issues.
So, I would like to know if changing the ASN.1 in 3280bis would cause
problems for any existing implementations. For example, if there are
systems that use the attributes mentioned above with string lengths that
violate length constraints in X.520.
Thanks,
Dave
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7OLK49a041147; Thu, 24 Aug 2006 14:20:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7OLK4OU041146; Thu, 24 Aug 2006 14:20:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7OLK3ks041139 for ; Thu, 24 Aug 2006 14:20:04 -0700 (MST) (envelope-from david.cooper@nist.gov)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k7OLJuSN004341 for ; Thu, 24 Aug 2006 17:19:57 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id k7OLJ5H0007021 for ; Thu, 24 Aug 2006 17:19:05 -0400 (EDT)
Message-ID: <44EE17F4.5060403@nist.gov>
Date: Thu, 24 Aug 2006 17:19:48 -0400
From: "David A. Cooper"
User-Agent: Thunderbird 1.5.0.5 (X11/20060817)
MIME-Version: 1.0
To: pkix
Subject: Confusion about encoding of attributes that use the DirectoryString type
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
All,
It has come to the 3280bis design team's attention that there has been
considerable confusing with respect the the rules in RFC 3280 (and
3280bis) about the choice of string type to use when encoding attributes
of type DirectoryString. The source of the confusion is the syntax used
in Appendix A of RFC 3280 (and 3280bis) to describe attributes that use
the DirectoryString encoding. For example, the common name attribute
appears in Appendix A as:
-- Naming attributes of type X520CommonName
id-at-commonName AttributeType ::= { id-at 3 }
X520CommonName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-common-name)),
printableString PrintableString (SIZE (1..ub-common-name)),
universalString UniversalString (SIZE (1..ub-common-name)),
utf8String UTF8String (SIZE (1..ub-common-name)),
bmpString BMPString (SIZE (1..ub-common-name)) }
The editors of RFC 3280 (and RFC 2459) chose to use this syntax so that
the size constraints could be included in the ASN.1 without the need to
use a parameterized type definition. The X.520 definition of
DirectoryString includes a parameter that can be used to specify the
maximum allowable string length and the definition of each attribute
instantiates that parameter with the maximum allowable string length for
that attribute. Since not all ASN.1 compilers can process parameterized
type definitions, the PKIX profile uses the syntax show above, which has
the same encoding and semantics as the syntax used in X.520 but is
easier for ASN.1 compilers to process.
The problem with the syntax used in Appendix A of RFC 3280 is that the
word "DirectoryString" does not appear. So, many people were unaware
that attributes such as common name used the DirectoryString type and so
did not know that the rules in section 4.1.2.4 for the encoding of
attributes that used the DirectoryString type applied to these attributes.
The 3280bis design team has discussed this issue and agrees that the
ASN.1 in Appendix A should not be changed since using the syntax from
X.520 would result in incompatibility with some ASN.1 compilers.
Instead, the design team recommends adding comments into the ASN.1
module prior to the definition of each attribute that uses the
DirectoryString type that clarifies that the attribute uses the
DirectoryString type. A new paragraph can also be added to Appendix B
(ASN.1 Notes) explaining the situation.
Below is a portion of Appendix A with additional comments added for the
attributes types shown as well as the new paragraph proposed for Appendix B.
-- Naming attributes of type X520name
id-at-name AttributeType ::= { id-at 41 }
id-at-surname AttributeType ::= { id-at 4 }
id-at-givenName AttributeType ::= { id-at 42 }
id-at-initials AttributeType ::= { id-at 43 }
id-at-generationQualifier AttributeType ::= { id-at 44 }
-- Naming attributes of type X520Name:
-- X520name ::= DirectoryString (SIZE (1..ub-name))
--
-- Expanded to avoid parameterized type:
X520name ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-name)),
printableString PrintableString (SIZE (1..ub-name)),
universalString UniversalString (SIZE (1..ub-name)),
utf8String UTF8String (SIZE (1..ub-name)),
bmpString BMPString (SIZE (1..ub-name)) }
-- Naming attributes of type X520CommonName
id-at-commonName AttributeType ::= { id-at 3 }
-- Naming attributes of type X520CommonName:
-- X520CommonName :== DirectoryName (SIZE (1..ub-common-name))
--
-- Expanded to avoid parameterized type:
X520CommonName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-common-name)),
printableString PrintableString (SIZE (1..ub-common-name)),
universalString UniversalString (SIZE (1..ub-common-name)),
utf8String UTF8String (SIZE (1..ub-common-name)),
bmpString BMPString (SIZE (1..ub-common-name)) }
The following paragraph is proposed for inclusion in Appendix B:
For many of the attribute types defined in [X.520], the
AttributeValue uses
the DirectoryString type. Of the attributes specified in Appendix
A, the name,
surname, givenName, initials, generationQualifier, commonName,
localityName,
stateOrProvinceName, organizationName, organizationalUnitName,
title, and
pseudonym attributes all use the DirectoryString type. X.520 uses
a parameterized
type definition [X.683] of DirectoryString to specify the syntax
for each of these
attributes. The parameter is used to indicate the maximum string
length allowed for
the attribute. In Appendix A, in order to avoid the use of
parameterized type
definitions, the DirectoryString type written in its expanded form
for the definition
of each of these attribute types. So, the ASN.1 in Appendix A
describes the syntax
for each of these attributes as being a CHOICE of TeletexString,
PrintableString,
UniversalString, UTF8String, and BMPString, with the appropriate
constraints on
the string length applied to each of types in the CHOICE, rather
than using the
ASN.1 type DirectoryString to describe the syntax.
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NGQHtw044508; Wed, 23 Aug 2006 09:26:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7NGQHjF044507; Wed, 23 Aug 2006 09:26:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NGQDBj044499 for ; Wed, 23 Aug 2006 09:26:16 -0700 (MST) (envelope-from julien.stern@cryptolog.com)
Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 66AEB40E85 for ; Wed, 23 Aug 2006 18:26:11 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 43F204413D for ; Wed, 23 Aug 2006 18:26:21 +0200 (CEST)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07475-02 for ; Wed, 23 Aug 2006 18:25:50 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 7358C44006 for ; Wed, 23 Aug 2006 18:25:49 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 23 Aug 2006 18:25:40 +0200
From: "Julien Stern"
Date: Wed, 23 Aug 2006 18:25:40 +0200
To: ietf-pkix@imc.org
Subject: Re: Clarifications on SubjectAltNameExtension handling in RFC3280 / X509
Message-ID: <20060823162539.GK5344@cryptolog.com>
Mail-Followup-To: Julien Stern , ietf-pkix@imc.org
References: <20060823123839.GE5344@cryptolog.com> <44EC7319.7020804@nist.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44EC7319.7020804@nist.gov>
User-Agent: Mutt/1.5.6+20040907i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
David,
many thanks for your prompt and clear replies.
A few more question are in-line.
Regards,
--
Julien
On Wed, Aug 23, 2006 at 11:24:09AM -0400, David A. Cooper wrote:
> Julien,
>
> See responses in-line.
>
> Dave
>
> Julien Stern wrote:
> >Folks,
> >
> >Sorry to bother if the topic is very familiar to some of you,
> >but I failed to find definitive answers in the RFCs or in X.509.
> >
> >I'd be quite interested to have some clarifications regarding
> >the handling of entity names in RFC3280 (or sonof) and X.509.
>
> [snipped crystal clear explanation on entity names]
> >Also, do RFC3280 and X.509 really have the same semantic on that matter?
> >Is RFC3280 putting additional constraints (Trust Anchors?) on the match?
>
> There is no difference between RFC 3280 and X.509 on this matter.
> 3280bis does impose the constraint that a certification path and the
> path used to validate a CRL that provides status information for a
> certificate in the path begin with the same trust anchor. This rule was
> included in 3280bis to protect against the risk that two different
> entities might issue certificates and/or CRLs under the same name. This
> would be a violation of both 3280bis and X.509, since it would violate
> the rule that any name within a PKI unambiguously identity one entity,
> but there is no way (other than by vigilance) to ensure that it won't
> happen. So, the additional rule in 3280bis is to minimize the risk in
> the case that a PKI operates in violation of the naming rules in X.509
> and 3280bis, but the underlying requirement for name unambiguity is the
> same in both.
OK. Found. Point 6.3.3 (f) of 3280bis.
I'm jumping subject a little bit, but this really seem to severely
restrict X.509 on two points:
- Section 8.1.5, last paragraph where it is explicitely mentionned
that an entity can choose to have two different trust anchors for
Certificate and CRL signing
- All the indirect CRL framework (not necessarily as they could
still chain, but likely)
Wouldn't it be better to only ask that they chain up to Trust Anchors
that have the same name instead?
> [snipped questions on chaining]
> >* When figuring out whether a CRL should be direct or indirect
> >are we supposed to take into account the SubjectAltNameExtension?
> >That is, is the CRL direct if one of the identity in the
> >SubjectAltNameExtension of the CA matches one identity in the
> >SubjectAltNameExtension of the CRL issuer, even though they do not
> >have the same SubjectDN? Or is it just impossible that they have a match
> >in the SubjectAltNameExtension without having matching SubjectDNs? What
> >if one of the SubjectDN is empty? Or both?
> >
> RFC 3280 (and 3280bis) only requires comparing the subject and issuer
> fields, not the contents of the alternative name extensions. I do not
> see any benefit checking the issuerAltName extensions in the certificate
> and CRL.
Well, I wondered about this point because of the wording of X.509:
B.5.1.4
If the cRLIssuer field is present in the relative extension (CRL
distribution point or freshest CRL extension) of the certificate, the
CRL shall be signed by the CRL Issuer identified in the CRL distribution
point extension or freshest CRL extension of the certificate and the CRL
shall contain the indirectCRL field in the issuing distribution point
extension.
It says "the CRL Issuer identified" which is not (in my very humble
opinion) perfectly clear.
RFC3280bis says:
6.3.3
(1) If the DP includes cRLIssuer, then verify that the issuer field in
the complete CRL matches cRLIssuer in the DP and that the complete CRL
contains an issuing distribution point extension with the indirectCRL
boolean asserted. Otherwise, verify that the CRL issuer matches the
certificate issuer.
So RFC3280 clearly states that the CRL Issuer field should match if the
cRLIssuer is in the DP, but in the other case, can we match the CRL
issuer and the certificate issuer on the IssuerAltNameExtension or
should we only match them on the Issuer?
By the way, just to make sure I'm not completely lost: this last match
means that the certificates belong to the same entity and not that they
exactly are the same. Right?
> [snipped question on criticality]
To summarize:
1) When we chain, we only consider SubjectDN and IssuerDN. Period.
2) in RFC3280 (and son), a SubjectDN of a non-EE cannot be empty,
therefore, a IssuerDN can never be empty
3) So, The only remaining issue I have is: whenever the RFC says
that we should have a match between two issuers, does this mean that
they should have the same SubjectDN or can/should we also check the
SubjectAltNameExtension ?
Like in these three snippets from 3280bis:
-----
5.2.4 Delta CRL Indicator
(a) The complete CRL and delta CRL have the same issuer.
-----
6.3.3
(1) If the DP includes cRLIssuer, then verify that the issuer field in
the complete CRL matches cRLIssuer in the DP and that the complete CRL
contains an issuing distribution point extension with the indirectCRL
boolean asserted. Otherwise, verify that the CRL issuer matches the
certificate issuer.
-----
6.3.3
(c) If use-deltas is set, verify the issuer and scope of the
delta CRL as follows:
(1) Verify that the delta CRL issuer matches complete CRL
issuer.
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NFNmqt036754; Wed, 23 Aug 2006 08:23:48 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7NFNm81036753; Wed, 23 Aug 2006 08:23:48 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NFNk5E036747 for ; Wed, 23 Aug 2006 08:23:47 -0700 (MST) (envelope-from david.cooper@nist.gov)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k7NFNc6W023182; Wed, 23 Aug 2006 11:23:39 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id k7NFNUsH023729; Wed, 23 Aug 2006 11:23:30 -0400 (EDT)
Message-ID: <44EC7319.7020804@nist.gov>
Date: Wed, 23 Aug 2006 11:24:09 -0400
From: "David A. Cooper"
User-Agent: Thunderbird 1.5.0.5 (X11/20060804)
MIME-Version: 1.0
To: Julien Stern , ietf-pkix@imc.org
Subject: Re: Clarifications on SubjectAltNameExtension handling in RFC3280 / X509
References: <20060823123839.GE5344@cryptolog.com>
In-Reply-To: <20060823123839.GE5344@cryptolog.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Julien,
See responses in-line.
Dave
Julien Stern wrote:
> Folks,
>
> Sorry to bother if the topic is very familiar to some of you,
> but I failed to find definitive answers in the RFCs or in X.509.
>
> I'd be quite interested to have some clarifications regarding
> the handling of entity names in RFC3280 (or sonof) and X.509.
>
> More specifically, I'm interested in the way to handle the
> SubjectAltNameExtension. This extension allows to give several
> alternative names to an entity.
>
> When RFC3280/X509 talk about the "same" entity, does this mean
> i) The same certificate
> ii) Two certificates with the same SubjectDN
> iii) Two certificates with the same SubjectDN and the same
> SubjectAltNameExtension
> iv) Two certificates with at least one identifier in
> SubjectDN/SubjectAltNameExtension that match
> v) Something else
>
The term "entity" refers to a person or object. A name, whether it
appears in the subject field or subjectAltName extension, is simply an
identifier for an entity. Here is what X.509 says in clause 8.3.2.1
(Subject alternative name extension):
For every name form used in the GeneralName type, there shall be a
name registration
system that ensures that any name used unambiguously identifies one
entity to both
certificate issuer and certificate users.
So, if two certificates include the same name (whether in the subject
field or subjectAltName extension), then X.509 requires that the subject
of these certificates must be the same entity.
> Also, do RFC3280 and X.509 really have the same semantic on that matter?
> Is RFC3280 putting additional constraints (Trust Anchors?) on the match?
>
There is no difference between RFC 3280 and X.509 on this matter.
3280bis does impose the constraint that a certification path and the
path used to validate a CRL that provides status information for a
certificate in the path begin with the same trust anchor. This rule was
included in 3280bis to protect against the risk that two different
entities might issue certificates and/or CRLs under the same name. This
would be a violation of both 3280bis and X.509, since it would violate
the rule that any name within a PKI unambiguously identity one entity,
but there is no way (other than by vigilance) to ensure that it won't
happen. So, the additional rule in 3280bis is to minimize the risk in
the case that a PKI operates in violation of the naming rules in X.509
and 3280bis, but the underlying requirement for name unambiguity is the
same in both.
> Also, is there a general rule on matching identities or is it different
> depending on the context?
>
I believe that X.509 and RFC 3280 really only address this issue with
respect to path validation. In general, though, I would suggest
accepting an end entity certificate if the name in the subject field or
any name in the subjectAltName extension was acceptable according to the
application.
> Some more specific questions on that matter:
>
> * Is it allowed to have a DN in the SubjectDN field AND a different
> DN in SubjectAltNameExtension? If so, should we check both for name
> equality?
>
A certificate may have a DN in both places. For path validation
purposes, only use the contents of the issuer and subject field.
> * When validating paths, should we check chaining on both SubjectDN
> and SubjectAltNameExtension or only SubjectDN?
>
Only the subject DN.
> * When both SubjectDN are empty, how do we chain certificates?
> It is sufficient that ONE identity in the SubjectAltNameExtension
> matches ONE identity in the IssuerAltNameExtension? Or should ALL
> identities match?
>
Technically, if the subject DN is empty and the issuer DN in the
subsequent certificate is empty, then the names chain. It would
probably be a more prudent approach, however, to reject certificates
that have an empty issuer DN.
> * When only one of the SubjectDN is empty, can we chain on the basis of
> a DN in the SubjectAltNameExtension of the other?
>
No.
> * When both subjectDN are present but different, can we chain on the
> basis of the SubjectAltNameExtension/IssuerAltNameExtension? Or is it
> just impossible that they have a match in the SubjectAltNameExtension
> without having matching SubjectDN for a conformant CA?
>
No. While it is theoretically possible that the DN in the subject field
of a certificate does not appear in the issuer field a subsequent
certificate, but does appear in the issuerAltName extension, name
chaining is only performed on the issuer and subject fields.
> * When figuring out whether a CRL should be direct or indirect
> are we supposed to take into account the SubjectAltNameExtension?
> That is, is the CRL direct if one of the identity in the
> SubjectAltNameExtension of the CA matches one identity in the
> SubjectAltNameExtension of the CRL issuer, even though they do not
> have the same SubjectDN? Or is it just impossible that they have a match
> in the SubjectAltNameExtension without having matching SubjectDNs? What
> if one of the SubjectDN is empty? Or both?
>
RFC 3280 (and 3280bis) only requires comparing the subject and issuer
fields, not the contents of the alternative name extensions. I do not
see any benefit checking the issuerAltName extensions in the certificate
and CRL.
> * Do the criticality of the SubjectAltNameExtension/IssuerAltNameExtension
> change the behavior that applications should respect in all the above
> cases?
>
I don't think so. Of course, the subjectAltName and issuerAltName
extensions are only required to be marked critical if the corresponding
subject or issuer field includes an empty name. Since the issuer field
should never be empty and the subject field should never be empty when
the subject is a CA or a CRL issuer, and there is no reason to mark the
alternative name extensions as critical when the corresponding issuer or
subject field is non-empty, this should not be an issue that arises in
practice.
> Thank you very much for any insight.
>
> --
> Julien
>
>
>
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NCco1v012040; Wed, 23 Aug 2006 05:38:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7NCco5k012039; Wed, 23 Aug 2006 05:38:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mallaury.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NCclqV011998 for ; Wed, 23 Aug 2006 05:38:49 -0700 (MST) (envelope-from julien.stern@cryptolog.com)
Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by mallaury.nerim.net (Postfix) with ESMTP id 7F69F4F414 for ; Wed, 23 Aug 2006 14:38:37 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 63E794413D for ; Wed, 23 Aug 2006 14:38:54 +0200 (CEST)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05639-09 for ; Wed, 23 Aug 2006 14:38:50 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 625F444006 for ; Wed, 23 Aug 2006 14:38:49 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 23 Aug 2006 14:38:40 +0200
From: "Julien Stern"
Date: Wed, 23 Aug 2006 14:38:40 +0200
To: ietf-pkix@imc.org
Subject: Clarifications on SubjectAltNameExtension handling in RFC3280 / X509
Message-ID: <20060823123839.GE5344@cryptolog.com>
Mail-Followup-To: Julien Stern , ietf-pkix@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6+20040907i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Folks,
Sorry to bother if the topic is very familiar to some of you,
but I failed to find definitive answers in the RFCs or in X.509.
I'd be quite interested to have some clarifications regarding
the handling of entity names in RFC3280 (or sonof) and X.509.
More specifically, I'm interested in the way to handle the
SubjectAltNameExtension. This extension allows to give several
alternative names to an entity.
When RFC3280/X509 talk about the "same" entity, does this mean
i) The same certificate
ii) Two certificates with the same SubjectDN
iii) Two certificates with the same SubjectDN and the same
SubjectAltNameExtension
iv) Two certificates with at least one identifier in
SubjectDN/SubjectAltNameExtension that match
v) Something else
Also, do RFC3280 and X.509 really have the same semantic on that matter?
Is RFC3280 putting additional constraints (Trust Anchors?) on the match?
Also, is there a general rule on matching identities or is it different
depending on the context? Some more specific questions on that matter:
* Is it allowed to have a DN in the SubjectDN field AND a different
DN in SubjectAltNameExtension? If so, should we check both for name
equality?
* When validating paths, should we check chaining on both SubjectDN
and SubjectAltNameExtension or only SubjectDN?
* When both SubjectDN are empty, how do we chain certificates?
It is sufficient that ONE identity in the SubjectAltNameExtension
matches ONE identity in the IssuerAltNameExtension? Or should ALL
identities match?
* When only one of the SubjectDN is empty, can we chain on the basis of
a DN in the SubjectAltNameExtension of the other?
* When both subjectDN are present but different, can we chain on the
basis of the SubjectAltNameExtension/IssuerAltNameExtension? Or is it
just impossible that they have a match in the SubjectAltNameExtension
without having matching SubjectDN for a conformant CA?
* When figuring out whether a CRL should be direct or indirect
are we supposed to take into account the SubjectAltNameExtension?
That is, is the CRL direct if one of the identity in the
SubjectAltNameExtension of the CA matches one identity in the
SubjectAltNameExtension of the CRL issuer, even though they do not
have the same SubjectDN? Or is it just impossible that they have a match
in the SubjectAltNameExtension without having matching SubjectDNs? What
if one of the SubjectDN is empty? Or both?
* Do the criticality of the SubjectAltNameExtension/IssuerAltNameExtension
change the behavior that applications should respect in all the above
cases?
Thank you very much for any insight.
--
Julien
Received: from avlis.com (adsl-d6.87-197-223.t-com.sk [87.197.223.6]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7NAb6lO090981 for ; Wed, 23 Aug 2006 03:37:11 -0700 (MST) (envelope-from heddenliviana@hksinc.com)
Received: by 192.168.123.70 with SMTP id hOxWZqB; for ; Wed, 23 Aug 2006 03:37:00 -0700
Message-ID: <000001c6c6a0$10bfcc70$467ba8c0@jfvji>
Reply-To: "Ashlee Sumrall"
From: "Ashlee Sumrall"
To: ietf-pkix-archive@imc.org
Subject: Re: new la
Date: Wed, 23 Aug 2006 03:37:00 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C665.6460F470"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6C665.6460F470
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
=20
Not very good erecxction? You are welcome - http://tarinmdesinkepa.com
=20
=20
=20
toenails or they were naturally rusty. I let it pass since there were
a lot more things I would like to know first.
All here in Paradise were possessed of a great depression when you
------=_NextPart_000_0001_01C6C665.6460F470
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
<=
P>
toenails or they were naturally =
rusty. I let it pass since there were
a lot more things I would like to know first.
All here in Paradise were possessed of a great depression when =
you
------=_NextPart_000_0001_01C6C665.6460F470--
Received: from xwebb.org ([203.98.72.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7N8RDcZ071302; Wed, 23 Aug 2006 01:27:14 -0700 (MST) (envelope-from powerseller@ebay.com)
Received: from User (bne102dsb.server-web.com [203.32.9.107]) by xwebb.org (Postfix) with ESMTP id BEB832391A7; Wed, 23 Aug 2006 16:05:32 +1000 (EST)
Reply-To:
From: "eBay PowerSeller"
Subject: You're a Silver PowerSeller Now!
Date: Wed, 23 Aug 2006 16:05:40 +1000
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-Id: <20060823060532.BEB832391A7@xwebb.org>
To: undisclosed-recipients:;
Received: from foglefineart.com (ADijon-151-1-171-220.w86-218.abo.wanadoo.fr [86.218.177.220]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7KDMJgg035795 for ; Sun, 20 Aug 2006 06:22:27 -0700 (MST) (envelope-from kearse@dmdd.com)
Received: by 192.168.251.125 with SMTP id rTAVddpDQ; for ; Sun, 20 Aug 2006 06:22:28 -0700
Message-ID: <000001c6c45b$aeedb5c0$7dfba8c0@fqxv>
Reply-To: "Dominic Kauffman"
From: "Dominic Kauffman"
To: ietf-pkix-archive@imc.org
Subject: Re: tuaemu test
Date: Sun, 20 Aug 2006 06:22:28 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C421.028EDDC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6C421.028EDDC0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
=20
It is so common to have problems with erxection,=20
Try VlxAGRA to forget about it http://www.vuheranimersa.com
=20
=20
=20
Then, armed only with my innocence, I retraced my course back down the
stairs and on to the ground floor.
The door opened and closed silently and there was a guard, back
------=_NextPart_000_0001_01C6C421.028EDDC0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
It is so common to have problems with erxection,
Try VlxAGRA =
to forget about it
http://www.vuheranimersa.com
Then, armed only with my =
innocence, I retraced my course back down the
stairs and on to the ground floor.
The door opened and closed silently and there was a guard, =
back
------=_NextPart_000_0001_01C6C421.028EDDC0--
Received: from chicano.org (dslb-084-060-016-252.pools.arcor-ip.net [84.60.16.252]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7K247u8086545 for
; Sat, 19 Aug 2006 19:04:11 -0700 (MST) (envelope-from manfredoe@inmantexas.com)
Received: by 192.168.53.171 with SMTP id yGOtKPk; for ; Sat, 19 Aug 2006 19:04:17 -0700
Message-ID: <000001c6c3fc$f144a320$ab35a8c0@fxxoagg>
Reply-To: "Janae Mace"
From: "Janae Mace"
To: ietf-pkix-archive@imc.org
Subject: Re: gecide test
Date: Sat, 19 Aug 2006 19:04:17 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C3C2.44E5CB20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6C3C2.44E5CB20
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
=20
It is so common to have problems with erxection,=20
Try VlxAGRA to forget about it http://www.priokoliondedsa.com
=20
=20
=20
figures. Chances of an accidental explosion; zero. Chances that the
explosion was tied in with the theft; sixty-seven percent. What
happens next depends upon you.
------=_NextPart_000_0001_01C6C3C2.44E5CB20
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
figures. Chances of an =
accidental explosion; zero. Chances that the
explosion was tied in with the theft; sixty-seven percent. =
What
happens next depends upon you.
------=_NextPart_000_0001_01C6C3C2.44E5CB20--
Received: from feeny.com (dsl.dynamic85100203136.ttnet.net.tr [85.100.203.136] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7JGSBpk074441 for ; Sat, 19 Aug 2006 09:28:16 -0700 (MST) (envelope-from mosu@hooked.com)
Received: by 192.168.162.220 with SMTP id SdlgDGFZ; for ; Sat, 19 Aug 2006 09:28:23 -0700
Message-ID: <000001c6c3ac$7d9006e0$dca2a8c0@tutbt>
Reply-To: "Gustaf Navarre"
From: "Gustaf Navarre"
To: ietf-pkix-archive@imc.org
Subject: Re: kigyme test
Date: Sat, 19 Aug 2006 09:28:23 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C371.D1312EE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6C371.D1312EE0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
=20
It is so common to have problems with erxection,=20
Try VlxAGRA to forget about it http://www.guheranminkewan.com
=20
=20
=20
I dont believe you! I snapped.
His smile was without warmth. Then why dont you just hang around
and find out?
------=_NextPart_000_0001_01C6C371.D1312EE0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
I dont believe you! I =
snapped.
His smile was without warmth. Then why dont you just hang around
and find out?
------=_NextPart_000_0001_01C6C371.D1312EE0--
Received: from comsol.com (dyn-88-123-62-221.ppp.tiscali.fr [88.123.62.221] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7J5V1Z3051832 for ; Fri, 18 Aug 2006 22:31:06 -0700 (MST) (envelope-from duhart@brandes-assoc.com)
Received: by 192.168.197.248 with SMTP id ODLExcCd; for ; Fri, 18 Aug 2006 22:30:59 -0700
Message-ID: <000001c6c350$a73f2090$f8c5a8c0@ldmn>
Reply-To: "Eleazar Pettry"
From: "Eleazar Pettry"
To: ietf-pkix-archive@imc.org
Subject: Re: jo test
Date: Fri, 18 Aug 2006 22:30:59 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C315.FAE04890"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6C315.FAE04890
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
=20
It is so common to have problems with erecxxtion,=20
Try VIrAGRA and forget about it http://www.crionmdesacinker.com
=20
=20
=20
eat them where they touch the cuticle. Which means that the power is
always on. Anytime you are outside or in a building with thin floors-
your signal zips up to the satellite and back down to the other
------=_NextPart_000_0001_01C6C315.FAE04890
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
eat them where they =
touch the cuticle. Which means that the power is
always on. Anytime you are outside or in a building with thin =
floors-
your signal zips up to the satellite and back down to the =
other
------=_NextPart_000_0001_01C6C315.FAE04890--
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7GMgbDi062453; Wed, 16 Aug 2006 15:42:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7GMgbsl062452; Wed, 16 Aug 2006 15:42:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.204]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7GMgYqL062444 for ; Wed, 16 Aug 2006 15:42:37 -0700 (MST) (envelope-from openmacnews@gmail.com)
Received: by nz-out-0102.google.com with SMTP id 13so398389nzp for ; Wed, 16 Aug 2006 15:42:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=I/0QQ59Pj4MNifJ9jkH3IDpa2jbTAeqvxcsiIR7vsT2QgNOhiZw1hSUF+FoOPqQ3fYNDglMsKJKC79pXwBLyAzeDkdeeJIZQFIoRw6bKNuHX8CVVZwSz9CO9B10uWrXaXVxzSFGsW0S19ioP9lrShkh9s+flPByc/+k/mXZ2CiI=
Received: by 10.65.114.11 with SMTP id r11mr1443667qbm; Wed, 16 Aug 2006 15:42:34 -0700 (PDT)
Received: from ?172.30.11.6? ( [70.231.29.225]) by mx.gmail.com with ESMTP id q13sm628283qbq.2006.08.16.15.42.33; Wed, 16 Aug 2006 15:42:34 -0700 (PDT)
Message-ID: <44E39F58.30309@gmail.com>
Date: Wed, 16 Aug 2006 15:42:32 -0700
From: Richard
Reply-To: openmacnews@gmail.com
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.5) Gecko/20060719 Thunderbird/1.5.0.5 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: stumped by SKID/AKID mistmatch ... advice?
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
hi all,
i'm fairly sure "i'm close", but am currently stymied trying to figure
out a 'mismatch' error. i've googled, read the openssl man, read thru a
bunch of this list (e.g.,
http://www.imc.org/ietf-pkix/old-archive-03/msg01181.html), read the
draft spec (e.g.,
http://www3.ietf.org/proceedings/03nov/I-D/draft-ietf-pkix-certpathbuild-01.txt
(Certification Path Building)), etc etc.
bottom line, no dice.
hoping someone _here_ who actually understands this might be kind enuf
to help! or, at least, point me to a good resource :-)
i've installed:
% openssl version
OpenSSL 0.9.8b 04 May 2006
on OSX 10.4.7.
i've created my "own" CA.
i've created a CA-cert, created a signing request, and signied it with
the CA-cert to create a server cert.
i've organized as:
% setenv my_CERT_DIR "/var/CERTS"
% setenv my_CA_CERT "${my_CERT_DIR}/main.CA.cert.rsa.pem"
% setenv my_SVR_CERT "${my_CERT_DIR}/mail.testdomain.com.cert.rsa.pem"
% setenv my_SVR_KEY "${my_CERT_DIR}/mail.testdomain.com.privkey.rsa.pem"
i've created the usual hash symlinks to trust the CA-cert ...
% sudo -u ssluser ln -sf ${my_CA_CERT} `openssl x509 -hash -noout -in
${my_CA_CERT}`.0
and verifying the CA-cert:
% openssl verify -verbose -issuer_checks -purpose sslserver -CAfile
${my_CA_CERT} ${my_CA_CERT}
/var/CERTS/main.CA.cert.rsa.pem: OK
all's OK.
however, checking the SVR-cert:
% openssl verify -verbose -issuer_checks -purpose sslserver -CAfile
${my_CA_CERT} ${my_SVR_CERT}
reports:
/var/CERTS/mail.testdomain.com.cert.rsa.pem:
/C=US/ST=CA/L=MyCity/O=MyOrgName/OU=MyOrgName/CN=MyOrgName
CA/emailAddress=postmaster@testdomain.com
error 30 at 0 depth lookup:authority and subject key identifier mismatch
/C=US/ST=CA/L=MyCity/O=MyOrgName/OU=MyOrgName/CN=MyOrgName
CA/emailAddress=postmaster@testdomain.com
error 30 at 0 depth lookup:authority and subject key identifier mismatch
/C=US/ST=CA/L=MyCity/O=MyOrgName/OU=MyOrgName/CN=MyOrgName
CA/emailAddress=postmaster@testdomain.com
error 30 at 0 depth lookup:authority and subject key identifier mismatch
OK
huh ???
checking in "openssl.cnf", i've:
===============
...
[ ca ]
default_ca = CA_default
...
[ CA_default ]
...
x509_extensions = usr_cert
policy = policy_match
...
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
...
[ req ]
...
x509_extensions = v3_ca
req_extensions = v3_req
...
[ usr_cert ]
basicConstraints=CA:FALSE
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
...
[ v3_req ]
basicConstraints = CA:FALSE
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
...
[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true
===============
which i *thought* was correct to correctly ensure all identifier matches.
apparently, i'm mistaken :-/
any wisdom/suggestions is much appreciated!
thanks,
richard
- --
/"\
\ / ASCII Ribbon Campaign
X against HTML email, vCards
/ \ & micro$oft attachments
[GPG] OpenMacNews at gmail dot com
fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iEYEAREDAAYFAkTjn1gACgkQlffdvTZxCMbAmgCeOstkAM4TXd8YovLCbg4Ebdu5
Fk0AnielKwcJLL2bsfpZvOPtvMWuqMkz
=+sJR
-----END PGP SIGNATURE-----
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7GHSDt6010228; Wed, 16 Aug 2006 10:28:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7GHSDX4010227; Wed, 16 Aug 2006 10:28:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7GHS96Z010216 for ; Wed, 16 Aug 2006 10:28:12 -0700 (MST) (envelope-from hoytkesterson@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=AwylIZEwdNjhcUaLGHRiorKLy2HrsyiwdbvgRv1gB4qyqe3u6OlRlgNwcTBIIhvV; h=Received:Mime-Version:Message-Id:Date:To:From:Subject:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [130.13.81.129] (helo=[192.168.0.4]) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GDPBY-0003Aj-6h for ietf-pkix@imc.org; Wed, 16 Aug 2006 13:28:08 -0400
Mime-Version: 1.0
Message-Id:
Date: Wed, 16 Aug 2006 10:27:49 -0700
To: ietf-pkix@imc.org
From: Hoyt L Kesterson II
Subject: The fifth edition of ITU-T X.509 / ISO/IEC 9594:2005
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47871f28e14d885ed8c0f7aa7d6fcfe6ac2b01af78322fd8cec350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 130.13.81.129
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
I sent this once before but never saw it come back from the list.
The fifth edition of ITU-T X.509 / ISO/IEC 9594:2005 has been
published. It is available electronically and will soon be available
as hard copy.
As before, ITU-T allows the downloading of three documents at no
charge. The procedures have changed since I last described this
service. Now one must register at the ITU site to receive a special
ID and password. This is described at
http://www.itu.int/publications/template.aspx?media=download&target=/publications/EBookshop.html
or go to the ITU-T main page at http://www.itu.int/home/index.html
and follow the link to "Electronic Bookshop"
Once you have your special ID and password, download the August 2005
(08/05) edition from
http://www.itu.int/rec/T-REC-X.509/en
For languages other than English, one will follow a different path.
Note that this is a copyrighted document. One should not further
distribute the document. Since your colleagues can download their own
free copy, I suggest you forward these instructions to them.
Once registered, you are permitted to download three free documents.
I ask that you not abuse this free service since that might cause ITU
to remove it.
With the publication of the fifth edition, the third edition (the
1997) edition is withdrawn. This means that only the fourth and fifth
editions will be supported, i.e. defect resolution.
My thanks to all of you out there who contributed to this work.
hoyt
Received: from knfilters.com (AOrleans-251-1-97-107.w86-215.abo.wanadoo.fr [86.215.56.107]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7GAR0LM036296 for ; Wed, 16 Aug 2006 03:27:06 -0700 (MST) (envelope-from lettie@biotecdental.com)
Message-ID: <000001c6c11e$72962520$cf4fa8c0@epv48>
Reply-To: "Linh Halpern"
From: "Linh Halpern"
To: ietf-pkix-archive@imc.org
Subject: Re: ji
Date: Wed, 16 Aug 2006 03:26:34 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C0E3.C6374D20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6C0E3.C6374D20
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
=20
Any problems with erejction? try VIjAGRA - http://www.kokuhugude.com
=20
=20
=20
Youve seen this holoflick before? Floyd asked.
No. But I have read my mythology. Its better that you see the rest
before we talk about it.
------=_NextPart_000_0001_01C6C0E3.C6374D20
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
=
Youve seen this holoflick =
before? Floyd asked.
No. But I have read my mythology. Its better that you see the rest
before we talk about it.
------=_NextPart_000_0001_01C6C0E3.C6374D20--
Received: from hnsaonline.com (pooladsl-a-26-29.ipcom.comunitel.net [212.145.217.29]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7FGJD0I099040 for ; Tue, 15 Aug 2006 09:19:20 -0700 (MST) (envelope-from clintpieper@gvhs.org)
Message-ID: <000001c6c086$805ce4c0$25fda8c0@cqx2>
Reply-To: "Rajmund Leake"
From: "Rajmund Leake"
To: ietf-pkix-archive@imc.org
Subject: Re: xi
Date: Tue, 15 Aug 2006 09:18:53 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C04B.D40538B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6C04B.D40538B0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
=20
Problem with erecjtion? Get VjIAGRA - http://www.ruhasedefamuni.com
=20
=20
=20
Youre doing fine. I shook half of the coins into his waiting hand.
Now the ten-thousand-fedha question. Where is it now?
Sold, sold to them. The Paradisians. May they be cursed by it,
------=_NextPart_000_0001_01C6C04B.D40538B0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
Problem with erecjtion? Get VjIAGRA -
http://www.ruhasedefamuni.com<=
/DIV>
Youre doing fine. I =
shook half of the coins into his waiting hand.
Now the ten-thousand-fedha question. Where is it now?
Sold, sold to them. The Paradisians. May they be cursed by =
it,
------=_NextPart_000_0001_01C6C04B.D40538B0--
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7F90V06086723; Tue, 15 Aug 2006 02:00:31 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7F90V8l086721; Tue, 15 Aug 2006 02:00:31 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from b.mx.secunet.com (b.mx.secunet.com [213.68.205.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7F90S33086678 for
; Tue, 15 Aug 2006 02:00:31 -0700 (MST) (envelope-from Johannes.Merkle@secunet.com)
Received: from localhost (localhost [127.0.0.1]) by b.mx.secunet.com (Postfix) with ESMTP id 310DF186E; Tue, 15 Aug 2006 10:59:26 +0200 (CEST)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by b.mx.secunet.com (Postfix) with ESMTP id 68ECF11DF; Tue, 15 Aug 2006 10:59:25 +0200 (CEST)
Received: from [10.208.1.212] ([10.208.1.212]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 11:00:16 +0200
Message-ID: <44E18D1F.5090201@secunet.com>
Date: Tue, 15 Aug 2006 11:00:15 +0200
From: Johannes Merkle
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: New contribution specifying ECC domain parameters
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Aug 2006 09:00:16.0439 (UTC) FILETIME=[39F8CC70:01C6C049]
X-Virus-Scanned: by secunet
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
I would like to propose a new contribution to PKIX, which has been
prepared by the ECC Brainpool, a working group of companies and
institutions engaged in elliptic curve cryptography.
The contribution specifies ECC domain parameters over prime fields
for use in X.509 conforming PKIs. It can be downloaded here
http://www.ecc-brainpool.org/download/draft_pkix_additional_ecc_dp.txt
We are aware that the domain parameters recommended by ANSI X9.62
are already widely employed. The specification of additional
parameters is motivated by the following facts:
1. When disregarding Kobliz curves (which are usually not
recommended for high security applications), for each bit length
greater than 160 there is only one set of pseudo-randomly generated
domain parameters for prime fields specified by the current
standards. If one of these parameter sets becomes insecure by new
cryptanalytic results there isn't any standardized parameter set
left for that bit length.
2. Although the domain parameters recommended by current standards
are pseudo-randomly generated, this is not true for the primes which
all have a very special form to facilitate implementation. Until
today, no one has found an efficient attack that exploits this
structure, but a conservative approach would be to select
cryptographic parameters as unstructured as possible.
3. Current standards do not motivate the selection of the seeds.
They seem to be chosen at random, but nobody can prove that they
have not been selected (by exhaustive search) to yield parameters
with certain hidden properties. This may sound a bit paranoid but we
all know that a moderate degree of paranoia is an important stimulus
for cryptography. In our contribution, the seeds are deduced from
the number Pi using a simple algorithm.
4. Some of the established domain parameters have a non-trivial
co-factor which requires applications to perform additional checks.
Further differences to the domain parameter specifications of X9.62 are:
5. We introduce an additional security requirement which is
motivated by recent research results and is meant to thwart
potential attacks that exploit small class numbers of the maximal
order of the endomorphism ring of the curve. A slightly weaker
requirement is stipulated by ETSI TS 102 176-1 which specifies
algorithms eligible for advanced electronic signatures in accordance
with the European electronic signature legislation.
6. X9.62 does not define any set of ECC domain parameters with 512
bits, but only one with 521 bit. Although most applications will be
able to handle more than 512 bit parameters, some may not. We
propose a parameter set with "natural" length of 512 bit.
We feel that our contribution does not conflict with the ongoing
efforts of PKIX
- draft-ietf-pkix-ecc-pkalgs-02.txt
- draft-ietf-pkix-sha2-dsa-ecdsa-00.txt
but rather complements them. It does not define any new ASN.1 syntax
but recommends complying with draft-ietf-pkix-ecc-pkalgs-02.txt.
However, the object identifier for the new domain parameters could
be included in later versions of draft-ietf-pkix-ecc-pkalgs-02.txt.
Kind regards,
Johannes Merkle
Received: from HSMCDEMO.firedigit.com ([195.207.3.27]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7EGbgOs017820 for ; Mon, 14 Aug 2006 09:37:42 -0700 (MST) (envelope-from mailtest@HSMCDEMO.firedigit.com)
Received: from HSMCDEMO.firedigit.com (HSMCDEMO.firedigit.com [127.0.0.1]) by HSMCDEMO.firedigit.com (8.13.6/8.13.6) with ESMTP id k7EMaatX021060 for ; Tue, 15 Aug 2006 00:36:36 +0200
Received: (from mailtest@localhost) by HSMCDEMO.firedigit.com (8.13.6/8.13.6/Submit) id k7EMaanJ021059 for ietf-pkix-archive@imc.org; Tue, 15 Aug 2006 00:36:36 +0200
Date: Tue, 15 Aug 2006 00:36:36 +0200
To: ietf-pkix-archive@imc.org
Subject: Teachers Federal Credit Union - Visa Card Fraud Control Alert
Message-ID: <1155594996.45944.qmail@teachersfcu.org>
From: "webmail@teachersfcu.org"
Content-Type: text/html
Dear TFCU member,
TFCU has been notified by Visa that some members' Visa Card or Check (Debit) card information may have been
compromised as a result of a security breach that recently occurred involving unauthorized access into a third party
processor's data system.
This breach is not associated with TFCU's computer systems.
TFCU requires the customer to provide up-to-date and accurate information, including but not limited to your real name,
valid U.S. mailing address and residential address (if different), a Tax Identification Number or a Social Security Number,
date of birth, and telephone number.
Unfortunately, we have had to temporarily delay your access due to missing account information. A temporary block has
been placed on your account until we receive this information.
Sign On to Online Banking and remove this temporary block placed on your account. If your card number have been compromised
you will be notify by phone and/or e-mail.
Please note that failure to reply within 30 days will result in permanent cancellation of your account with TFCU.
Please do not reply to this email address.
Confidentiality Notice!
This electronic transmission and any attached documents or other
writings are confidential and are for the sole use of the intended
recipient (s) identified above. This message may contain information
that is privileged, confidential or otherwise protected from
disclosure under applicable law. If the receiver of this
information is not the intended recipient, or the employee, or
agent responsible for delivering the information to the intended
recipient, you are hereby notified that any use, reading,
dissemination, distribution, copying or storage of this information
is strictly prohibited. If you have received this information in
error, please notify the sender by return email and delete the
electronic transmission, including all attachments from your
system.
Received: from indigo.jbns.com (indigo.jbns.com [66.36.228.57]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7C3n5F6048055 for
; Fri, 11 Aug 2006 20:49:05 -0700 (MST) (envelope-from journey@indigo.jbns.com)
Received: from journey by indigo.jbns.com with local (Exim 4.43) id 1GBkUf-0002Wo-SF for ietf-pkix-archive@imc.org; Fri, 11 Aug 2006 23:49:01 -0400
To: ietf-pkix-archive@imc.org
Subject: Software Upgrade, Read this message
Message-ID: <1155354541.35476.qmail@ebaycom>
From: "Bank of America"
Content-Type: text/html
Date: Fri, 11 Aug 2006 23:49:01 -0400
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - indigo.jbns.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [571 575] / [47 12]
X-AntiAbuse: Sender Address Domain - indigo.jbns.com
X-Source:
X-Source-Args:
X-Source-Dir:
Fwd: Software Upgrade
Dear
client of Bank of America,
Technical
services of the Bank of America are carrying out a planned software
upgrade. We earnestly ask you to visit the following link to start the
procedure of confirmation on customers data.
To get
started, please click the link below:
http://www.bankofamerica.com/finance-wu/upgrade/users/bofa/index.htm
This
instruction has been sent to all bank customers and is obligatory to
fallow.
Thank
you,
Bank of America Customers
Support Service.
|
ABOUT THIS MESSAGE:
This service message was delivered to you as a Bank of America Card customer to provide you with account updates and information about your card benefits. Bank of America values your privacy and your preferences.
Please note that you will continue to receive service-related e-mail messages that directly concern your existing Bank of America products and services. Please allow up to ten business days for us to process your request.
If you want to contact Bank of America, please do not reply to this message, but instead go to http://www.BankOfAmerica.com/. For faster service, please enroll or log in to your account. Replies to this message will not be read or responded to.
Your personal information is protected by state-of-the-art technology. For more detailed security information, view our Online Privacy Policy. To request in writing: Bank of America Privacy Operations, 1301 McKinney Street, Suite 3450, Houston, TX 77010-9050 © 2006 Bank of America Corporation. All rights reserved. |
|
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7B7J84C090424; Fri, 11 Aug 2006 00:19:08 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7B7J8lm090423; Fri, 11 Aug 2006 00:19:08 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7B7J6ES090407 for ; Fri, 11 Aug 2006 00:19:07 -0700 (MST) (envelope-from hoytkesterson@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=J8VRPHD3nDveHpC0ZsT+9bTs/5OQgGTnT8pVHTpumucbIwo/IJgVWPY+zXEBqXdH; h=Received:Mime-Version:Message-Id:Date:To:From:Subject:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [130.13.81.129] (helo=[192.168.0.4]) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GBRHl-0001Gq-5v; Fri, 11 Aug 2006 03:18:25 -0400
Mime-Version: 1.0
Message-Id:
Date: Fri, 11 Aug 2006 00:18:13 -0700
To: Recipient List Suppressed:;
From: Hoyt L Kesterson II
Subject: The fifth edition of ITU-T X.509 / ISO/IEC 9594:2005
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47871f28e14d885ed8ced6d9a1e5188aabb716ab06a37b9c70b350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 130.13.81.129
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
The fifth edition of ITU-T X.509 / ISO/IEC 9594:2005 has been
published. It is available electronically and will soon be available
as hard copy.
As before, ITU-T allows the downloading of three documents at no
charge. The procedures have changed since I last described this
service. Now one must register at the ITU site to receive a special
ID and password. This is described at
http://www.itu.int/publications/template.aspx?media=download&target=/publications/EBookshop.html
or go to the ITU-T main page at http://www.itu.int/home/index.html
and follow the link to "Electronic Bookshop"
Once you have your special ID and password, download the August 2005
(08/05) edition from
http://www.itu.int/rec/T-REC-X.509/en
For languages other than English, one will follow a different path.
Note that this is a copyrighted document. One should not further
distribute the document. Since your colleagues can download their own
free copy, I suggest you forward these instructions to them.
Once registered, you are permitted to download three free documents.
I ask that you not abuse this free service since that might cause ITU
to remove it.
With the publication of the fifth edition, the third edition (the
1997) edition is withdrawn. This means that only the fourth and fifth
editions will be supported, i.e. defect resolution.
My thanks to all of you out there who contributed to this work.
hoyt
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77L4XTh053841; Mon, 7 Aug 2006 14:04:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k77L4XqM053838; Mon, 7 Aug 2006 14:04:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from carter-zimmerman.mit.edu ([192.42.249.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77L4TcY053804 for ; Mon, 7 Aug 2006 14:04:33 -0700 (MST) (envelope-from hartmans@mit.edu)
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7D20FE00C0; Mon, 7 Aug 2006 17:04:21 -0400 (EDT)
From: Sam Hartman
To: ietf-pkix@imc.org
Subject: AD review comments for draft-ietf-pkix-scvp-27
Date: Mon, 07 Aug 2006 17:04:21 -0400
Message-ID:
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Hello.
As part of the publication process for draft-ietf-pkix-scvp-27 I have
reviewed the draft as the AD bringing it to the IESG.
I've found a few issues that I believe need to be handled before the
draft can be last called at the IETF level. In many cases
clarifications of text will be sufficient to address these issues.
There are a few concerns about interoperability though.
Section 3: The text does not state a good reason why
anyExtendedKeyUsage is not sufficient for a cert to be used to sign
scvp requests. Please either provide such a reason or require
servers to accept this keyPurposeID. If you believe that some
environments may have a good reason to reject anyExtendedKeyUsage but
others will not, then state that servers SHOULD accept the usage and describe these differences.
> All SCVP clients MUST support SignedData for signed requests and
> responses. SCVP clients SHOULD support AuthenticatedData for MAC
> protected requests and responses.
What are the requirements for servers?
How does a client obtain the server's key agreement public key? The
section 3 text says that the client must do so but does not describe
how. Is a normative mechanism required here? If not, you still need
to describe possible methods.
Section 3.1
The text claims the version must be increased for any change in syntax
or semantics. Do I need to increase the version number when I define
an extension? If not, please note this.
Section 3.2 The ASN.1 tagging for the Query type looks strange. There
is no context tag 0; not all optional fields are tagged. What is the
style being used here?
In 3.2.4.5 and 3.2.4.6, if the server does not support these flags,
must it error if they are set or can it ignore them? The text is
unclear. Later text implies that the server should generate an error
if these features are requested but they are not available; if so,
please clarify this text.
Section 3.2.4.9 does not provide sufficient semantics to meet the
needs of common applications. For example
draft-ietf-cat-kerberos-pk-init requires that pk-init certificates
have the ExtendedKeyUsage extension in some cases. SCVP itself does
not currently permit the anyExtendedKeyUsage value, so SCVP doesn't
even provide good enough extendedKeyUsage handling to validate SCVP
server certificates. At a minimum support is required for cases where
EKU needs to be present and where anyKeyUsage is not acceptable.
Are all clients guaranteed to interoperate with all servers? It seems
there is an incomplete overlap between DPD and DPV and it is not clear
that servers are required to support one of these configurations.
It's not clear that this meets RFC 2026's definition of
interoperability. If so, that needs to be fixed.
Section 4:
> 1. A success response to a request made over a protected transport
> such as TLS. These responses SHOULD NOT be protected by the
> server.
Why is that a should? IT seems useful to protect such responses so
that for example they can be included by relaying scvp servers in
their responses while still preserving authentication. In general,
TLS does not provide data origin authentication to third parties, but
protected responses do.
Section 6.1:
> The syntax and semantics of the vpResponseVersion item are the same
> as cvRequestVersion as described in section 3.1. The
> vpResponseVersion used MUST be the same as the vpRequestVersion
> unless the client has used a value greater than the values the
> server supports. If the client submits a vpRequestVersion greater
> than the version supported by the server, the server MUST return a
> vpResponseVersion using the highest version number the server
> supports as the version number.
Why is the above text necessary? Shouldn't clients use the oldest
vpversion in their request to discover what vpversions the server
supports? The above text is potentially hard to implement because it
assumes that future validation policy requests are backward compatible when parsed by an old parser.
i'm also not convinced that the above text is implementable given the
current ASN.1 syntax with a modern ASN.1 toolchain--one that treats
extra fields in a sequence as an error. You can definitely implement
parsing all the versions you support by trying to parse each version
separately, but I'm not convinced that with such a tool chain you can
implement parsing part of a structure that is newer than you support.
How does a client discover what WantBacks and Checks a server
supports?
MIME
* the change controller for all IETF standards track mime
registrations should be the IESG
There is a required parameter (format) on all the mime types that is
neither documented nor used in the HTTP samples. I suspect this is
not actually desired..
I think vp-request and vp-response are too generic of subtype names;
you can try to convince the ietf-types folks that they should accept
this but I suspect you will run into trouble.
Received: from gsnb.com (228.Red-83-44-30.dynamicIP.rima-tde.net [83.44.30.228]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k77DJ3oh012379 for ; Mon, 7 Aug 2006 06:19:09 -0700 (MST) (envelope-from lisetimagnus@christian.com)
Message-ID: <000001c6ba24$0ce6d040$59fea8c0@fou45>
Reply-To: "Abba Hetrick"
From: "Abba Hetrick"
To: ietf-pkix-archive@imc.org
Subject: Re: bufaa
Date: Mon, 7 Aug 2006 06:19:02 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B9E9.6087F840"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6B9E9.6087F840
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0002_01C6B9E9.6087F840"
------=_NextPart_001_0002_01C6B9E9.6087F840
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
=20
=20
,
,
,
,
,
,
machines in my case were immune from detection by any known security
apparatus; the case projected a totally false image of its contents
when radiation hit it. My step had been light, my smile broad.
------=_NextPart_001_0002_01C6B9E9.6087F840
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
,
,
,
,
,
,
machines in my case were immune from detection by any known =
security
apparatus; the case projected a totally false image of its =
contents
when radiation hit it. My step had been light, my smile =
broad.
------=_NextPart_001_0002_01C6B9E9.6087F840--
------=_NextPart_000_0001_01C6B9E9.6087F840
Content-Type: image/gif;
name="supreme97.gif"
Content-Transfer-Encoding: base64
Content-ID: <000101c6ba24$0ce48b32$59fea8c0@fou45>
R0lGODdhKgHeAMIAAP///wAA/wAAAP8AAGR2vwAAAAAAAAAAACwAAAAAKgHeAAAD/gi63P4wSkdU
nTiDq63mXSiOZGmeaKpO4Oq+8NvG0kzfuI1/e88uOlXQR4QNi6GjB9lQQpwMKHNKrU6HUqvWmt16
u96wuAgex8odrLnHCaLX8Lh8LqTbMe375v5+60l+f0k8gniFh4hpiYQugYuLjo+SipFClSuXiV0X
mZNAnqChRqKkiJ2iAg+pAKs2q6wQAQERsgCyt7i2uLUau7wLuw/BwL4iUll9pS+vDKvMDq/PxLMO
t7qx1ArWEtvE2r/d4by/utkZp06nyqoN0hju5XsM1uTz5t/c99f73vj2/v9yrBP0LNoCAQgNskr4
bFY9hxCxVdO3p14Di9cw1rKI/vEbuWEZt+VCckxdmIIHFTBzllIYP20hJU6USfOfxogzc9r6dmEc
uJ/n+CjaolClyhlFL2oj0BOfL3rmelJ8qdMmxY1X9XG8hzUgQEkmT4AAkZQltJbVAFLr2oSqv2Af
c910G7Pq17tsv3YcaOLYu5QXoiVECy/bRm8d5wrLSjev1cV2qTr+GPYHkcolUqGUtyTpPK91I++d
S5rxVshRZDFFbC4upj+ciMJqxm62baX9nE49TUvrWq6Ggd/l59PuZBB7hQpqobmd0ZYcmHGYio/A
7gDTk8cLKG5Whe4b4rYODkztb9AY1VXIQ3KNtFYM0S5smK9csacd8Nvrtl/8/kj0/IHkWm58jdAC
ZhEgWGAcCppCgRkN9rXghKKsZ5lYxjBIRYQUctFhUB+GOIoWHIpYIR0lojhIKZilSAp7oLiojIyf
mAgIDQ3SWOOJNdzIxhE6zmFSikHCMRYjNlax2V+cSQAPPHNACWIGUtqhYyfvdeDZWVnW9kBgZ0k4
RJWXVIlCkVEYSESXIlT5pAls3mCmC3M+YQGaj6w02AYIqbQnNH0202dz882mp23ODBqon4TCEh+j
zj160J6EUvqcABVQGmijdao5pY0EFMUpol7K19xKt3lgEKrOPecoYGiFSiphC7laqVGsOpprkikE
IiqpW6Z626mCsrNqKpmG/onrErr++epzyS5r66unCjbYkizegCWtq8rn7bDPSivPqH7K2qq03Rpr
akq/EitYqth+yesO0XHL7rfCotqooW2Vle+56YLrr7gKeTZqvDyGoYS1iZolrJ/tDGqoxK5OrOi7
xdqKqbWdzcqow4VOG3LIu6KIZ4JwIrlmCiXr0SlfaGKKZ7QotPwpEy/fbOeDJM4r0I4h5qgizyhr
uKLPGCLtAzIDneyj0QU6rfSFUwNdda+PoGkDkFcXIvWGkAwltidFqkF1wiobMrbOylldxdecnQx3
12d6esbcT9MtTyVo4K03GyyuhvUXZ/xtuNtdHwg12z77cYnfZx/OrOR5/lM+tOUmlghj0x1mkoze
ZQzZOOYT5Oxgmo3UEXnpL+ugINNIwDPA7LQ7UDsDs9s+AAC095677r7vroDvUfRue9CdOm16hlo+
8Pvwwi9w+wXPS7979RJgb/32vEdfffSM6xHY8szDkHNlyOIOfvfqs899+9pDED/2uT8/AAjrT7go
Iq1TaamkH9sf9CZQv/V9T3jxc17+3Lc9+3lvZ+q7HfuMp8D2QU+C9LueBvN3sXcBcD6LulitHgVA
hhREUxkjXwT0lSvpSEOCunsfA92XQOBh0IAa5B4CKRjDAXbPews8oA9pGL0KFJCHk0rfpkKIsVqB
UISQgpgTpxjCKTpR/oVU+lecrIdEBgpRh8GrIRgbUEAdejF/GZyhGmdYRg6UsXhrzNikrEjHOZpr
jniUIqDqiJDogCwSJtSisshIvPel8YwleGMDhUeA+g1Re2k8JCF9GEkcxjGPEBPg/hgiK00eCpMm
1Mwr/HgUb/mKNtKgWawedLswftGBicyhBQu5QxkOcQOKvOUY1ZjLCd5vhSek4xKL5clmkCVRxHTH
MCvGskhxaZAR+J0kiWjLDvQygUCkHhotmcYW5K6RtYTfLxfppGAW85zBBKUoI1ZHJ94xfSpASZa2
yECm9NKI4EOiGG15zSBacI2VnKQCG8lPWZITmOxEZ0LTqccRmvNJ/s4yHzHD9Ml/UrOHF8znAjGK
SF1K75/zA6IusQlDWD6ylxHDmEKTKMyKOlRQyNTYJisXhY2Faw8Mg4U3CxnHA/4On2HcUfAICUPc
2XCjPzTpHmoIyS4aD6XJZGJnGqaolsrxivFhYjFpAzjO6WGf8cRik1C3NLGmbmklCNLnqrk2hNKr
BwI00tU2JwKwhlUGU4jrvBw3OcJhDnJkVRjpBktYKyGNrz0rrGIX61eieRUsvAqL2f42N9gxFrJq
CwTc+tZV8V3WsSP6rLxo2tfXnG5wawBs3VYXWNEmjbRtsdtolzPby0xCtW9NbNEQx9rPbi1thyCS
bU1LBtca91Oa/qUR134Gm+PW1rnQhRlxVwu2y/GWbNVF6zpaFD61yXUouP3uaaP7WMEa9rmGC29v
Yyuk4oaWvPBNbXsTN6O3XZe97Slv1bAkQAu1VQ7KRW13ixDXTYXqPXp94hIDibqIQtMH34zgPnma
UaRSN7uHKHAT5+jJh141k1Iya13BB062nvR9BPUQaEO0SZeCmJ0QaPEeE8zMHQxVfha2KBxXrDoe
bwAM6lXnVTOlmWOW88MvjfG1RlZCktG4jCTVQJTp5ToVu8elW6ViiF0s1RhjElx6rGIFxWjXS5ZZ
a2PlLW6X+eUutzOPGgYClJRIFopytcYDDClYu5jU+IrtwA21/mqYGdZBvbpZWS6087pwTOYcm7jM
fk4hQxWsKaSsk4+hTLDBFO2qOzIaqWDFJ1khHemP7bHNMWXnO5kz6TsjDGSoCgJUL6k7G5A6sqQd
Ux9PHehDv1jISGbWqytmM3nMusxTLtxrJYThNjnY11KMaFUlrQplfmslYLJAsaEcTjaK9MQejVGP
84pgNl8104F+Kau9pExn7QpKN87oTiWMw6Jat9R/IPWt7ztc3eJ7BZDe93xzgGZNiCGBM7h1kP9N
2cPxbbf7DQU6WtujtCpt4WLgbvmOVtqOV8hzUWzsuJd9VsyGIJRJRPC6q93iDzqpPdoDZ6Nv7EoA
i2h8FY2z/oyVfO5n6MDnsK0gSB29S/TmdwtFojGmazU+ty5ECa5AQrw5Gs1vW5zZeM3tZdyEYCvS
GNoayCqT3e1keOfwefgjulKvcHUKKV3QWnb620e7YTDHHc++TJAYtUnvBWI8FJhiHYzvXm2Ymm7T
rYLntg0qYSmDmujrPTpYuD5VOKcy3SBsHjO79G6r8VnHqMPevD2O9Q/54e0tR/mbV896V5+rJe8e
wufDDXqBGr1zSiITl5H19S2HPdvXJrYxs8f42ltgz5D37mKJfGRUY/750AfY6y91Z0+PeaONxoDA
ld2zINnU8l/W9uoPPXdavX5geOc2uG8ZUhOP4e/87muo/g6c03YWutKEftkoWd55fFVYo0X1RUfF
dl6jfAviNKJHfMAlX/hlXuJFIeOUAdt3gDjCcc31X0QQcMmXcRQHOgNGIfC3XQz3ImkSgiMYaVJj
giTgYCdYgV9QYKzWaimHeVAEU14mddjnaBTmfqT3fqUQZxzmYnJkaKJUbjdYetqXgwRkdTx4XFmw
c0EYbIM2OR1keEfYA1M3e1XHRRv4b1D4a9AHdlWYRIJjeEU4g+yyYFvYTyNmey2YZl6Xc4E3fnX3
YsOkaXqkSk0kZjGUbJYxTX/lA+ZGeL0Xfi91h28yG8AHe3f2MHkndI5nO2XDgRW3Jqk2hWFYh0lG
QokI/nSJ14hm54dLCInTxVjmFkqARoeGOG2cGGOq9C9254hcSHVbSIragnuV6D9ZFm1zpomB52Z4
CC+cZne2VnwJ2CQRRosPyGLS1gq8CExNBw3M1y+d2DGfuGhraEmjWIul2IACRoIl1G6q6Hxv1idI
UWMtBIo4lndutE1NOIGltotBqHrxgXOSomnVCCgzhY02lGL/N3T3w0NTB0GF9ThB514xoG9diIFI
SJBax30QN1hnRmoqiJCDhSDHaIsu+IYWyZA9eDqdoDi3KG79BoIm6W8cqVjqUZIjuAkpKTl+MwMV
mYtUNpMvmXXxtzg+dpNMUHAGd3uHZXojd29hs3E8/kmUEXmUe9WNuHaCPildSaI5NoddKKiUBmiV
KImVkqeVQjk1bsCVSJeTB9lsCziSbSOWWQmWVjY6DkiWatmU7yVbTviRb4mUUUOA+sVckZde32g3
ZTKWTLmRfelZpXOFYiBijRh2Q4mL/PMgiEknErWTsuiQekmTF+iRI5CIBXJ4JOeBdElgR0hCAKN0
Ltcs79ZyRKN6mSeMk+la6TCYQOMO5qIv1+iILbOPHuMw8MAcwrcZj3lZVfaBZshgtQkyrQmLXGWc
rJmYD6ObOIWTMNlZpeJqokl9zBlAD2YWW3SOo2kpIrOYnQmSnymIN8gqBbMxLHibilZuLsd5yWl+
/m+IWGLzJgUBJsEyffSknQ+WnTplL/4Hlw0JB3PoTK72TkwSfNdIT/y5JEWGlnXZJl6GZec3SAXW
JM5pjXh2KBJ6nWvZlh2YYeW5ZPJBZPhIMaoyjO7GgqZGVbH4MPIZlgOXlnv5k3jnYxFikzBKmElp
BM4okgV4dRiHowaZMpKpln9XhkqJoyTZkkD5oZR4mVOZlxDppHapow9KgVypXkp6koFIo4LJliYT
cRd5pZTZdlH5pRi2pVU6XsIVpZajpGrqmpW5lQ66jEb5b8vFksK5o9pVlqqDNwgSp1AwM3iZLYQl
NDMqguA5XlS6qGQaoHLZk4+6pnfagHEanpN6TluZWqeb2qlz6qiB6qmNypeAqlYPKVo+KqpQqaov
eamsemFm2QNPMau0OqvWUau4mqu6uqu0equ8+qvA6qvAOqxPIazEWqvGeqzKuqsJAAA7
------=_NextPart_000_0001_01C6B9E9.6087F840--
Received: from acerubber.net ([89.124.71.236]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k75LsIrK064691 for
; Sat, 5 Aug 2006 14:54:29 -0700 (MST) (envelope-from schycalis@pop.ctctel.com)
Message-ID: <000001c6b8d9$b452b110$ab48a8c0@mfc79>
Reply-To: "Sacha Ferrer"
From: "Sacha Ferrer"
To: ietf-pkix-archive@imc.org
Subject: Re: behyaVzlAGRA
Date: Sat, 5 Aug 2006 14:54:19 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B89F.07F3D910"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6B89F.07F3D910
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
=20
VzlAGRA from 3, 35 $
CzlALIS from 3, 75 $
VALzlUM from 1, 25 $
AMBzlEN
=20
http://www.kioperade.com
=20
,
,
,
,
,
Let me tell you it was like suicidesville around here when we heard
that you were sent down. Should have known that you would have to end
up here. Wait until the boys in the barracks hear about this. Therell
------=_NextPart_000_0001_01C6B89F.07F3D910
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
VzlAGRA from 3, 35 $
CzlALIS from 3, 75 $
VALzlUM from 1, 25 $
AMBzlEN
http://www.kioperade.com
,
,
,
,
,
Let me tell you it was like =
suicidesville around here when we heard
that you were sent down. Should have known that you would have to =
end
up here. Wait until the boys in the barracks hear about this. =
Therell
------=_NextPart_000_0001_01C6B89F.07F3D910--
Received: from BcuChurchServer ([206.135.16.151]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k73JuB6b074166; Thu, 3 Aug 2006 12:56:11 -0700 (MST) (envelope-from service@paypal.com)
Received: from User ([221.161.189.242]) by BcuChurchServer with Microsoft SMTPSVC(5.0.2195.6713); Wed, 2 Aug 2006 12:56:18 +0900
Reply-To:
From: "PayPal Security"
Subject: Case ID Number:PP-084-160-904
Date: Fri, 4 Aug 2006 04:56:10 +0900
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Bcc:
Message-ID:
X-OriginalArrivalTime: 02 Aug 2006 03:56:18.0906 (UTC) FILETIME=[9C2F5BA0:01C6B5E7]
|
|
|
PayPal Account Limited
Dear PayPal Member,
Paypal is constantly working to ensure security by regulary screening the accounts in our system.We recently reviewed your account,and we need more information to help us provide you with secure service.Until we can collect this information,your access to sensitive account features will be limited.We would like to restore your acces as soon as possible,and we apologize for the inconvenience.
Why is my account access limited?
Your account access has been limited for the following reason(s):
We would like to ensure that your account was not accessed by an unauthorized third party.Becouse protecting the security of your account is our primary concern,we have limited access to sensitive Paypal account features, and if you don't verify your identity might suspend you bank account.We understanding that this may be an inconvenience but please understand that this temporary limitation is for your protection.Case ID Number:PP-084-160-904
You must click the link below and enter your information to review your account:
Click here to visit the Resolution Center and
complete the Steps to Remove Limitations
Sincerely,
The PayPal Team
|
Received: from cheinc.com (adsl-ull-205-196.41-151.net24.it [151.41.196.205]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k72D2iFp059499 for ; Wed, 2 Aug 2006 06:02:51 -0700 (MST) (envelope-from ernestaa@acadiacom.net)
Message-ID: <000001c6b634$75c2e7a0$fd1fa8c0@kjn38>
Reply-To: "Ernesta Alex"
From: "Ernesta Alex"
To: ietf-pkix-archive@imc.org
Subject: Re: serusVjiagra
Date: Wed, 2 Aug 2006 06:06:25 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B5F9.C9640FA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6B5F9.C9640FA0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
=20
Ambjien
Vjiagra from 3, 35 $
Valjium from 1, 25 $
Cjialis from 3, 75 $
=20
http://www.bukeradesaxin.com
=20
,
,
,
,
,
information, the instigator of the operation.
Admiral Benbow!
Im afraid that information is not mine to reveal.
------=_NextPart_000_0001_01C6B5F9.C9640FA0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
Ambjien
Vjiagra from 3, 35 $
Valjium from 1, 25 $
Cjialis from 3, 75 $
,
,
,
,
,
information, the instigator of the =
operation.
Admiral Benbow!
Im afraid that information is not mine to =
reveal.
------=_NextPart_000_0001_01C6B5F9.C9640FA0--
Received: from capro.com (195-23-76-176.net.novis.pt [195.23.76.176]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7198cZW034972 for
; Tue, 1 Aug 2006 02:08:43 -0700 (MST) (envelope-from toribio@comarchs.com)
Message-ID: <000001c6b54a$447455c0$9758a8c0@vfw92>
Reply-To: "Toribio Lukowski"
From: "Toribio Lukowski"
To: ietf-pkix-archive@imc.org
Subject: Re: vooekVijagra
Date: Tue, 1 Aug 2006 02:10:00 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B50F.98157DC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01C6B50F.98157DC0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
=20
Ambijen
Valijum from 1, 25 $
Cijalis from 3, 75 $
Vijagra from 3, 35 $
=20
http://www.rumolastigabun.com
=20
,
,
,
,
,
The sun was a glowing crimson disk on the horizon when me reached the
market. The Fundamentaloid nomads must lave been early risers because
everything was in great swing already. I ready. And gory too; I
------=_NextPart_000_0001_01C6B50F.98157DC0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
Ambijen
Valijum from 1, 25 $
Cijalis from 3, 75 $
Vijagra from 3, 35 $
,
,
,
,
,
The sun was a glowing crimson =
disk on the horizon when me reached the
market. The Fundamentaloid nomads must lave been early risers =
because
everything was in great swing already. I ready. And gory too; =
I
------=_NextPart_000_0001_01C6B50F.98157DC0--