Subject: May your Dreams Come True!

From: <[email-masked]>
Date: Wed, 31 Dec 2008 19:47:45 -0800 (PST)

Please do not reply to this email. To contact Armstrong Shank Advertising, please
visit us

This email message was sent to . If
you do not wish to receive further communications from Armstrong Shank Advertising,
click
here to unsubscribe.

If you've experience any difficulty
in being removed from a Armstrong Shank Advertising email list, click
here for personalized help.

Copyright © 2008 Armstrong Shank Advertising, Inc. All rights reserved.

7450 S Seneca, Haysville, KS 67060

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVLnR0a011498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 14:49:27 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVLnRgZ011497; Wed, 31 Dec 2008 14:49:27 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVLnGc0011483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Dec 2008 14:49:27 -0700 (MST) (envelope-from [email-masked])
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBVLn742030982; Wed, 31 Dec 2008 16:49:07 -0500
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id mBVLn22A032518; Wed, 31 Dec 2008 16:49:03 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 16:49:02 -0500
From: "David A. Cooper"
User-Agent: Thunderbird 2.0.0.18 (X11/20081120)
MIME-Version: 1.0
To: [email-masked]
CC: pkix
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information:
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Eygene,

You are correct that a change anywhere in the certificate will change
the hash. However, the attacker does not need to know in advance what
the hash value will be, only that the hash of the real certificate and
the rogue certificate will be the same. If you look at the image
depicting the generation of the collision in the attack
(http://www.win.tue.nl/hashclash/rogue-ca/downloads/alignment.pdf), you
will see why these two statements are not the same.

Hash functions such as MD5, SHA-1, SHA-256, etc. work by processing
messages in blocks. In the case of MD5, the blocks are 64 bytes each.
In the attacks, the attackers needed to find two certificates such that
the results of hashing the first 704 bytes (11 blocks) of both the real
and rogue certificates would be the same. Once they had found such a
collision, it was guaranteed that the hashes of the two certificates
would be the same as long as the contents of the remaining bytes in both
certificates (blocks 12-15) were the same. In the diagram, it notes
that blocks 12-15 are identical in both the real certificate and the
rogue certificate. In the rogue certificate, unlike in the real
certificate, all of these bytes are just treated as random garbage. The
contents of blocks 12-15 can be changed arbitrarily, as long as the same
changes are made in both the real and rogue certificates, and the result
will still be two certificates with the same hash value.

So, the attack works as follows: guess and/or generate the contents of
the certificate that will precede the subjectPublicKeyInfo field,
including the overall length of the certificate. Create a key pair for
the real certificate and contents for the rogue certificate such there
is a collision in the intermediate output of the hash function for the
two certificates (e.g., such that the output of the hash function after
processing the first 10 blocks of each certificate is the same). Submit
the certificate request with the information for the real certificate
and then get back the real certificate from the CA. Copy all bytes from
the real certificate that appear after the point of the collision into
the rogue certificate (e.g., copy blocks 11-16 from the real certificate
to the rogue certificate). If the CA incorporates randomness into the
extensions field (but in a way that does not make the certificate's
length unpredictable), the attacker may not be able to predict the hash
value of the entire certificate, but that will not keep the attacker
from reliably creating a collision.

To put it another way, for all of the commonly used hash functions (MD5,
SHA-1, SHA-256, etc.), if H(M) = H(M') then H(M || N) = H(M' || N) [I
believe that the lengths of M and M' need to be the same and an even
multiple of the block size used by the hash function]. So, an attacker
who wants to create two messages, M || N and M' || N, such that H(M ||
N) = H(M' || N) can do so by creating M and M' such that H(M) = H(M')
without needing to know the value of N.

Dave

Eygene Ryabinkin wrote:
> David, good day.
>
> Wed, Dec 31, 2008 at 02:03:32PM -0500, David A. Cooper wrote:
>
>> The attack (http://www.win.tue.nl/hashclash/rogue-ca) does not require
>> the attacker to know the order in which the extensions will appear or
>> the values that will appear in the extensions.
>>
>
> Really? Unless I am missing something, the hash from the A + B will be
> different from the hash of B + A, if '+' is some sort of concatenation.
> In fact, changing the single bit of input should produce greatly varying
> hash.
>
>
>> The attacker only needs to guess those portions of the DER encoded
>> TBSCertificate that appear before the subjectPublicKeyInfo field.
>>
>
> No, since attackers are generating collisions prior to the signing
> the request at CA, they should be sure that the hash computed by CA
> will be the same as the hash computed by attackers. And since the
> whole DER-encoded TBSCertificate chunk is user for a hash generation,
> every bit of it matters.
>
> You're right that the attackers could vary the arbitrary bits of the two
> certificates during the collision search. But once collision is found,
> this is the end, certificates are fixed and CA is used just for the
> signature generation. And this is the reason why people seek the serial
> number and validity dates of the colliding-certificate-to-be-signed.
> And that's why randomization of the serial number and/or validity
> dates will help to avoid or at least delay the attackers.
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVL1UHG007358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 14:01:31 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVL1U3x007357; Wed, 31 Dec 2008 14:01:30 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.grid.kiae.ru (mail.grid.kiae.ru [144.206.66.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVL1HVu007334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Dec 2008 14:01:30 -0700 (MST) (envelope-from [email-masked])
Received: from phoenix.codelabs.ru (ppp85-141-67-189.pppoe.mtu-net.ru [85.141.67.189]) by mail.grid.kiae.ru (Postfix) with ESMTPSA id 6CA4554D02C; Thu, 1 Jan 2009 00:01:16 +0300 (MSK)
Date: Thu, 1 Jan 2009 00:01:15 +0300
From: Eygene Ryabinkin
To: "David A. Cooper"
Cc: pkix
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
Message-ID:
Reply-To: [email-masked]
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

David, good day.

Wed, Dec 31, 2008 at 02:03:32PM -0500, David A. Cooper wrote:
> The attack (http://www.win.tue.nl/hashclash/rogue-ca) does not require
> the attacker to know the order in which the extensions will appear or
> the values that will appear in the extensions.

Really? Unless I am missing something, the hash from the A + B will be
different from the hash of B + A, if '+' is some sort of concatenation.
In fact, changing the single bit of input should produce greatly varying
hash.

> The attacker only needs to guess those portions of the DER encoded
> TBSCertificate that appear before the subjectPublicKeyInfo field.

No, since attackers are generating collisions prior to the signing
the request at CA, they should be sure that the hash computed by CA
will be the same as the hash computed by attackers. And since the
whole DER-encoded TBSCertificate chunk is user for a hash generation,
every bit of it matters.

You're right that the attackers could vary the arbitrary bits of the two
certificates during the collision search. But once collision is found,
this is the end, certificates are fixed and CA is used just for the
signature generation. And this is the reason why people seek the serial
number and validity dates of the colliding-certificate-to-be-signed.
And that's why randomization of the serial number and/or validity
dates will help to avoid or at least delay the attackers.
--
Eygene Ryabinkin, Russian Research Centre "Kurchatov Institute"

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVJKaVC000150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 12:20:36 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVJKaOo000149; Wed, 31 Dec 2008 12:20:36 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVJKPvX000128; Wed, 31 Dec 2008 12:20:36 -0700 (MST) (envelope-from [email-masked])
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate
Date: Wed, 31 Dec 2008 14:20:23 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate
Thread-Index: Aclq5IgC5ZANbzGKQ/GkJqeRHNnrQgAkuFSw
References: <[email-masked]> <[email-masked]> <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]>
From: "Kemp, David P."
To: , , ,
X-OriginalArrivalTime: 31 Dec 2008 19:17:00.0562 (UTC) FILETIME=[5B1E9F20:01C96B7C]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Just to be precise, past MD5 certificates should be safe as long as
there
are no second-preimage attacks. I have no idea* whether there are any
computational shortcuts to finding a second preimage (where both the
hashed data and its digest value are known) relative to finding a
preimage
(where only the digest value is known), but in principle second-preimage
attacks might be feasible sooner.

Dave

* for example, http://www.springerlink.com/content/yut517362112765h/
indicates
that 1 in 2^56 messages may be "weak" against a specified attack on MD4.
What is needed is an attack on MD5 where many or all messages are
"weak".

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jeffrey Hutzelman
Sent: Tuesday, December 30, 2008 6:46 PM
To: Santosh Chokhani; Peter Hesse; RL 'Bob' Morgan; Paul Hoffman
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate

--On Tuesday, December 30, 2008 06:28:07 PM -0500 Santosh Chokhani=20
wrote:

> Since the attack is computing pre-image, I suspect that past MD5
> certificates are safe until the attack was devised.

The attack does _not_ involve computing a preimage; it involves
computing a=20
colliding pair one of which has a prefix which is predictable but not=20
controllable, followed by a controllable component consisting of some=20
minimum number of bits followed by at least three aligned message
blocks.=20
What makes existing certificates safe is that there are no known
preimage=20
attacks against MD5, couple with limitations of the technique used to=20
construct the colliding pair.

However, there is a limit to how "safe" existing certificates are,
because=20
the attack does not require anything that was not known 3-4 years ago.
The=20
only change is that with the latest techniques for computing collisions,
it=20
is possible to do so in a short enough time to be able to predict the=20
validity and serial number that will be used by the issuer with fairly
high=20
probability.

-- Jeff

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVJ3uTE098879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 12:03:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVJ3usf098877; Wed, 31 Dec 2008 12:03:56 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVJ3lAr098860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Dec 2008 12:03:55 -0700 (MST) (envelope-from [email-masked])
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBVJ3nwQ024232 for ; Wed, 31 Dec 2008 14:03:49 -0500
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id mBVJ3W6G025792 for ; Wed, 31 Dec 2008 14:03:33 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 14:03:32 -0500
From: "David A. Cooper"
User-Agent: Thunderbird 2.0.0.18 (X11/20081120)
MIME-Version: 1.0
To: pkix
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information:
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

The attack (http://www.win.tue.nl/hashclash/rogue-ca) does not require
the attacker to know the order in which the extensions will appear or
the values that will appear in the extensions. The attacker only needs
to guess those portions of the DER encoded TBSCertificate that appear
before the subjectPublicKeyInfo field. Also the attack does not involve
including a "tumor" or any unrecognized extensions in the certificate
request. The "tumor" only appears in the rogue certificate that the CA
never sees.

Since the length of TBSCertificate appears at the beginning of the DER
encoding of TBSCertificate, anything that made the length unpredictable
would make things more difficult for the attacker. The extensions field
could be used for this, but one cannot reasonably vary the length of the
certificate by very much. It is much easier for the CA to prevent the
attacker from guessing the DER encoding of the part of TBSCertificate
that appears before the subjectPublicKeyInfo field by modifying
serialNumber, validity, or subject than to do so by modifying the
certificate's length. As Blake Ramsdell and I separately noted
yesterday, even if there is a requirement to use sequential serial
numbers, one can easily create a lot of unpredictability in an
unobtrusive fashion by simply randomly setting the notBefore and
notAfter times to some values that are within a few minutes of the times
that would have been used otherwise.

Dave

P.S. I am only subscribed to PKIX, so I am assuming that I cannot send
this message to the other mail lists that received the original message,
but others may feel free to forward it.

Mike wrote:
>
> I sent my last message a bit too hastily. Other ideas that I was
> contemplating should have been mentioned including:
>
> - remove any unrecognized extensions
> - remove tumors
>
> Those could potentially cause problems if for some reason they were
> actually needed. This one, though, shouldn't cause trouble:
>
> - add a private EKU with a random number (or two) in the OID
>
> That would not mess up the serial number scheme in use or modify the
> subject name as has been suggested.
>
> Mike
>
>
> I wrote:
>> There is a simple fix -- a CA can just reorder the extensions prior
>> to issuing a certificate.
>>
>> Mike
>
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIuUhd098366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:56:30 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIuUBb098363; Wed, 31 Dec 2008 11:56:30 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVIuSSC098350 for ; Wed, 31 Dec 2008 11:56:29 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 4657 invoked from network); 31 Dec 2008 18:56:51 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:56:51 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:56:51 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Date: Wed, 31 Dec 2008 13:56:27 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclreTiLOa9qi39USCibRTE4UToJHQAABQ1A
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "Timothy J. Miller"
Cc: "Dr Stephen Henson" , , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

You have some time there and work with client vendors to implement
SHA-256 and next generation SHA.

I would support a random value extension if clients checked for it.

-----Original Message-----
From: Timothy J. Miller [mailto:[email-masked]]=20
Sent: Wednesday, December 31, 2008 1:54 PM
To: Santosh Chokhani
Cc: Dr Stephen Henson; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

Santosh Chokhani wrote:

> So, if you are relying on CAs, why not ask them to switch to SHA-1 as
> opposed to adding more software to the CA. SHA-1 is purely a
> configuration item for the CA deployments.

Because someday SHA-1 (and SHA-2, or any hash algorithm) may be subject=20
to a similar collision generation attack, and the presence of=20
unpredictable data in the cert will defeat it as well.

Just trying to be proactive here.

-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIsXFm098231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:54:34 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIsXNW098230; Wed, 31 Dec 2008 11:54:33 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIsWLG098215; Wed, 31 Dec 2008 11:54:32 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIsUIg021783; Wed, 31 Dec 2008 13:54:31 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIsUrK021773; Wed, 31 Dec 2008 13:54:30 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:54:30 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 12:53:59 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Santosh Chokhani
CC: Dr Stephen Henson , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010106060408020209040905"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Santosh Chokhani wrote:

> So, if you are relying on CAs, why not ask them to switch to SHA-1 as
> opposed to adding more software to the CA. SHA-1 is purely a
> configuration item for the CA deployments.

Because someday SHA-1 (and SHA-2, or any hash algorithm) may be subject
to a similar collision generation attack, and the presence of
unpredictable data in the cert will defeat it as well.

Just trying to be proactive here.

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEyMzExODUzNTlaMCMGCSqGSIb3DQEJBDEWBBRvm0ZUBx2kUMXPZMdTcjy9VsI7hTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgFfgtFy7Di89XncxZPvVvOWVa1zy05iBeqhstrmEKD0MBObvNiR0lbvnC/Xt
VQOKE9jnfS6QSzzE2Iik8Y92fDAhbOWgKdlWcxV9q4+qHjf4Q9aefulpw1SObVxtCcHGhSCt
i64UPYyummro3guFQumjkhIxhu8Wcy9LbvN3z1yrAAAAAAAA
--------------ms010106060408020209040905--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIoGWb097941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:50:16 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIoGo9097940; Wed, 31 Dec 2008 11:50:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVIoE0c097927 for ; Wed, 31 Dec 2008 11:50:15 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 4597 invoked from network); 31 Dec 2008 18:50:37 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:50:37 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:50:37 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Date: Wed, 31 Dec 2008 13:50:13 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclrdpWRZ2DsZT93SYeylkbr3Wg+mAAAUebw
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "Timothy J. Miller"
Cc: "Dr Stephen Henson" , , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

These things need to be thought through.

If all the CAs did this, it might work. But, what if the client side
was looking for junk in the certificate as evidence of collision?

Also, client will not enforce this.

So, if you are relying on CAs, why not ask them to switch to SHA-1 as
opposed to adding more software to the CA. SHA-1 is purely a
configuration item for the CA deployments.

I just find that all three mail lists are getting work out and real
message and analysis is getting lost.

For example, folks are still posting misinformation that self-signed
roots have a hash problem. Signatures on self-signed roots are
gratuitous from security viewpoint. So, we do not want to cry wolf and
undertaken replacing roots which will be a humongous waste to time and
money. Signatures and hence hash used to sign these do not matter. =20

-----Original Message-----
From: Timothy J. Miller [mailto:[email-masked]]=20
Sent: Wednesday, December 31, 2008 1:35 PM
To: Santosh Chokhani
Cc: Dr Stephen Henson; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

Santosh Chokhani wrote:
> I am a bit concerned about random goo when random goo is one of the
> things the attacker uses to cause collision. This may limit human or
> machine's ability to discern mischief.

I don't see how, if the random goo is added by the CA. It defeats=20
chosen prefix attacks as a class.

-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIZgIw096978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:35:42 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIZgjE096977; Wed, 31 Dec 2008 11:35:42 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIZesj096966; Wed, 31 Dec 2008 11:35:40 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIZdvc006788; Wed, 31 Dec 2008 13:35:40 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIZdEj006785; Wed, 31 Dec 2008 13:35:39 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:35:39 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 12:35:09 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Santosh Chokhani
CC: Dr Stephen Henson , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010007000707070000040106"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Santosh Chokhani wrote:
> I am a bit concerned about random goo when random goo is one of the
> things the attacker uses to cause collision. This may limit human or
> machine's ability to discern mischief.

I don't see how, if the random goo is added by the CA. It defeats
chosen prefix attacks as a class.

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEyMzExODM1MDlaMCMGCSqGSIb3DQEJBDEWBBQ7wSCe4F6a7ye+v4kS0uvOGSEZxjBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgCTIqWUo25RX2p72ZoyshHyXDNPdtnFa2cGv0bRgIZSCX0rIi5+1Nl8n3imi
L3lCMkQOeE0Ai3QU62e1BzsBzXl4VavVhoeb8JHhzeTZAdrXmxQCJ48CB4R1k+TKB8mtkCCT
E1FJ8rPqf9EeE4BVdvHvPSb8zf3mUy3iG4rA9D7zAAAAAAAA
--------------ms010007000707070000040106--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIYbiD096921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:34:37 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIYbHd096920; Wed, 31 Dec 2008 11:34:37 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIYZ0D096908; Wed, 31 Dec 2008 11:34:35 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIYY60003982; Wed, 31 Dec 2008 13:34:35 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIYYd0003979; Wed, 31 Dec 2008 13:34:34 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:34:34 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 12:34:04 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Dr Stephen Henson
CC: "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070406060900010800080503"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Timothy J. Miller wrote:
> Dr Stephen Henson wrote:
>> Mike wrote:
>>> I sent my last message a bit too hastily. Other ideas that I was
>>> contemplating should have been mentioned including:
>>>
>>> - remove any unrecognized extensions
>>> - remove tumors
>>>
>>> Those could potentially cause problems if for some reason they were
>>> actually needed. This one, though, shouldn't cause trouble:
>>>
>>> - add a private EKU with a random number (or two) in the OID
>>>
>>> That would not mess up the serial number scheme in use or modify the
>>> subject name as has been suggested.
>>>
>>
>> Or add a non-critical extension with some randomness in it...
>
> Do you want to propose id-ce-magicCookie OBJECT IDENTIFIER ::= {id-ce
> 55} or should I? :)

draft-01 already: Make that id-ce-magicNumber instead. :)

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEyMzExODM0MDRaMCMGCSqGSIb3DQEJBDEWBBSSJNMK3zrvAhp1fLThyKuCS2ZbzDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgChOMbV+0oDSDKO7kDjIuxQIjRDbYZag6cll5l/fgLT0BVA+ko8npPtOmf1v
ctmCWIwx3wUmGBqLvXlnZIJ17XPwuT8Pkkqwte0q7M4aY3HW0J7UICoVIi9PXBsV75NklUR9
nh8lnb3TROTWQO2G2MG/8Z7Po5Sw1wOvBlDbyElIAAAAAAAA
--------------ms070406060900010800080503--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIUkZQ096660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:30:46 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIUk5u096659; Wed, 31 Dec 2008 11:30:46 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIUiF3096646; Wed, 31 Dec 2008 11:30:44 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIUhxA026624; Wed, 31 Dec 2008 13:30:44 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIUh7u026614; Wed, 31 Dec 2008 13:30:43 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:30:43 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 12:30:13 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Dr Stephen Henson
CC: "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060500070900000409080503"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Dr Stephen Henson wrote:
> Mike wrote:
>> I sent my last message a bit too hastily. Other ideas that I was
>> contemplating should have been mentioned including:
>>
>> - remove any unrecognized extensions
>> - remove tumors
>>
>> Those could potentially cause problems if for some reason they were
>> actually needed. This one, though, shouldn't cause trouble:
>>
>> - add a private EKU with a random number (or two) in the OID
>>
>> That would not mess up the serial number scheme in use or modify the
>> subject name as has been suggested.
>>
>
> Or add a non-critical extension with some randomness in it...

Do you want to propose id-ce-magicCookie OBJECT IDENTIFIER ::= {id-ce
55} or should I? :)

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEyMzExODMwMTNaMCMGCSqGSIb3DQEJBDEWBBTDOGnW2taEtjPNTda+B7sp3jwHXjBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgI4Tiunxma0T7GovwYWUekJusn0Fg6S544dlebV3nxswPVkGqdvuGRb4yaBq
qYonL0ehGR+ZMi1kFYNOLd0bBOibJOtHdubkqmjHMBENsjbiaUnFwd8pN4NW0GIinVLnUTYa
1vfzSaor2vdmDWTBBGF8QAXJPFF76ZsLkkqoz8BJAAAAAAAA
--------------ms060500070900000409080503--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIOWGQ096306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:24:32 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIOWbd096304; Wed, 31 Dec 2008 11:24:32 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIOKme096278; Wed, 31 Dec 2008 11:24:31 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIOK0d010078; Wed, 31 Dec 2008 13:24:20 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIOKfI010073; Wed, 31 Dec 2008 13:24:20 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:24:20 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 12:23:50 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Santosh Chokhani
CC: Mike , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010602050007000404020402"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

How about adding an otherName to the SAN? You'd need an OID for random
data though.

Or the CA could insert a method 4 UUID as a URI in the SAN. That's
intentionally random. This might upset anyone wanting to use UUIDs as
unique names, though (and these people do exist :).

Just thinking out loud.

-- Tim

Santosh Chokhani wrote:
> Private EKU could cause problems if EKU is not otherwise present in the
> certificate.
>
> The certificate may not be usable for intended purpose. Not all clients
> may recognize "any key purpose" as intended by 5280.
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Mike
> Sent: Wednesday, December 31, 2008 12:50 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
> CAcertificate
>
>
> I sent my last message a bit too hastily. Other ideas that I was
> contemplating should have been mentioned including:
>
> - remove any unrecognized extensions
> - remove tumors
>
> Those could potentially cause problems if for some reason they were
> actually needed. This one, though, shouldn't cause trouble:
>
> - add a private EKU with a random number (or two) in the OID
>
> That would not mess up the serial number scheme in use or modify the
> subject name as has been suggested.
>
> Mike
>
>
> I wrote:
>> There is a simple fix -- a CA can just reorder the extensions prior
>> to issuing a certificate.
>>
>> Mike
>

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEyMzExODIzNTBaMCMGCSqGSIb3DQEJBDEWBBTEu3+INXFh8y7RIME+TF+hrvAoaTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgFUNkYNyIak1Rk2H6NPqM7XEBS4j05b8blOT9+hLnMM2Lwb+t6eFS8jW88JJ
MaI6+q3G3oh7PiX3BXiOI8IxlNBAi0a6kegxF9sFnt7Kzrw6Tw8OvefCiDISs8QEWbTFv49g
ISeuzouWk+0O/27KhDbO0Y+JG4BzqQeu4tCJRnLnAAAAAAAA
--------------ms010602050007000404020402--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIO1iw096255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:24:01 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIO1jZ096254; Wed, 31 Dec 2008 11:24:01 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVINoec096227 for ; Wed, 31 Dec 2008 11:24:00 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 4386 invoked from network); 31 Dec 2008 18:24:12 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:24:12 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:24:12 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Date: Wed, 31 Dec 2008 13:23:49 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclrdI9/sOJPqIrSRxWmhrDCQYi/6wAADprw
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "Dr Stephen Henson" ,
Cc: , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I am a bit concerned about random goo when random goo is one of the
things the attacker uses to cause collision. This may limit human or
machine's ability to discern mischief.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Dr Stephen Henson
Sent: Wednesday, December 31, 2008 1:12 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

Mike wrote:
>=20
> I sent my last message a bit too hastily. Other ideas that I was
> contemplating should have been mentioned including:
>=20
> - remove any unrecognized extensions
> - remove tumors
>=20
> Those could potentially cause problems if for some reason they were
> actually needed. This one, though, shouldn't cause trouble:
>=20
> - add a private EKU with a random number (or two) in the OID
>=20
> That would not mess up the serial number scheme in use or modify the
> subject name as has been suggested.
>=20

Or add a non-critical extension with some randomness in it...

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

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIBf09095597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:11:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIBfGH095594; Wed, 31 Dec 2008 11:11:41 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay10.mail.uk.clara.net (relay10.mail.uk.clara.net [80.168.70.190]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIBTXB095574; Wed, 31 Dec 2008 11:11:40 -0700 (MST) (envelope-from [email-masked])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49616 helo=[192.168.7.8]) by relay10.mail.uk.clara.net with esmtpa (Exim 4.69) (envelope-from ) id 1LI5XR-0000nh-An; Wed, 31 Dec 2008 18:11:26 +0000
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 18:11:35 +0000
From: Dr Stephen Henson
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Mike wrote:
>
> I sent my last message a bit too hastily. Other ideas that I was
> contemplating should have been mentioned including:
>
> - remove any unrecognized extensions
> - remove tumors
>
> Those could potentially cause problems if for some reason they were
> actually needed. This one, though, shouldn't cause trouble:
>
> - add a private EKU with a random number (or two) in the OID
>
> That would not mess up the serial number scheme in use or modify the
> subject name as has been suggested.
>

Or add a non-critical extension with some randomness in it...

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

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVI3Gpv095203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:03:16 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVI3GDN095201; Wed, 31 Dec 2008 11:03:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVI3Erg095186 for ; Wed, 31 Dec 2008 11:03:15 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 4249 invoked from network); 31 Dec 2008 18:03:37 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:03:37 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:03:37 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Date: Wed, 31 Dec 2008 13:03:13 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclrcaZvjthE5F+NRLKwI78nj+9Z5AAACsDQ
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "Mike" ,
Cc: , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Private EKU could cause problems if EKU is not otherwise present in the
certificate.

The certificate may not be usable for intended purpose. Not all clients
may recognize "any key purpose" as intended by 5280.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Mike
Sent: Wednesday, December 31, 2008 12:50 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

I sent my last message a bit too hastily. Other ideas that I was
contemplating should have been mentioned including:

- remove any unrecognized extensions
- remove tumors

Those could potentially cause problems if for some reason they were
actually needed. This one, though, shouldn't cause trouble:

- add a private EKU with a random number (or two) in the OID

That would not mess up the serial number scheme in use or modify the
subject name as has been suggested.

Mike

I wrote:
> There is a simple fix -- a CA can just reorder the extensions prior
> to issuing a certificate.
>=20
> Mike

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVHoasA094528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 10:50:36 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVHoawe094525; Wed, 31 Dec 2008 10:50:36 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVHoPh7094500; Wed, 31 Dec 2008 10:50:35 -0700 (MST) (envelope-from [email-masked])
Received: from localhost.localdomain (unknown [127.0.0.1]) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 88E0F1B777; Wed, 31 Dec 2008 12:50:24 -0500 (EST)
Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id B7C771B787; Wed, 31 Dec 2008 12:50:19 -0500 (EST)
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 09:49:45 -0800
From: Mike
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 80508BAC-D763-11DD-889F-F83E113D384A-38729857!a-sasl-quonix.pobox.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I sent my last message a bit too hastily. Other ideas that I was
contemplating should have been mentioned including:

- remove any unrecognized extensions
- remove tumors

Those could potentially cause problems if for some reason they were
actually needed. This one, though, shouldn't cause trouble:

- add a private EKU with a random number (or two) in the OID

That would not mess up the serial number scheme in use or modify the
subject name as has been suggested.

Mike

I wrote:
> There is a simple fix -- a CA can just reorder the extensions prior
> to issuing a certificate.
>
> Mike

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVH4LtH091875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 10:04:21 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVH4Lhn091873; Wed, 31 Dec 2008 10:04:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVH4AP1091758; Wed, 31 Dec 2008 10:04:20 -0700 (MST) (envelope-from [email-masked])
Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id A7EB98CD08; Wed, 31 Dec 2008 12:04:09 -0500 (EST)
Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id AD05D8CCFD; Wed, 31 Dec 2008 12:04:05 -0500 (EST)
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 09:03:37 -0800
From: Mike
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 0A5CA3DC-D75D-11DD-B70C-5720C92D7133-38729857!a-sasl-fastnet.pobox.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> We are simply not vigilant enough. This issue has been on our plate
> since 2004.
>
> SHA-1 is next and neither the client side vendors nor the big
> Enterprises have pushed to move to SHA-256.

There is a simple fix -- a CA can just reorder the extensions prior
to issuing a certificate.

Mike

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFbC6Z087821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:37:12 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVFbCqc087819; Wed, 31 Dec 2008 08:37:12 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVFaxkC087772 for ; Wed, 31 Dec 2008 08:37:10 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 28690 invoked from network); 31 Dec 2008 15:36:57 -0000
Received: from [email-masked] by sottccs1.entrust.com with EntrustECS-Server-8.0;31 Dec 2008 15:36:57 -0000
Received: from unknown (HELO sottexch1.corp.ad.entrust.com) (10.4.51.28) by sottccs1.entrust.com with SMTP; 31 Dec 2008 15:36:56 -0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="--=_NextPart_EE_103656811.38200976"
Date: Wed, 31 Dec 2008 10:36:56 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclrXBEEqsU/Y6e/ROuPhuoyz8ZfcAAAQNmw
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]>
From: "Tim Moses"
To: "Timothy J. Miller"
Cc: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

----=_NextPart_EE_103656811.38200976
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Colleagues - It has been confirmed that no EV issuer is signing certific=
ates with MD5. Also, EV certificates cannot be issued by an automated p=
rocess, putting another obstacle in the path of an attacker. All the be=
st. Tim.

Tim Moses
+1 613 270 3183

-----Original Message-----
From: owner-ietf-smime=40mail.imc.org =5Bmailto:owner-ietf-smime=40mail.=
imc.org=5D On Behalf Of Timothy J. Miller
Sent: Wednesday, December 31, 2008 10:18 AM
To: Santosh Chokhani
Cc: ietf-pkix=40imc.org; ietf-smime=40imc.org; cfrg=40irtf.org; saag=40i=
etf.org
Subject: Re: =5BCfrg=5D =5Bsaag=5D Further MD5 breaks: Creating a rogue C=
Acertificate

Santosh Chokhani wrote:
> One would think we want to start using SHA-1 or even SHA256 (assuming=20
> client vendors implement SHA256 ASAP) and ask the CAs emanating from=20
> commercial roots to perform responsible I&A before issuing certificate=
s.

Speaking of I&A, I found it interesting to note that the CA/Browser foru=
m guidelines for EV certs allows (but recommends against) MD5 until 2010=
=2E

The spot check of EV issuers I did yesterday didn't turn up anyone actua=
lly using MD5, but I didn't have all of 'em available.

-- Tim

----=_NextPart_EE_103656811.38200976
Content-Type: application/pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCTAHBgUrDgMCGjCABgkqhkiG9w0BBwEAAKCCIIIwggKf
MIICCKADAgECAgRGJ7vgMA0GCSqGSIb3DQEBBQUAMCwxCzAJBgNVBAYTAkNBMR0wGwYDVQQK
ExRFbnRydXN0IFRlY2hub2xvZ2llczAeFw0wODA1MDcxMzA4MzlaFw0xMTA1MDcxMzM4Mzla
MDIxCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczCB
nTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEA0IBgoGWlwptmAbxopaoSELaZIvJHlWg+vqcq
kQlA6mSAzTEHQl79k5aUq4cPZQTK5SnsUoY3aPN8IyTN8+SDmIJ/3qwFvxG1Xkbi1UDo6qB/
TR1zwBoxpz7iL8XH5gLWSaijFab+bMeTamSeL05l0JjF0AoAmxnwAjU7Zl4kdWkCAQOjgckw
gcYwHQYDVR0OBBYEFAUkiCBOsLJRzMuh2elnJIbV+bBFME4GA1UdHwRHMEUwQ6BBoD+kPTA7
MQswCQYDVQQGEwJDQTEdMBsGA1UEChMURW50cnVzdCBUZWNobm9sb2dpZXMxDTALBgNVBAMT
BENSTDEwCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFDGPKjFGWl7oabci0fgBq6xQXgF1MAwG
A1UdEwQFMAMBAf8wGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCAIEwDQYJKoZIhvcNAQEFBQAD
gYEAbdDF5a/A+vjthvR7ofXzM3UxI/62yW9yJPzQ7sN1AS9zKgPB9Nm4tySDwSeFvqQ1/KOv
JTEeYABGRaZ1YrTXc2mFhTlcLQAZ16DsS2VxnKqhEVWq4JaUaJAe9qvKvdkvpDieKQMkfM0c
WZCa9b396rZKqSd+j86yP6FauYSrw6wwggLfMIICSKADAgECAgRGS07GMA0GCSqGSIb3DQEB
BQUAMC4xCzAJBgNVBAYTAmNhMRAwDgYDVQQKEwdlbnRydXN0MQ0wCwYDVQQLEwRQcm9kMB4X
DTA3MDUyMjE0NTQ0N1oXDTEwMDUyMjE1MjQ0N1owLDELMAkGA1UEBhMCQ0ExHTAbBgNVBAoT
FEVudHJ1c3QgVGVjaG5vbG9naWVzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5SPAE
WITHCc04wRiDaJpJY8ZF7bCJ1ohhSyKRA2ouJ+sjRMqzfxXcxQTKuE4GQg1dvZjvmmZJq5KZ
71yZnvK+Kb1ixXP1y/zAy6CiiatTPrf8SNzXpSDon3VdKo8zuKQ6ELKaWP3nK4O4eOiXdmfn
a2bOLzFi7TpKICfieMOdlQIDAQABo4IBCjCCAQYwHQYDVR0OBBYEFDGPKjFGWl7oabci0fgB
q6xQXgF1MIGNBgNVHR8EgYUwgYIwRaBDoEGkPzA9MQswCQYDVQQGEwJjYTEQMA4GA1UEChMH
ZW50cnVzdDENMAsGA1UECxMEUHJvZDENMAsGA1UEAxMEQ1JMMTA5oDegNYYzZmlsZTovL1xc
U09UVFBST0RDQVxDUkxccHJvZF9lbnRydXN0X2NhX2NybGZpbGUuY3JsMAsGA1UdDwQEAwIB
BjAfBgNVHSMEGDAWgBTR5DvPp2uwBfGx/my5EmQy0JQbujAMBgNVHRMEBTADAQH/MBkGCSqG
SIb2fQdBAAQMMAobBFY3LjEDAgCBMA0GCSqGSIb3DQEBBQUAA4GBAEnSrabNwGiiZNjhIFce
7VctEE5uR6RaADbc6hszcn50pYoliCY5T53dUpOvznUuDX0HWFfH+YXl3Isol2p0DbSSAFNv
8OWyEAd2SoYRinBNpMOyQlrTWt5FBiCB2dglbxx/I2eyTqr5COy8u/ijLKvVn00yBf3f1kCw
d+//jQluMIIC7TCCAlagAwIBAgIEMkbEozANBgkqhkiG9w0BAQUFADAyMQswCQYDVQQGEwJD
QTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5lc3MwHhcNOTgwODE5MTkxMjA2
WhcNMTgwODE5MTk0MjA2WjAyMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8G
A1UECxMIQnVzaW5lc3MwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBANCAYKBlpcKbZgG8
aKWqEhC2mSLyR5VoPr6nKpEJQOpkgM0xB0Je/ZOWlKuHD2UEyuUp7FKGN2jzfCMkzfPkg5iC
f96sBb8RtV5G4tVA6Oqgf00dc8AaMac+4i/Fx+YC1kmooxWm/mzHk2pkni9OZdCYxdAKAJsZ
8AI1O2ZeJHVpAgEDo4IBEDCCAQwwEQYJYIZIAYb4QgEBBAQDAgAHMFQGA1UdHwRNMEswSaBH
oEWkQzBBMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5l
c3MxDTALBgNVBAMTBENSTDEwKwYDVR0QBCQwIoAPMTk5ODA4MTkxOTEyMDZagQ8yMDE4MDgx
OTE5MTIwNlowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFAUkiCBOsLJRzMuh2elnJIbV+bBF
MB0GA1UdDgQWBBQFJIggTrCyUczLodnpZySG1fmwRTAMBgNVHRMEBTADAQH/MBkGCSqGSIb2
fQdBAAQMMAobBFY0LjADAgSQMA0GCSqGSIb3DQEBBQUAA4GBAJg+gIo2VG7EqPRBAJ3Q6sho
xP/8pMCk/3UyKbuu4En4aRn+5kAXmjhqJR98uZsR89G5S1I68pn+xhg6FK3gNgC/OLOZ6bRG
ABcQGkRov8vvIoJPRRN3JYcAyJSRykY2CZhPsW99pO69qlxS4lRIfIFuflaXs7PY2LTzftsO
6o1cMIIDJTCCAo6gAwIBAgIERktOCjANBgkqhkiG9w0BAQUFADAuMQswCQYDVQQGEwJjYTEQ
MA4GA1UEChMHZW50cnVzdDENMAsGA1UECxMEUHJvZDAeFw0wNzA1MTYxODAxMzhaFw0xNzA1
MTYxODMxMzhaMC4xCzAJBgNVBAYTAmNhMRAwDgYDVQQKEwdlbnRydXN0MQ0wCwYDVQQLEwRQ
cm9kMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCpd6zp2+OYdJe2JvS/+IlSax3c1GWf
xpm/6G11szZ9iRTy0UCpcVZ7e7pEnu/ySNSDN0CLFfj2XMnC2b5YgnuL9/rDz+jVCylLJbuJ
HjpYmGWQqG1vbmSUBQeH9TCdTHEqScibjV77r81cfyOpjWe0iETErEUlq5jsnuZOYKkuXQID
AQABo4IBTjCCAUowEQYJYIZIAYb4QgEBBAQDAgAHMIGNBgNVHR8EgYUwgYIwRaBDoEGkPzA9
MQswCQYDVQQGEwJjYTEQMA4GA1UEChMHZW50cnVzdDENMAsGA1UECxMEUHJvZDENMAsGA1UE
AxMEQ1JMMTA5oDegNYYzZmlsZTovL1xcU09UVFBST0RDQVxDUkxccHJvZF9lbnRydXN0X2Nh
X2NybGZpbGUuY3JsMCsGA1UdEAQkMCKADzIwMDcwNTE2MTgwMTM4WoEPMjAxNzA1MTYxODMx
MzhaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBTR5DvPp2uwBfGx/my5EmQy0JQbujAdBgNV
HQ4EFgQU0eQ7z6drsAXxsf5suRJkMtCUG7owDAYDVR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAE
EDAOGwhWNy4xOjQuMAMCBJAwDQYJKoZIhvcNAQEFBQADgYEAWATjTT62BcA4MaxLVJTG5alA
BUYnKzbtbpoZrckpmEVZfcoLooJcgRq58DeGVihhvl9lfUOE3YIQUFxDXA6svFD8Fn99y3Iy
RGM+itL/rRdbSAlH2Xa6HLBhjTJff9oa6n67WW/RU0106O8jqS3bcVjWeI0WLh7LKxxHnGz3
TFUwggMwMIICmaADAgECAgQ4xeeqMA0GCSqGSIb3DQEBBQUAMDIxCzAJBgNVBAYTAkNBMRAw
DgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczAeFw0wNDA5MjkxNzExNThaFw0w
ODA5MjkxNzQxNThaMDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQL
EwdSIGFuZCBEMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvIeIjfoD5D86sD8C
ehB+kVhYJTL+VuaUZiVijGevUTlnUAwy1WpOYVpFCa8VK116TJ+o99axN1jMbsVBYfRzFk9S
Wl4iAH+PyJ1S6D5Yl593KjHPhBCfdD0v9KoPqXhCwRlkvupreNlFx3FFk2Uf5jG/i9SCP925
OXbz3wod2mdIu8ueNWgTmA2XAOBdHZg6HYKo50BWUIgtRwFvzbh1J57+gNdHxMYLZmvj5saS
1mDTSibkPH/AY+D+xAozRmyOYa4SY2HVfZSM2SP7MkuVtKp17pzhwicoWAGKXrKeDRWDYeZB
TJjHoNP/SXKdpSzY7rV8GPrfWFoogc4350VbowIDAQABo4HPMIHMMB0GA1UdDgQWBBTz8Cwo
5jmnNBmrmpGopmZAkpzicTBUBgNVHR8ETTBLMEmgR6BFpEMwQTELMAkGA1UEBhMCQ0ExEDAO
BgNVBAoTB0VudHJ1c3QxETAPBgNVBAsTCEJ1c2luZXNzMQ0wCwYDVQQDEwRDUkwxMAsGA1Ud
DwQEAwIBBjAfBgNVHSMEGDAWgBQFJIggTrCyUczLodnpZySG1fmwRTAMBgNVHRMEBTADAQH/
MBkGCSqGSIb2fQdBAAQMMAobBFY3LjADAgCBMA0GCSqGSIb3DQEBBQUAA4GBAI8B1Aa8TTla
mxl1BgP6ch4CZUEADT/1xNwEaPveZFajVrURlnKqMfDQ704aNc2qFnLHJDI3dS49vJEJ8LsK
Hvd7sf6WqRCuGkF3D8qsIWKxBK6muWdSfKAYWLB/4wDm2CcZDyXt/A3OYFjMzQ5pVBKeAXNA
k6fZ32SGLVNvVqc/MIIDMDCCApmgAwIBAgIESCCkSzANBgkqhkiG9w0BAQUFADAyMQswCQYD
VQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5lc3MwHhcNMDgwOTI0
MTQzNjA0WhcNMTIwOTI0MTUwNjA0WjAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVz
dDEQMA4GA1UECxMHUiBhbmQgRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALyH
iI36A+Q/OrA/AnoQfpFYWCUy/lbmlGYlYoxnr1E5Z1AMMtVqTmFaRQmvFStdekyfqPfWsTdY
zG7FQWH0cxZPUlpeIgB/j8idUug+WJefdyoxz4QQn3Q9L/SqD6l4QsEZZL7qa3jZRcdxRZNl
H+Yxv4vUgj/duTl2898KHdpnSLvLnjVoE5gNlwDgXR2YOh2CqOdAVlCILUcBb824dSee/oDX
R8TGC2Zr4+bGktZg00om5Dx/wGPg/sQKM0ZsjmGuEmNh1X2UjNkj+zJLlbSqde6c4cInKFgB
il6yng0Vg2HmQUyYx6DT/0lynaUs2O61fBj631haKIHON+dFW6MCAwEAAaOBzzCBzDAdBgNV
HQ4EFgQU8/AsKOY5pzQZq5qRqKZmQJKc4nEwVAYDVR0fBE0wSzBJoEegRaRDMEExCzAJBgNV
BAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczENMAsGA1UEAxME
Q1JMMTALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUBSSIIE6wslHMy6HZ6WckhtX5sEUwDAYD
VR0TBAUwAwEB/zAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIAgTANBgkqhkiG9w0BAQUFAAOB
gQDHUhDfQdNFmborkeOSyqtTmpiIESBES6KULodyCmdHbcoV4L1H5vpjBO0HdUx+YXlIZxUj
pTKDv2mowbCAdcWihfW3LjY+3RoqoMu2iR8nSDexR+TesS8drRF9Mrmy30/ddj+sneR7KeaG
KL8WGcZBDmxGIvoOaCYGuxsgrC9/LzCCA2gwggLRoAMCAQICBEZLTsUwDQYJKoZIhvcNAQEF
BQAwLjELMAkGA1UEBhMCY2ExEDAOBgNVBAoTB2VudHJ1c3QxDTALBgNVBAsTBFByb2QwHhcN
MDcwNTIyMTQ0MTIxWhcNMTAwNTIyMTUxMTIxWjAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMH
RW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALyHiI36A+Q/OrA/AnoQfpFYWCUy/lbmlGYlYoxnr1E5Z1AMMtVqTmFaRQmvFStdekyf
qPfWsTdYzG7FQWH0cxZPUlpeIgB/j8idUug+WJefdyoxz4QQn3Q9L/SqD6l4QsEZZL7qa3jZ
RcdxRZNlH+Yxv4vUgj/duTl2898KHdpnSLvLnjVoE5gNlwDgXR2YOh2CqOdAVlCILUcBb824
dSee/oDXR8TGC2Zr4+bGktZg00om5Dx/wGPg/sQKM0ZsjmGuEmNh1X2UjNkj+zJLlbSqde6c
4cInKFgBil6yng0Vg2HmQUyYx6DT/0lynaUs2O61fBj631haKIHON+dFW6MCAwEAAaOCAQow
ggEGMB0GA1UdDgQWBBTz8Cwo5jmnNBmrmpGopmZAkpzicTCBjQYDVR0fBIGFMIGCMEWgQ6BB
pD8wPTELMAkGA1UEBhMCY2ExEDAOBgNVBAoTB2VudHJ1c3QxDTALBgNVBAsTBFByb2QxDTAL
BgNVBAMTBENSTDEwOaA3oDWGM2ZpbGU6Ly9cXFNPVFRQUk9EQ0FcQ1JMXHByb2RfZW50cnVz
dF9jYV9jcmxmaWxlLmNybDALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAU0eQ7z6drsAXxsf5s
uRJkMtCUG7owDAYDVR0TBAUwAwEB/zAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIAgTANBgkq
hkiG9w0BAQUFAAOBgQCQBw6L+mclwk7Z64xW4jbrS1CZpTHFGNmVuow0GbxBdFWHsDNE9H0s
4AUS59qW2T8JQRhm062vhZwpj29bCkOwDgciGq2POfOachGypOnV09x5Dcs3s+5M7c3gpbEP
dcO8G7GPIcociDNPPj+Kd8ceoMvcZySp22u4MWuI1bOxyjCCA28wggJXoAMCAQICBEZD+x4w
DQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNV
BAsTB1IgYW5kIEQwHhcNMDgxMDIxMTMyOTM2WhcNMDkwNDIxMTM1OTM2WjBVMQswCQYDVQQG
EwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEiMA4GA1UEBRMHMDUw
NDA2NzAQBgNVBAMTCVRpbSBNb3NlczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0gtt
TXg2dN9WsLP92LJQzIYPjdXOXewCcdviTglJfIFKO+RU3O76TPR6pKsZNgPADZL6Q0QHo5I2
ygrRBXCnMOH7xKutmI2QujgX5FW6kEFrHPRom65/XkuMXNW57BjRt+C4hXKU8fHp6WaiKhOM
It2WG2jTHU8IYcYnWiiK4dMCAwEAAaOB7jCB6zALBgNVHQ8EBAMCBSAwIAYDVR0RBBkwF4EV
dGltLm1vc2VzQGVudHJ1c3QuY29tMFQGA1UdHwRNMEswSaBHoEWkQzBBMQswCQYDVQQGEwJD
QTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEOMAwGA1UEAxMFQ1JMNDIw
HwYDVR0jBBgwFoAU8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYEFMXxKqPWd83GEHAC
aXkPSw+P2UHrMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCBLAwDQYJKoZI
hvcNAQEFBQADggEBAClPCYWYRjj5Q0uz74Ldr4FhH4KYkt35rgTXAWR9T2cSLbq6wssHiBS5
YGmM9lsYkQHXc9yPji03n9/Xco/0VjkZY2Fmc03f+3+6WkvvnfAbZFV0HfK1IR/i3hKC5vp9
D8DjcoSXOGwucv7L9iKARJ6jJSXIHl/fTIkt1gqtpfcSAesOhq9u/XO+zxGD8GL1tKF5k1F9
0GN5MQd7HNAZsrwEBDWAO7P3MbCBmOiArjno61cQMUU7k+tgMTt4W2Eeoc0yyzIrRtamz2q8
zbxmnKdEHt140yUXmsxuG04ZM2+iL/MtVD0F69WTAr2JNGsBeeNB8KMGDlCmM8Co2uQOSTkw
ggOeMIIChqADAgECAgRGQ/sdMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNVBAYTAkNBMRAwDgYD
VQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMB4XDTA4MTAyMTEzMjkzNloXDTA5MDQy
MTEzNTkzNlowVTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1Ig
YW5kIEQxIjAOBgNVBAUTBzA1MDQwNjcwEAYDVQQDEwlUaW0gTW9zZXMwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBALT3bXGkvn4caHYy/u5MXZsEw0q0/s9nj6j7wNkOkyrw394HoLN7
JY404tmf3zCa+qbCXS5eC9hmbU2Rdxo1eZhlB2sZpP/aY8KaHSzUAUcv0LmtQS25qEkSZkLn
WSgczRts/EvOf7q0U4COQwI0dP/vBNk+fvJ+jkjVRZxZX32dAgMBAAGjggEcMIIBGDALBgNV
HQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAwODEwMjExMzI5MzZagQ8yMDA5MDIyNTIyNTkzNlow
IAYDVR0RBBkwF4EVdGltLm1vc2VzQGVudHJ1c3QuY29tMFQGA1UdHwRNMEswSaBHoEWkQzBB
MQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEOMAwG
A1UEAxMFQ1JMNDIwHwYDVR0jBBgwFoAU8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYE
FCrFDow3ATgAarWOHil+N5udd2xJMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcu
MQMCBLAwDQYJKoZIhvcNAQEFBQADggEBAFGhTfDY3PVBPb1xQezRSKyd6kfj6d1Gl/rqsOk7
1skHSE89plfdYHMoNEBfSCkr+O2au7hx2DBLLK/zjfaqfpr5Scu8IsYz5LrNKsukP46qwOna
2yprT9VVyCsTuByOnG//9U2CEDIwCZ/GBw1i6MHCXssSdZIjxn5oxmO4OBDHhfBIFXT2vIKC
x/yEM+BgU+qWPu5T8V3Q3XR+kCE6jQDRp9cSTJy2Otzw+k+ASXASWO4hzEOH/X8Prd/lx1iS
clEK1lOXl5k4gCnQu/KcpM5CGKUhwFjcO9LJb/Xkeab4+Z8yEXSvNrjc5xLuFDW3BLaFPyNa
hWsrINpm/kC1goAwggP1MIIC3aADAgECAgQySKogMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNV
BAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMB4XDTAyMDQxNzAy
MjAyNloXDTIyMDQxNzAyNTAyNlowMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3Qx
EDAOBgNVBAsTB1IgYW5kIEQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8h4iN
+gPkPzqwPwJ6EH6RWFglMv5W5pRmJWKMZ69ROWdQDDLVak5hWkUJrxUrXXpMn6j31rE3WMxu
xUFh9HMWT1JaXiIAf4/InVLoPliXn3cqMc+EEJ90PS/0qg+peELBGWS+6mt42UXHcUWTZR/m
Mb+L1II/3bk5dvPfCh3aZ0i7y541aBOYDZcA4F0dmDodgqjnQFZQiC1HAW/NuHUnnv6A10fE
xgtma+PmxpLWYNNKJuQ8f8Bj4P7ECjNGbI5hrhJjYdV9lIzZI/syS5W0qnXunOHCJyhYAYpe
sp4NFYNh5kFMmMeg0/9Jcp2lLNjutXwY+t9YWiiBzjfnRVujAgMBAAGjggETMIIBDzARBglg
hkgBhvhCAQEEBAMCAAcwUwYDVR0fBEwwSjBIoEagRKRCMEAxCzAJBgNVBAYTAkNBMRAwDgYD
VQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMQ0wCwYDVQQDEwRDUkwxMCsGA1UdEAQk
MCKADzIwMDIwNDE3MDIyMDI2WoEPMjAyMjA0MTcwMjUwMjZaMAsGA1UdDwQEAwIBBjAfBgNV
HSMEGDAWgBTz8Cwo5jmnNBmrmpGopmZAkpzicTAdBgNVHQ4EFgQU8/AsKOY5pzQZq5qRqKZm
QJKc4nEwDAYDVR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAEEDAOGwhWNi4wOjQuMAMCBJAwDQYJ
KoZIhvcNAQEFBQADggEBAIA+ebVGmfnJrmQEsWlyRG3D5e5j8bmbq5Af2FVeB5yGn6Lr+1eV
iNDxxycnLUdw6Y9LvXwuQbh2vEF+uGM71pO52/5M0gxH2LNrLv3qGwGTutoGli3Fq84SPFvy
N+n4R6XO2BxJmjvfuZjNyuv2kOPMmV2yuILM8NT83TnZH5EnhGz/QiK5bMhUfvL31L076sbX
g+MQo1CEDf2BPCD2IwG1CiSwN8q7T1QJoWwTtphQLx4TTDOSLgb4OXlEoTnswZpgCH5xxybI
9HpfD+CXxijdgaE5bPepq0CFtumUAKb0tKZ24xItdDJuR7pyrklRvxz1UzOL1wiK/odt/X/E
5s8xggJoMIICZAIBATA5MDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYD
VQQLEwdSIGFuZCBEAgRGQ/sdMAcGBSsOAwIaoIIBiTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEyMzExNTM2NTZaMCMGCSqGSIb3DQEJBDEWBBRJYJQR
3LOeOmLPQl5+lI5BWAQlBjCCASgGCSqGSIb3DQEJDzGCARkwggEVMAoGCCqGSIb3DQMHMAcG
BSsOAwIaMAoGCCqGSIb3DQICMAoGCCqGSIb3DQIEMAoGCCqGSIb3DQIFMA4GCCqGSIb3DQME
AgIAgDANBggqhkiG9w0DBAIBKDAHBgUrDgMCBzAOBgkqhkiG9n0HQgMCAUAwDgYJKoZIhvZ9
B0IDAgEoMA8GCSqGSIb2fQdCCgICAIAwEQYLKwYBBAGBPAcBAQICAgCAMA8GCWCGSAFlAwQB
AgICAIAwDwYJYIZIAWUDBAEWAgIAwDAPBglghkgBZQMEASoCAgEAMA4GCCqGSIb3DQMCAgIA
gDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBODANBggqhkiG9w0DAgIBKDALBgkqhkiG
9w0BAQEEgYAZ5wG6uFoDAwofzu92qRcG76k3WrqXjHB3b6RsWMe+Jt5xlI2JRzHZbSD10yJu
ETUcGMyhvZEVDEwaR3dsN6N3kjF+WpqoK6OAQNA1OO6WmXXfpDJYsucllmfv+JWA0GX4M5Ux
uMCHY3dvQnet5UldSEs3dAMT6wfaMlkXHTghlwAAAAAAAA==
----=_NextPart_EE_103656811.38200976--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFLFWt087123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:21:15 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVFLFvN087121; Wed, 31 Dec 2008 08:21:15 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVFLD34087108 for ; Wed, 31 Dec 2008 08:21:13 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 3243 invoked from network); 31 Dec 2008 15:21:36 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 15:21:36 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 15:21:36 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Date: Wed, 31 Dec 2008 10:21:12 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclrWwxnY5KUcnr6RkKSgCgRHyNxcgAADcag
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]>
From: "Santosh Chokhani"
To: "Timothy J. Miller"
Cc: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

We are simply not vigilant enough. This issue has been on our plate
since 2004.

SHA-1 is next and neither the client side vendors nor the big
Enterprises have pushed to move to SHA-256.

-----Original Message-----
From: Timothy J. Miller [mailto:[email-masked]]=20
Sent: Wednesday, December 31, 2008 10:18 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

Santosh Chokhani wrote:
> One would think we want to start using SHA-1 or even SHA256 (assuming
> client vendors implement SHA256 ASAP) and ask the CAs emanating from
> commercial roots to perform responsible I&A before issuing
certificates.

Speaking of I&A, I found it interesting to note that the CA/Browser=20
forum guidelines for EV certs allows (but recommends against) MD5 until=20
2010.

The spot check of EV issuers I did yesterday didn't turn up anyone=20
actually using MD5, but I didn't have all of 'em available.

-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFIaeD086981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:18:36 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVFIaGL086979; Wed, 31 Dec 2008 08:18:36 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFIY1l086966; Wed, 31 Dec 2008 08:18:34 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVFIXwR002392; Wed, 31 Dec 2008 10:18:33 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVFIXZb002386; Wed, 31 Dec 2008 10:18:33 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 10:18:33 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 09:18:00 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Santosh Chokhani
CC: "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com>
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050306030909090007020003"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Santosh Chokhani wrote:
> One would think we want to start using SHA-1 or even SHA256 (assuming
> client vendors implement SHA256 ASAP) and ask the CAs emanating from
> commercial roots to perform responsible I&A before issuing certificates.

Speaking of I&A, I found it interesting to note that the CA/Browser
forum guidelines for EV certs allows (but recommends against) MD5 until
2010.

The spot check of EV issuers I did yesterday didn't turn up anyone
actually using MD5, but I didn't have all of 'em available.

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEyMzExNTE4MDBaMCMGCSqGSIb3DQEJBDEWBBTYJibxLOyG1SEmTVXB/AhI0/Bt8jBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgAZCH6+J56WxRyI0sA7T1gbC1tsCwYnjNsqIpESy0TwpwrdIYDgtwOARQOev
InbqiDYQerQmWIIH+ovlzYIUazy21FVc8ReHKFTXOrx4GLrDvGSwGfsDrc8Rz8l5dcP0rXUS
J6/YQsvvbM90MY/o0TBIWI2i8PG5c5mVmkkYr+E9AAAAAAAA
--------------ms050306030909090007020003--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVF4tQJ086353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:04:55 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVF4sib086351; Wed, 31 Dec 2008 08:04:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVF4gaD086329 for ; Wed, 31 Dec 2008 08:04:52 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 3140 invoked from network); 31 Dec 2008 15:05:05 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 15:05:05 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 15:05:04 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Further MD5 breaks: Creating a rogue CA certificate
Date: Wed, 31 Dec 2008 10:04:40 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Further MD5 breaks: Creating a rogue CA certificate
Thread-Index: AclrWAfbgnf2g3ujTbSdpg9MXzs4IAAANDWw
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Mini CRL are not a standard.

That said, using implementators agreement (based on whether high order
to low order bits are true serial number) one bit per certificate can be
assigned and the random prefix or appendage to the serial number
ignored.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Timothy J. Miller
Sent: Wednesday, December 31, 2008 9:43 AM
To: Russ Housley
Cc: Eric Rescorla; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Further MD5 breaks: Creating a rogue CA certificate

Russ Housley wrote:
>=20
>> I'm not sure I understand the issue here, but
>> they don't actually have to be totally randomized. You could use a
>> PRF so they were predictable to the CA.
>=20
> That works. This works too: the serial number could be composed of=20
> two parts, where the most significant bits are a counter and the=20
> least significant bits are randomly generated.

How would Corestreet's miniCRL format fare under this?

-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVEn07r085545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 07:49:00 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVEn06Z085543; Wed, 31 Dec 2008 07:49:00 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVEmnk9085526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 07:48:59 -0700 (MST) (envelope-from [email-masked])
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id BFE4650822; Wed, 31 Dec 2008 07:05:05 -0800 (PST)
Date: Wed, 31 Dec 2008 07:05:05 -0800
From: Eric Rescorla
To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
In-Reply-To:
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At Wed, 31 Dec 2008 14:20:39 +1300,
Peter Gutmann wrote:
>
> "Peter Hesse" writes:
>
> >Ceasing the issuance of certificates with MD5 used in the signature doesn't
> >solve the problem of the certificates that have already been issued and are
> >still out there, any number of which may be rogue.
> >
> >Replacing, or marking as untrusted all root certificates which have any
> >current valid (i.e. non-expired, non-revoked) certificates with MD5 used in
> >the signature could have tremendous undesirable impact and be an untenable
> >solution.
>
> I hate to be the one to point to the elephant in the room (well OK, I don't
> hate it, it's rather fun actually) but you need to keep this in perspective:
> one in ten AuthentiCode-signed Windows binaries is malware, and cybercrooks
> have no problems at all obtaining certs from commercial CAs using stolen
> identities and credentials for pretty much any use they want. The current MD5
> attack is very cool but there's no need to worry about bad guys doing much
> with it because it's much, much easier to get legitimate CA-issued certs the
> normal way, you buy them just like everyone else does (except that you use
> someone else's credit card and identity, obviously).
>
> In other words, if this problem is fixed, would anyone other than security
> geeks even notice? I doubt the crooks will.

Well, if we're going to be pointing ot the obvious, then code signing actually
seems kind of off-point as well. > 50% of IE users are not running up-to-date
copies of their browser.[0] In many cases this means that the browsers have
remote exploits. Why worry about AuthentiCode?

-Ekr

[0] http://www.techzoom.net/publications/insecurity-iceberg/index.en

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVEhec4085339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 07:43:40 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVEhe7w085337; Wed, 31 Dec 2008 07:43:40 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVEhQJ1085321; Wed, 31 Dec 2008 07:43:37 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVEhO1a005883; Wed, 31 Dec 2008 09:43:24 -0500
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVEhOWH005873; Wed, 31 Dec 2008 09:43:24 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 09:43:24 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 08:42:56 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Russ Housley
CC: Eric Rescorla , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: Further MD5 breaks: Creating a rogue CA certificate
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090606080405090908050504"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Russ Housley wrote:
>
>> I'm not sure I understand the issue here, but
>> they don't actually have to be totally randomized. You could use a
>> PRF so they were predictable to the CA.
>
> That works. This works too: the serial number could be composed of
> two parts, where the most significant bits are a counter and the
> least significant bits are randomly generated.

How would Corestreet's miniCRL format fare under this?

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEyMzExNDQyNTZaMCMGCSqGSIb3DQEJBDEWBBTfbxF7sn3oqEN3WXpHFQsd8theZDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgBZT/e02nOU5oLHw8SlL6T03B11F/xNZ0nz2O8tH5cZlJO9MLivLWFMt7kuj
+OfGq/Rbd1s8iuLaOutkrqN86npxL/gDNTA9HhiOUS7uN6rWywF/2tptx4S0l7lJRMDg/BcX
0kefE1Ivxq3RU/taMplV1KFiHkJ7LJUnlyHecbu2AAAAAAAA
--------------ms090606080405090908050504--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBV87fBK065613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 01:07:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBV87fct065610; Wed, 31 Dec 2008 01:07:41 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBV87SWk065597 for ; Wed, 31 Dec 2008 01:07:38 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 936 invoked from network); 31 Dec 2008 08:07:51 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 08:07:51 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 08:07:51 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Date: Wed, 31 Dec 2008 03:07:26 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: Aclq5ghrPG8EOOIcREilhQIvujxQYwAOEaVA
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com>
From: "Santosh Chokhani"
To: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

One would think we want to start using SHA-1 or even SHA256 (assuming
client vendors implement SHA256 ASAP) and ask the CAs emanating from
commercial roots to perform responsible I&A before issuing certificates.

It will also help if the client side certificate policy processing
became more of a norm.

But, all of this is probably expecting too much. My fear is that
expecting any of this is also too much.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Gutmann
Sent: Tuesday, December 30, 2008 8:21 PM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

"Peter Hesse" writes:

>Ceasing the issuance of certificates with MD5 used in the signature
doesn't
>solve the problem of the certificates that have already been issued and
are
>still out there, any number of which may be rogue.
>
>Replacing, or marking as untrusted all root certificates which have any
>current valid (i.e. non-expired, non-revoked) certificates with MD5
used in
>the signature could have tremendous undesirable impact and be an
untenable
>solution.

I hate to be the one to point to the elephant in the room (well OK, I
don't
hate it, it's rather fun actually) but you need to keep this in
perspective:
one in ten AuthentiCode-signed Windows binaries is malware, and
cybercrooks
have no problems at all obtaining certs from commercial CAs using stolen
identities and credentials for pretty much any use they want. The
current MD5
attack is very cool but there's no need to worry about bad guys doing
much
with it because it's much, much easier to get legitimate CA-issued certs
the
normal way, you buy them just like everyone else does (except that you
use
someone else's credit card and identity, obviously).

In other words, if this problem is fixed, would anyone other than
security
geeks even notice? I doubt the crooks will.

Peter.
_______________________________________________
Cfrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/cfrg

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBV1Kxgu050092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:20:59 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBV1Kx1e050089; Tue, 30 Dec 2008 18:20:59 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBV1KkLi050051; Tue, 30 Dec 2008 18:20:58 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C6E079D3C9; Wed, 31 Dec 2008 14:20:45 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ47zQCpU9p7; Wed, 31 Dec 2008 14:20:45 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EF5B69D3C8; Wed, 31 Dec 2008 14:20:44 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 0EEEE1BE4002; Wed, 31 Dec 2008 14:20:40 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LHplH-0006Xw-V6; Wed, 31 Dec 2008 14:20:39 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To: <08bb01c96ac7$1cd5a750$5680f5f0$@com>
Message-Id:
Date: Wed, 31 Dec 2008 14:20:39 +1300
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

"Peter Hesse" writes:

>Ceasing the issuance of certificates with MD5 used in the signature doesn't
>solve the problem of the certificates that have already been issued and are
>still out there, any number of which may be rogue.
>
>Replacing, or marking as untrusted all root certificates which have any
>current valid (i.e. non-expired, non-revoked) certificates with MD5 used in
>the signature could have tremendous undesirable impact and be an untenable
>solution.

I hate to be the one to point to the elephant in the room (well OK, I don't
hate it, it's rather fun actually) but you need to keep this in perspective:
one in ten AuthentiCode-signed Windows binaries is malware, and cybercrooks
have no problems at all obtaining certs from commercial CAs using stolen
identities and credentials for pretty much any use they want. The current MD5
attack is very cool but there's no need to worry about bad guys doing much
with it because it's much, much easier to get legitimate CA-issued certs the
normal way, you buy them just like everyone else does (except that you use
someone else's credit card and identity, obviously).

In other words, if this problem is fixed, would anyone other than security
geeks even notice? I doubt the crooks will.

Peter.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNjtPp045193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:45:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNjtPr045191; Tue, 30 Dec 2008 16:45:55 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNjr9K045178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 16:45:54 -0700 (MST) (envelope-from [email-masked])
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUNjjIx018330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:45:46 -0500 (EST)
Date: Tue, 30 Dec 2008 18:45:45 -0500
From: Jeffrey Hutzelman
To: Santosh Chokhani , Peter Hesse , "RL 'Bob' Morgan" , Paul Hoffman
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--On Tuesday, December 30, 2008 06:28:07 PM -0500 Santosh Chokhani
wrote:

> Since the attack is computing pre-image, I suspect that past MD5
> certificates are safe until the attack was devised.

The attack does _not_ involve computing a preimage; it involves computing a
colliding pair one of which has a prefix which is predictable but not
controllable, followed by a controllable component consisting of some
minimum number of bits followed by at least three aligned message blocks.
What makes existing certificates safe is that there are no known preimage
attacks against MD5, couple with limitations of the technique used to
construct the colliding pair.

However, there is a limit to how "safe" existing certificates are, because
the attack does not require anything that was not known 3-4 years ago. The
only change is that with the latest techniques for computing collisions, it
is possible to do so in a short enough time to be able to predict the
validity and serial number that will be used by the issuer with fairly high
probability.

-- Jeff

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNeokg044868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:40:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNeoUw044867; Tue, 30 Dec 2008 16:40:50 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNebSX044839; Tue, 30 Dec 2008 16:40:48 -0700 (MST) (envelope-from [email-masked])
Received: by fg-out-1718.google.com with SMTP id l26so2736323fgb.26 for ; Tue, 30 Dec 2008 15:40:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=DDpekhM52VkOAoRXt2PZCjhH4t1PiBNvOlzCNzEqzL4=; b=ZZz3YvRMqfdLQsd/8ahiFloECdUPBawdLeuuNZH8Cr46ZHYLNXsoZ+HMY+zLRX6zYI h+P2eWBjHI0CacQWPFxFZXccAWRnZLdIAa2ZIivutA9pgNYpKm9PZOVdbDda45599etK ntwcXzkHyb9uMG1+RTH91bwmHp47itVwiUsgY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=rIO56ncxno48IvUn931cZzc48cPja3c6sVugRkSlz07p+kL31iFVgv0xYSnUpIRGhc 9l8VIIu5uelDeSjEMvZMXmMvlH94d3yEPdueUvJdVnE1X+piIepre66GsXldcD7HYouL S1ChvvQEJXezzzv/SuiCz/3ifmbLVWzeW8SV8=
Received: by 10.86.95.20 with SMTP id s20mr2438156fgb.39.1230680436423; Tue, 30 Dec 2008 15:40:36 -0800 (PST)
Received: by 10.86.93.6 with HTTP; Tue, 30 Dec 2008 15:40:36 -0800 (PST)
Message-ID:
Date: Tue, 30 Dec 2008 18:40:36 -0500
From: "Hugo Krawczyk"
To: "Eric Rescorla"
Subject: Re: Further MD5 breaks: Creating a rogue CA certificate
Cc: "Paul Hoffman" , [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_143378_5086089.1230680436411"
References: <[email-masked]> <[email-masked]> <[email-masked]>
X-Google-Sender-Auth: 51d21de5a352475d
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

------=_Part_143378_5086089.1230680436411
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Paul, Eric and everyone else,

Paul said

>
> If the IETF feels that adding randomization to signatures is
> important, we should define randomized signature functions. We could
> start with NIST Draft SP 800-106
> (<
http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf>).
However,
> I think that doing so is sending the wrong message: we should
> instead be encouraging the use of non-broken hash functions.

and Eric responded

> I certainly agree we should be encouraging the use of non-broken hash
> functions. However, randomizing the SN seems like very cheap backward
> compatible insurance against the fact that that's going to take a long
time.

I believe that the best answer to the above arguments regarding the use of
randomized hashing vs. the "patch" of using random SNs is given by Sotirov
et
al, the cryptanalysts that carried out the remarkable MD5-certificate attack
(see their website). They say:

*We do note however that this use of randomness in the serial number is a
workaround, made possible by lucky choices in the X.509 standard. It is
not a
bad idea in general to add randomness to a hash input when a possible
attacker
is able to choose the input. A much more reliable, since designed,
solution is
to use randomized hashing, see [HK]. Such a solution introduces
randomization
as a "mode of operation" for hash functions, which is a much more
fundamental
approach to the problem than relying on features that happen to be present
in
existing standards for non-security reasons, or for no reason at all.*

In this light, I disagree with Paul's statement:

> I think that doing so is sending the wrong message: we should
> instead be encouraging the use of non-broken hash functions.

The two things are not exclusive. We should do BOTH:
Adopt a randomized hashing technique (as a mode of operation for hash
functions) and continue our quest for better hash functions.

We must aim at the best possible hash function, but we cannot guarantee its
security in the long term. As stated in the above text by Sotirov et al,
randomized hashing is a more fundamental (I would call it "infrastructural")
approach. It strengthens digital signatures with any hash function and for
any
digital signature application, not just certificates.

Let's take the example of HMAC: Its development in mid-90's was motivated to
a
large extent by the weaknesses found in MD5 by Dobbertin and others.
If we took the approach of "let's use a better hash function" we should have
adopted the key-append method
MAC(K,X) = SHA1(X||K)
which used SHA1 for which there was ample belief that it was a very good
collision resistant hash function. However, had we done that, we would now
have a broken MAC since the above design breaks with collisions on the
underlying hash function.

I believe that the responsible course of action for the IETF and
particularly
SAAG is to adopt the standardization process started by NIST with
http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf
and create a deployment path that could accommodate a randomized hashing
approach as a mode of operation. This includes the consideration of
randomized
hashing in protocol changes and new protocol design that support algorithm
agility.

No one in the world will think that by doing that we should keep using MD5,
or not pay attention to NIST's hash competition, or should stop from moving
to
SHA2.

The just-published attack indicates that it is time that we take seriously
our
digital signatures, and randomized hashing is the best long-term insurance
we know against future collision vulnerabilities.

You can find more details on the specific randomized hashing approach behind
NIST's document in http://www.ee.technion.ac.il/~hugo/rhash/
In particular, some of the documents in that site provide some guidance
regarding implementation and deployment issues (it also includes a
now-expired
internet draft).

Hugo

------=_Part_143378_5086089.1230680436411
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Paul, Eric and everyone else,

Paul said

>
> If the IETF feels that adding randomization to signatures is
> important, we should define randomized signature functions. We could
> start with NIST Draft SP 800-106

> (<http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf>). However,
> I think that doing so is sending the wrong message: we should

> instead be encouraging the use of non-broken hash functions.

and Eric responded

>  I certainly agree we should be encouraging the use of non-broken hash
>  functions. However, randomizing the SN seems like very cheap backward

>  compatible insurance against the fact that that's going to take a long time.

I believe that the best answer to the above arguments regarding the use of
randomized hashing vs. the "patch" of using random SNs is given by Sotirov et

al, the cryptanalysts that carried out the remarkable MD5-certificate attack
(see their website). They say:

We do note however that this use of randomness in the serial number is a
workaround, made possible by lucky choices in the X.509 standard. It is not a

bad idea in general to add randomness to a hash input when a possible attacker
is able to choose the input. A much more reliable, since designed, solution is
to use randomized hashing, see [HK]. Such a solution introduces randomization

as a "mode of operation" for hash functions, which is a much more fundamental
approach to the problem than relying on features that happen to be present in
existing standards for non-security reasons, or for no reason at all.

In this light, I disagree with Paul's statement:

> I think that doing so is sending the wrong message: we should
> instead be encouraging the use of non-broken hash functions.

The two things are not exclusive. We should do BOTH:

Adopt a randomized hashing technique (as a mode of operation for hash
functions) and continue our quest for better hash functions.

We must aim at the best possible hash function, but we cannot guarantee its
security in the long term. As stated in the above text by Sotirov et al,

randomized hashing is a more fundamental (I would call it "infrastructural")
approach. It strengthens digital signatures with any hash function and for any
digital signature application, not just certificates.

Let's take the example of HMAC: Its development in mid-90's was motivated to a
large extent by the weaknesses found in MD5 by Dobbertin and others.
If we took the approach of "let's use a better hash function" we should have

adopted the key-append method
MAC(K,X) = SHA1(X||K)
which used SHA1 for which there was ample belief that it was a very good
collision resistant hash function.  However, had we done that, we would now
have a broken MAC since the above design breaks with collisions on the

underlying hash function.

I believe that the responsible course of action for the IETF and particularly
SAAG is to adopt the standardization process started by NIST with
http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf

and create a deployment path that could accommodate a randomized hashing
approach as a mode of operation. This includes the consideration of randomized
hashing in protocol changes and new protocol design that support algorithm

agility.

No one in the world will think that by doing that we should keep using MD5,
or not pay attention to NIST's hash competition, or should stop from moving to
SHA2.

The just-published attack indicates that it is time that we take seriously our

digital signatures, and randomized hashing is the best long-term insurance
we know against future collision vulnerabilities.

You can find more details on the specific randomized hashing approach behind
NIST's document in http://www.ee.technion.ac.il/~hugo/rhash/

In particular, some of the documents in that site provide some guidance
regarding implementation and deployment issues (it also includes a now-expired
internet draft).

Hugo

------=_Part_143378_5086089.1230680436411--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNUGpd044381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:30:17 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNUGKr044380; Tue, 30 Dec 2008 16:30:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUNUEbL044362 for ; Tue, 30 Dec 2008 16:30:15 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 29881 invoked from network); 30 Dec 2008 23:30:38 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:30:38 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:30:38 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate
Date: Tue, 30 Dec 2008 18:30:13 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate
Thread-Index: AclqylLTk2EWxsuuQ1C7rI9Jvd/JmAADAnAQ
References: <[email-masked]><[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "Yoav Nir" , "RL 'Bob' Morgan"
Cc: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Let us leave the trust anchors alone. Your challenge of protecting
trust anchors does not change even if you use SHA 512 or next generation
hash function yet to be determined.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yoav Nir
Sent: Tuesday, December 30, 2008 5:02 PM
To: RL 'Bob' Morgan
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate

>> Regardless of that, the authors of the MD5 paper are correct: trust =20
>> anchors signed with MD5 are highly questionable as of today (well, =20
>> actually, since they published their last paper). Hopefully, the =20
>> maintainers of the popular trust anchor repositories (Microsoft, =20
>> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and =20
>> MD2!) as soon as possible.
>
> This is a different claim than "CAs should stop issuing certs with =20
> MD5 signatures", which is what I as an amateur take away from a =20
> quick scan of the material. Obviously MD5 is suspect in various =20
> ways, but does this new work lead to the conclusion that MD5-signed =20
> roots are untrustworthy today?
> Replacing a root is a much bigger deal then changing signing =20
> practices.
>
> - RL "Bob"

CAs should have stopped issuing certs with MD5 signatures 4 years ago, =20
when the first practical attacks on MD5 were published.

Now it would be more correct to say that "relying parties should treat =20
as invalid any certificate chain that contains an MD5 (or MD2, MD4) =20
signature"

Since in the HTTPS context the relying parties are the browsers, it =20
falls to the vendors (if Microsoft leads, everyone will follow) to, as =20
Paul said, yank the trust anchors.

It should be noted, though, that yanking the trust anchors is not =20
enough. You really should change the relying party to not recognize =20
this algorithm. Otherwise, it's perfectly valid for a CA whose =20
certificate is signed with SHA1 to sign an intermediate CA certificate =20
with MD5 (although they usually don't do that, I hope)

Email secured by Check Point
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNSAXN044294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:28:10 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNSAvI044292; Tue, 30 Dec 2008 16:28:10 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUNS8eB044271 for ; Tue, 30 Dec 2008 16:28:08 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 29840 invoked from network); 30 Dec 2008 23:28:32 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:28:32 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:28:32 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate
Date: Tue, 30 Dec 2008 18:28:07 -0500
Message-ID:
In-Reply-To: <08bb01c96ac7$1cd5a750$5680f5f0$@com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate
Thread-Index: AclqxboXk3PuIMY0SLuDtNKXm7F2qQAAEKtAAAQJILA=
References: <[email-masked]> <[email-masked]> <08bb01c96ac7$1cd5a750$5680f5f0$@com>
From: "Santosh Chokhani"
To: "Peter Hesse" , "RL 'Bob' Morgan" , "Paul Hoffman"
Cc: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Peter,

Roots need not be replaced since they need protected migration and
storage.

Since the attack is computing pre-image, I suspect that past MD5
certificates are safe until the attack was devised.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Hesse
Sent: Tuesday, December 30, 2008 4:40 PM
To: 'RL 'Bob' Morgan'; 'Paul Hoffman'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate

Ceasing the issuance of certificates with MD5 used in the signature
doesn't
solve the problem of the certificates that have already been issued and
are
still out there, any number of which may be rogue.

Replacing, or marking as untrusted all root certificates which have any
current valid (i.e. non-expired, non-revoked) certificates with MD5 used
in
the signature could have tremendous undesirable impact and be an
untenable
solution.

The right tool for the job is a client-side solution to fail validation
of
any signature which uses MD5, especially certificate signatures. I will
not
hold my breath for such a solution.

--Peter=20

----------------------------------------------------------------
Peter Hesse [email-masked]
http://securitymusings.com http://geminisecurity.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of RL 'Bob' Morgan
Sent: Tuesday, December 30, 2008 4:18 PM
To: Paul Hoffman
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate

> Regardless of that, the authors of the MD5 paper are correct: trust=20
> anchors signed with MD5 are highly questionable as of today (well,=20
> actually, since they published their last paper). Hopefully, the=20
> maintainers of the popular trust anchor repositories (Microsoft,=20
> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and=20
> MD2!) as soon as possible.

This is a different claim than "CAs should stop issuing certs with MD5=20
signatures", which is what I as an amateur take away from a quick scan
of=20
the material. Obviously MD5 is suspect in various ways, but does this
new=20
work lead to the conclusion that MD5-signed roots are untrustworthy
today?
Replacing a root is a much bigger deal then changing signing practices.

- RL "Bob"

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNQ7DX044211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:26:07 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNQ7Tp044209; Tue, 30 Dec 2008 16:26:07 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUNQ5kV044188 for ; Tue, 30 Dec 2008 16:26:05 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 29815 invoked from network); 30 Dec 2008 23:26:29 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:26:29 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:26:29 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate
Date: Tue, 30 Dec 2008 18:26:04 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate
Thread-Index: AclqxZr3n+guWOOLTkmzRrRAnrk5JgAEETnQ
References: <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "RL 'Bob' Morgan" , "Paul Hoffman"
Cc: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

As mentioned, self-signed roots have their own problems and hash is not
one of them. They need other means to protect since signatures on them
are useless.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of RL 'Bob' Morgan
Sent: Tuesday, December 30, 2008 4:18 PM
To: Paul Hoffman
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate

> Regardless of that, the authors of the MD5 paper are correct: trust=20
> anchors signed with MD5 are highly questionable as of today (well,=20
> actually, since they published their last paper). Hopefully, the=20
> maintainers of the popular trust anchor repositories (Microsoft,=20
> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and=20
> MD2!) as soon as possible.

This is a different claim than "CAs should stop issuing certs with MD5=20
signatures", which is what I as an amateur take away from a quick scan
of=20
the material. Obviously MD5 is suspect in various ways, but does this
new=20
work lead to the conclusion that MD5-signed roots are untrustworthy
today?
Replacing a root is a much bigger deal then changing signing practices.

- RL "Bob"

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNNTwV044009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:23:29 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNNT9h044005; Tue, 30 Dec 2008 16:23:29 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUNNG8c043975 for ; Tue, 30 Dec 2008 16:23:27 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 29788 invoked from network); 30 Dec 2008 23:23:40 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:23:40 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:23:40 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Date: Tue, 30 Dec 2008 18:23:15 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclqwLMO5Ztz1GDZSjWorp7026VgfQAFJdBA
References: <[email-masked]><[email-masked]>
From: "Santosh Chokhani"
To: "Paul Hoffman" , , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul,

I disagree in the matter of trust anchors, assuming you mean self-signed
ones.

Signatures on Trust anchors are inherently useless from security
viewpoint. Thus, they could be signed using even MD4.

Their security relies on protecting them from unauthorized modification.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Hoffman
Sent: Tuesday, December 30, 2008 3:53 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote:
>This is a practical application of an approach that I remember being
brought up during discussions about MD5 at a saag meeting some time ago.
I also recall someone mentioning at the time that many/most CA's were
already issuing certificates with random rather than sequential serial
numbers, which would have thwarted this particular attack.

Your recollection may be off. I believe I was the person who brought up
the serial number hack at the mic, and I'm pretty sure I said "some",
not "many" (and certainly not "most"!). When I looked at a handful of
popular CAs earlier this week, I only found a few who are using
randomization in their serial numbers.

Regardless of that, the authors of the MD5 paper are correct: trust
anchors signed with MD5 are highly questionable as of today (well,
actually, since they published their last paper). Hopefully, the
maintainers of the popular trust anchor repositories (Microsoft,
Mozilla, etc.) will yank out the trust anchors signed with MD5 (and
MD2!) as soon as possible.

At 3:10 PM -0500 12/30/08, Russ Housley wrote:
>RFC 5280 does not include this advice. It is sound advice that was
discussed in PKIX and other venues. Perhaps a BCP is in order.

Man, that is really stretching the definition of "best".

For one, it is only needed in signatures that use known-attackable hash
functions. A "best practice" in that case is to use a better hash
function in the signature. Also, it relies on the ability of the
software using the random number to be sure that the result is a
positive integer in ASN.1, which seems overly optimistic.

If the IETF feels that adding randomization to signatures is important,
we should define randomized signature functions. We could start with
NIST Draft SP 800-106
(). However, I think that doing so is sending the wrong
message: we should instead be encouraging the use of non-broken hash
functions.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Cfrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/cfrg

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNF3jE043682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:15:03 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNF3Ok043680; Tue, 30 Dec 2008 16:15:03 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNF1RH043670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 16:15:02 -0700 (MST) (envelope-from [email-masked])
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUNEtxp017907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:14:56 -0500 (EST)
Date: Tue, 30 Dec 2008 18:14:55 -0500
From: Jeffrey Hutzelman
To: Nicolas Williams
cc: Eric Rescorla , Paul Hoffman , [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--On Tuesday, December 30, 2008 04:36:12 PM -0600 Nicolas Williams
wrote:

> Applying a principle of redundancy in RTI algorithms to symmetric key
> protocols is fairly simple. Applying such a principle to PKI seems
> rather more difficult -- it's not just hash algorithms, but pk
> algorithms too. Your example was to require not just the implementation
> of multiple hash (but not pk) algorithms, but to require the *use* of
> those. That makes sense to me, but it's not quite the same principle
> being applied to PKI as to SSH.

Correct. I'm suggesting that in the case of PKI, merely having two RTI
algorithms wouldn't be sufficient; at least for long-term certificates you
need to actually sign using two algorithms in order to get the
interoperability benefit. Validating using both isn't necessary, though it
does have a benefit, in that no code or configuration changes are required
to continue to be safe as long as at least one is good enough.

IMHO, one of the biggest problems in the current PKI standards is that
there is no ability to future-proof certificates by generating signatures
with multiple algorithms. The result is that you can't start signing with
a new algorithm until everyone understands it, and you can't stop accepting
an old algorithm without either reissuing lots of certificates with a new
one or waiting for them to expire. This means movement is very slow and we
are unable to abandon a broken algorithm in a hurry. The former is poor;
the latter is a disaster waiting to happen.

-- Jeff

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUN7SiP043207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:07:28 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUN7SjU043206; Tue, 30 Dec 2008 16:07:28 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUN7GLB043196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Dec 2008 16:07:27 -0700 (MST) (envelope-from [email-masked])
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBUN7AO5030377 for ; Tue, 30 Dec 2008 18:07:10 -0500
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id mBUN6xjD020656 for ; Tue, 30 Dec 2008 18:06:59 -0500
Message-ID: <[email-masked]>
Date: Tue, 30 Dec 2008 18:06:58 -0500
From: "David A. Cooper"
User-Agent: Thunderbird 2.0.0.18 (X11/20081120)
MIME-Version: 1.0
To: pkix
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information:
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I have heard that using non-sequential serial numbers can cause problems
for OCSP responders that pre-produce responses as well.

There is an alternative, however, for CAs that do not wish to use
randomized serial numbers. Randomness can be included in the validity
dates.

The described attack relied on the ability to guess both the serial
number and validity dates of the certificate that would be issued. The
authors were able to find a CA that always used validity dates of
notBefore = T (where T was the time of issuance) and notAfter = T + 1
year, where T was always 6 seconds after the time that the certificate
request was submitted.

Suppose, however, that the CA selected two random numbers R1 and R2 and
then used notBefore = T + R1 seconds and notAfter = T + R2 seconds +
(normal validity period [e.g., 1 year]). If R1 and R2 were each chosen
from the range [-15 ... 16] then the attacker would only have a 1 in
1024 chance of guessing the validity dates. If R1 and R2 were each
chosen from the range [-511 ... 512] then the attacker would only have a
1 in 1,048,576 chance of guessing the validity dates. Since notBefore
and notAfter would be modified by at most a few minutes, the
randomization should not create any practical problems for users.

Of course, randomizing the serial number is a more effective means of
counteracting the attack since the serial number could be made a random
159-bit number and since the serial number appears earlier in the
certificate, but incorporating some randomness into the validity dates
would be a second best choice if the serial number cannot be randomized.

Dave

Timothy J. Miller wrote:
> Eric Rescorla wrote:
>> At Tue, 30 Dec 2008 12:53:06 -0800,
>> Paul Hoffman wrote:
>>> Your recollection may be off. I believe I was the person who brought
>>> up the serial number hack at the mic, and I'm pretty sure I said
>>> "some", not "many" (and certainly not "most"!). When I looked at a
>>> handful of popular CAs earlier this week, I only found a few who are
>>> using randomization in their serial numbers.
>> I don't know whether many or most do it. IMO everyone should.
>
> Randomizing serial numbers has implications for OCSP operations,
> particularly those that use presigned responses in order to optimize
> performance.
>
> Why presign? Because for a large network with varying levels of
> support, it may be easier to move around sets of pre-produced
> responses to distributed keyless OCSP responders than to guarantee
> connectivity to a keyed OCSP service.
>
> Why presign batches rather than individual responses? Because for a
> large PKI the response pre-production time can exceed the CRL update
> frequency.
>
> -- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUN0k3L042872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:00:46 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUN0kvd042870; Tue, 30 Dec 2008 16:00:46 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUN0Z99042846; Tue, 30 Dec 2008 16:00:46 -0700 (MST) (envelope-from [email-masked])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBUN0ZCC027191; Tue, 30 Dec 2008 23:00:35 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBUN0ZOK044664; Tue, 30 Dec 2008 16:00:35 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBUMb2LL003035; Tue, 30 Dec 2008 16:37:02 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBUMaCUE003034; Tue, 30 Dec 2008 16:36:12 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [email-masked] using -f
Date: Tue, 30 Dec 2008 16:36:12 -0600
From: Nicolas Williams
To: Jeffrey Hutzelman
Cc: Eric Rescorla , Paul Hoffman , [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.7i
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Tue, Dec 30, 2008 at 05:01:12PM -0500, Jeffrey Hutzelman wrote:
> Incidentally, the recently reported problems with CBC mode ciphers in SSH
> have gotten me to thinking that in some situations, a single REQUIRED
> algorithm isn't enough, because if something goes wrong and you have to
> abandon that algorithm in a hurry, operators may be in a position of having
> to choose between seriously compromising either security or
> interoperability.

+1

But note that in the case of the SSH CBC mode ciphers the vulnerable
ciphers had only the cipher mode in common. The SSH vulnerability, in
any case, doesn't stem from the use of CBC, but is more general, and
well could have been worse, but let's ignore that for this argument.

So in the SSH case one would have liked to have seen two or more
REQUIRED to implement ciphers with very distinct properties. Say
3DES in CBC mode, AES in counter mode, and arcfour.

Applying a principle of redundancy in RTI algorithms to symmetric key
protocols is fairly simple. Applying such a principle to PKI seems
rather more difficult -- it's not just hash algorithms, but pk
algorithms too. Your example was to require not just the implementation
of multiple hash (but not pk) algorithms, but to require the *use* of
those. That makes sense to me, but it's not quite the same principle
being applied to PKI as to SSH.

Nico
--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMcbFf041941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:38:37 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMcaGr041938; Tue, 30 Dec 2008 15:38:37 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMcaVV041923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:38:36 -0700 (MST) (envelope-from [email-masked])
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 0E36550822; Tue, 30 Dec 2008 14:54:54 -0800 (PST)
Date: Tue, 30 Dec 2008 14:54:53 -0800
From: Eric Rescorla
To: "Timothy J. Miller"
Cc: Eric Rescorla , Paul Hoffman , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Here's Tim Callan from VEriSign posting about this:

https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php

-Ekr
y

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMVYbx041608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:31:34 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMVYcL041606; Tue, 30 Dec 2008 15:31:34 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMVLtP041578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:31:32 -0700 (MST) (envelope-from [email-masked])
Received: from newdasher.Dartmouth.EDU (newdasher.dartmouth.edu [129.170.208.30]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id mBULqtr9007948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 17:30:44 -0500
X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system.
Received: from c-65-96-146-181.hsd1.nh.comcast.net [65.96.146.181] by newdasher.Dartmouth.EDU (Mac) via SMTP for id <138927721>; 30 Dec 2008 17:30:43 -0500
Message-ID: <[email-masked]>
Date: Tue, 30 Dec 2008 17:30:14 -0500
From: Scott Rea
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Russ Housley
CC: "RL 'Bob' Morgan" , Paul Hoffman , [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU
X-MailScanner-SpamCheck: spam, SpamAssassin on mailhub2 (score=1.651, required 1, BAYES_00 -2.60, BLITZ_DISCLAIMER 0.05, HELO_DYNAMIC_IPADDR 4.20)
X-MailScanner-SpamScore: s
X-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Russ Housley wrote:
>
>
>>> Regardless of that, the authors of the MD5 paper are correct: trust
>>> anchors signed with MD5 are highly questionable as of today (well,
>>> actually, since they published their last paper). Hopefully, the
>>> maintainers of the popular trust anchor repositories (Microsoft,
>>> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and
>>> MD2!) as soon as possible.
>>
>> This is a different claim than "CAs should stop issuing certs with
>> MD5 signatures", which is what I as an amateur take away from a quick
>> scan of the material. Obviously MD5 is suspect in various ways, but
>> does this new work lead to the conclusion that MD5-signed roots are
>> untrustworthy today?
>
> We recommended a migration (walk, don't run) away from MD2, MD4, and
> SHA-1 toward SHA-256 a few years ago. MD2 and MD4 generate 128 bit
> hash values; even without the attacks, these are getting to be too
> small. SHA-1 has been shown to be weaker than its design goal, and
> the 160 bit hash value will be getting too short in a couple of
> years. We recommended SHA-256 while fully recognizing that NIST was
> starting a hash competition, and that we might recommend the winner of
> that competition as the successor to SHA-256.
>
> I still strongly encourage the migration to SHA-256.
>
> The use of the random bits in the serial number are insurance against
> similar problems being found in other hash functions. This insurance
> will hopefully provide time to migrate to another hash function when
> cryptanalysis begins to show flaws in any future hash function.
>
> Russ

But one of the things that has kept the brakes on migration has been
support in clients for SHA256 - the largest vendor of client machines
only just recently added SHA256 to its XP platform (if you upgrade to
SP3). I keep running into folks using OpenSSL as their crypto base and
they haven't updated to a distribution that supports SHA256. I think it
will take a little more time before it becomes the default...

--
Scott Rea

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMNsTb040975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:23:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMNsm7040974; Tue, 30 Dec 2008 15:23:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUMNqIJ040944 for ; Tue, 30 Dec 2008 15:23:52 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 24294 invoked by uid 0); 30 Dec 2008 22:23:45 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:23:45 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Dec 2008 17:23:33 -0500
To: Eric Rescorla
From: Russ Housley
Subject: Re: Further MD5 breaks: Creating a rogue CA certificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

>I'm not sure I understand the issue here, but
>they don't actually have to be totally randomized. You could use a
>PRF so they were predictable to the CA.

That works. This works too: the serial number could be composed of
two parts, where the most significant bits are a counter and the
least significant bits are randomly generated.

Russ

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMNs7f040972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:23:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMNsLw040969; Tue, 30 Dec 2008 15:23:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.246]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMNgDm040924; Tue, 30 Dec 2008 15:23:53 -0700 (MST) (envelope-from [email-masked])
Received: by rv-out-0708.google.com with SMTP id c5so5433808rvf.34 for ; Tue, 30 Dec 2008 14:23:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SOjf1T9xI3MBJb+v+mg2/Dsw2wPmsmYSixQ9iXiIRcA=; b=jLU/hS5jNIbna5Zku6U+axs1KV2KLYrQTa+hHCR/6kqe207G+tXYDsVPGgTJk0qupA RJNQu5TWWaiQBDzj6O/tCx4phcCEZunboOs+VpniRcdvoADq3XwUZ1mzr83/ud5RY47H 8qdO/4Hzhx0900vj2XpDMmQJIaimvjR/nKQhg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=fNUP7Tab+VzvZPlIZjRGwRfpijhSl5e12WjdlWGoMMTJAQLgGCUXaBh6fPtA/Uex4x SNJMbQy/susUqr3OwRpb03aw46n6l9v8rUN4Gu8YA/jVRFYUFah7cKKcTeg4ApodNWJq EylztJzNVq1Niy3z4I7ag/Xk1/BlZfI+34MHY=
Received: by 10.140.226.14 with SMTP id y14mr7464473rvg.59.1230675822107; Tue, 30 Dec 2008 14:23:42 -0800 (PST)
Received: by 10.141.169.13 with HTTP; Tue, 30 Dec 2008 14:23:42 -0800 (PST)
Message-ID: <[email-masked]>
Date: Tue, 30 Dec 2008 14:23:42 -0800
From: "Blake Ramsdell"
To: "Timothy J. Miller"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
Cc: "Eric Rescorla" , "Paul Hoffman" , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
In-Reply-To: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Tue, Dec 30, 2008 at 2:05 PM, Timothy J. Miller wrote:
> Randomizing serial numbers has implications for OCSP operations,
> particularly those that use presigned responses in order to optimize
> performance.

It seems that the disruption caused by modifying serial number
generation for existing CAs is pretty high. Would an easier solution
be to either a) make the validity period vary slightly (in the
documented attack, the notBefore was always a fixed interval from the
submission time, and making this vary in a period of just a few
minutes would have thwarted it, if I'm understanding correctly), or b)
the CA sticks some random junk in the subject DN (not an MPEG of a
cat, but maybe OU=sf9fj3 [some base64 PRNG data]).

Blake
--
Blake Ramsdell | http://www.blakeramsdell.com

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMIheK040690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:18:43 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMIhrR040686; Tue, 30 Dec 2008 15:18:43 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMIg9v040670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:18:42 -0700 (MST) (envelope-from [email-masked])
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 48BD350822; Tue, 30 Dec 2008 14:35:00 -0800 (PST)
Date: Tue, 30 Dec 2008 14:34:59 -0800
From: Eric Rescorla
To: "Timothy J. Miller"
Cc: Eric Rescorla , Paul Hoffman , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At Tue, 30 Dec 2008 16:05:56 -0600,
Timothy J. Miller wrote:
>
> [1 ]
> Eric Rescorla wrote:
> > At Tue, 30 Dec 2008 12:53:06 -0800,
> > Paul Hoffman wrote:
>
> >> Your recollection may be off. I believe I was the person who brought
> >> up the serial number hack at the mic, and I'm pretty sure I said
> >> "some", not "many" (and certainly not "most"!). When I looked at a
> >> handful of popular CAs earlier this week, I only found a few who are
> >> using randomization in their serial numbers.
>
> > I don't know whether many or most do it. IMO everyone should.
>
> Randomizing serial numbers has implications for OCSP operations,
> particularly those that use presigned responses in order to optimize
> performance.
>
> Why presign? Because for a large network with varying levels of
> support, it may be easier to move around sets of pre-produced responses
> to distributed keyless OCSP responders than to guarantee connectivity to
> a keyed OCSP service.
>
> Why presign batches rather than individual responses? Because for a
> large PKI the response pre-production time can exceed the CRL update
> frequency.

I'm not sure I understand the issue here, but
they don't actually have to be totally randomized. You could use a
PRF so they were predictable to the CA.

-Ekr

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMH83B040617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:17:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMH8pE040614; Tue, 30 Dec 2008 15:17:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUMH7XD040595 for ; Tue, 30 Dec 2008 15:17:07 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 20400 invoked by uid 0); 30 Dec 2008 22:17:00 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:17:00 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Dec 2008 17:12:02 -0500
To: "RL 'Bob' Morgan" , Paul Hoffman
From: Russ Housley
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

>>Regardless of that, the authors of the MD5 paper are correct: trust
>>anchors signed with MD5 are highly questionable as of today (well,
>>actually, since they published their last paper). Hopefully, the
>>maintainers of the popular trust anchor repositories (Microsoft,
>>Mozilla, etc.) will yank out the trust anchors signed with MD5 (and
>>MD2!) as soon as possible.
>
>This is a different claim than "CAs should stop issuing certs with
>MD5 signatures", which is what I as an amateur take away from a
>quick scan of the material. Obviously MD5 is suspect in various
>ways, but does this new work lead to the conclusion that MD5-signed
>roots are untrustworthy today?

We recommended a migration (walk, don't run) away from MD2, MD4, and
SHA-1 toward SHA-256 a few years ago. MD2 and MD4 generate 128 bit
hash values; even without the attacks, these are getting to be too
small. SHA-1 has been shown to be weaker than its design goal, and
the 160 bit hash value will be getting too short in a couple of
years. We recommended SHA-256 while fully recognizing that NIST was
starting a hash competition, and that we might recommend the winner
of that competition as the successor to SHA-256.

I still strongly encourage the migration to SHA-256.

The use of the random bits in the serial number are insurance against
similar problems being found in other hash functions. This insurance
will hopefully provide time to migrate to another hash function when
cryptanalysis begins to show flaws in any future hash function.

Russ

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM6bm0039982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:06:37 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM6bFA039981; Tue, 30 Dec 2008 15:06:37 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM6P1i039959; Tue, 30 Dec 2008 15:06:36 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBUM6OPb025827; Tue, 30 Dec 2008 17:06:25 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBUM6Ocb025814; Tue, 30 Dec 2008 17:06:24 -0500
Received: from [129.83.200.2] (129.83.200.2) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 30 Dec 2008 17:06:24 -0500
Message-ID: <[email-masked]>
Date: Tue, 30 Dec 2008 16:05:56 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Eric Rescorla
CC: Paul Hoffman , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000706050700070408070900"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Eric Rescorla wrote:
> At Tue, 30 Dec 2008 12:53:06 -0800,
> Paul Hoffman wrote:

>> Your recollection may be off. I believe I was the person who brought
>> up the serial number hack at the mic, and I'm pretty sure I said
>> "some", not "many" (and certainly not "most"!). When I looked at a
>> handful of popular CAs earlier this week, I only found a few who are
>> using randomization in their serial numbers.

> I don't know whether many or most do it. IMO everyone should.

Randomizing serial numbers has implications for OCSP operations,
particularly those that use presigned responses in order to optimize
performance.

Why presign? Because for a large network with varying levels of
support, it may be easier to move around sets of pre-produced responses
to distributed keyless OCSP responders than to guarantee connectivity to
a keyed OCSP service.

Why presign batches rather than individual responses? Because for a
large PKI the response pre-production time can exceed the CRL update
frequency.

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEyMzAyMjA1NTZaMCMGCSqGSIb3DQEJBDEWBBQ4RbejFRP0hZy6Vjhh795xqhnGfDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgELzHlPR7X3MOFLP5ZcY1mbMXJyVuu8D6m/7NK0eZrsmu7YMbLzv7t5txCiQ
6CHlVuWg0WcLwT24dUazLur+cNII/+p5MiS42K0qScSEoWc7uJDgKtmol40n1brGU7mVvLVm
oNAh3ZUvQV/gAJ3VbnN61DL/Eld+TlsdEjGJ8SirAAAAAAAA
--------------ms000706050700070408070900--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM2X1N039872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:02:33 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM2WJQ039871; Tue, 30 Dec 2008 15:02:32 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM2UYN039852; Tue, 30 Dec 2008 15:02:31 -0700 (MST) (envelope-from [email-masked])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E614A29C002; Wed, 31 Dec 2008 00:02:29 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7F09C29C001; Wed, 31 Dec 2008 00:02:08 +0200 (IST)
X-CheckPoint: {495A98AD-10000-88241DC2-7B6}
Received: from [172.31.21.158] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBUM27fE029359; Wed, 31 Dec 2008 00:02:08 +0200 (IST)
Cc: Paul Hoffman , [email-masked], [email-masked], [email-masked], [email-masked]
Message-Id: <[email-masked]>
From: Yoav Nir
To: "RL 'Bob' Morgan"
In-Reply-To:
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
Date: Wed, 31 Dec 2008 00:02:07 +0200
References: <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

>> Regardless of that, the authors of the MD5 paper are correct: trust
>> anchors signed with MD5 are highly questionable as of today (well,
>> actually, since they published their last paper). Hopefully, the
>> maintainers of the popular trust anchor repositories (Microsoft,
>> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and
>> MD2!) as soon as possible.
>
> This is a different claim than "CAs should stop issuing certs with
> MD5 signatures", which is what I as an amateur take away from a
> quick scan of the material. Obviously MD5 is suspect in various
> ways, but does this new work lead to the conclusion that MD5-signed
> roots are untrustworthy today?
> Replacing a root is a much bigger deal then changing signing
> practices.
>
> - RL "Bob"

CAs should have stopped issuing certs with MD5 signatures 4 years ago,
when the first practical attacks on MD5 were published.

Now it would be more correct to say that "relying parties should treat
as invalid any certificate chain that contains an MD5 (or MD2, MD4)
signature"

Since in the HTTPS context the relying parties are the browsers, it
falls to the vendors (if Microsoft leads, everyone will follow) to, as
Paul said, yank the trust anchors.

It should be noted, though, that yanking the trust anchors is not
enough. You really should change the relying party to not recognize
this algorithm. Otherwise, it's perfectly valid for a CA whose
certificate is signed with SHA1 to sign an intermediate CA certificate
with MD5 (although they usually don't do that, I hope)

Email secured by Check Point

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM2L0u039828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:02:21 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM2L1x039826; Tue, 30 Dec 2008 15:02:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUM2J2p039808 for ; Tue, 30 Dec 2008 15:02:20 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 12655 invoked by uid 0); 30 Dec 2008 22:02:12 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:02:12 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Dec 2008 16:33:19 -0500
To: Paul Hoffman
From: Russ Housley
Subject: Re: Further MD5 breaks: Creating a rogue CA certificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul:

>If the IETF feels that adding randomization to signatures is
>important, we should define randomized signature functions. We could
>start with NIST Draft SP 800-106
>().
>However, I think that doing so is sending the wrong message: we
>should instead be encouraging the use of non-broken hash functions.

This is a very different thing than a BCP that the recommends that
the certificate serial number include some random bits.

Russ

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM1XIL039746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:01:33 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM1Xvo039744; Tue, 30 Dec 2008 15:01:33 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM1Lqj039727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 15:01:32 -0700 (MST) (envelope-from [email-masked])
Received: from atlantis-home.pc.cs.cmu.edu (173-101-98-177.pools.spcsdns.net [173.101.98.177]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUM1Cht017220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 17:01:14 -0500 (EST)
Date: Tue, 30 Dec 2008 17:01:12 -0500
From: Jeffrey Hutzelman
To: Eric Rescorla , Paul Hoffman
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--On Tuesday, December 30, 2008 01:39:34 PM -0800 Eric Rescorla
wrote:

> At Tue, 30 Dec 2008 12:53:06 -0800,
> Paul Hoffman wrote:
>>
>> At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote:
>> > This is a practical application of an approach that I remember being
>> > brought up during discussions about MD5 at a saag meeting some time
>> > ago. I also recall someone mentioning at the time that many/most CA's
>> > were already issuing certificates with random rather than sequential
>> > serial numbers, which would have thwarted this particular attack.
>>
>> Your recollection may be off. I believe I was the person who brought
>> up the serial number hack at the mic, and I'm pretty sure I said
>> "some", not "many" (and certainly not "most"!). When I looked at a
>> handful of popular CAs earlier this week, I only found a few who are
>> using randomization in their serial numbers.
>
> So it's in my deck from SAAG at IETF 62.
>
> http://www.ietf.org/proceedings/05mar/slides/saag-3.pdf
>
> I don't know whether many or most do it. IMO everyone should.

I just checked my records, and shortly after that IETF, our internal CA
started issuing certificates with SHA-1 signatures and randomized serial
numbers, as a direct result of that discussion.

>
>> > RFC 5280 does not include this advice. It is sound advice that was
>> > discussed in PKIX and other venues. Perhaps a BCP is in order.
>>
>> Man, that is really stretching the definition of "best".
>>
>> For one, it is only needed in signatures that use known-attackable
>> hash functions. A "best practice" in that case is to use a better
>> hash function in the signature. Also, it relies on the ability of
>> the software using the random number to be sure that the result is a
>> positive integer in ASN.1, which seems overly optimistic.

On the contrary, IMHO best practice is to take every reasonable measure to
reduce the likelyhood of an attack. In my book, that means both using a
better hash function _and_ using randomized serial numbers, since the
latter clearly helps when the hash is broken, and hash functions may become
broken over time, and before you realize it.

>> If the IETF feels that adding randomization to signatures is
>> important, we should define randomized signature functions.

I think that's a very good idea. However...

> I certainly agree we should be encouraging the use of non-broken hash
> functions. However, randomizing the SN seems like very cheap backward
> compatible insurance against the fact that that's going to take a long
> time.

"what he said".

Incidentally, the recently reported problems with CBC mode ciphers in SSH
have gotten me to thinking that in some situations, a single REQUIRED
algorithm isn't enough, because if something goes wrong and you have to
abandon that algorithm in a hurry, operators may be in a position of having
to choose between seriously compromising either security or
interoperability.

In the case of usages like certificates where no live negotiation is
possible and implementations may have to interoperate over a long period of
time, I believe additional care is necessary. For example, I think it
would be a good idea to define a composite signature function which uses
more than one hash computed independently. This would likely make some
attacks harder, but more importantly, it means that as long as at least one
of the underlying hashes is strong enough, the signature is still usable.

-- Jeff

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULdmOx038675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:39:48 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBULdmIX038674; Tue, 30 Dec 2008 14:39:48 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from prospect.joyent.us (prospect.joyent.us [8.12.36.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULdaRA038639; Tue, 30 Dec 2008 14:39:46 -0700 (MST) (envelope-from [email-masked])
Received: from PeterVistaSP1 (static-68-163-72-26.res.east.verizon.net [68.163.72.26]) by prospect.joyent.us (Postfix) with ESMTPSA id 14CD01ECC7; Tue, 30 Dec 2008 21:39:34 +0000 (GMT)
From: "Peter Hesse"
To: "'RL 'Bob' Morgan'" , "'Paul Hoffman'"
Cc: , , ,
References: <[email-masked]> <[email-masked]>
In-Reply-To:
Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate
Date: Tue, 30 Dec 2008 16:39:34 -0500
Message-ID: <08bb01c96ac7$1cd5a750$5680f5f0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AclqxboXk3PuIMY0SLuDtNKXm7F2qQAAEKtA
Content-Language: en-us
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Ceasing the issuance of certificates with MD5 used in the signature doesn't
solve the problem of the certificates that have already been issued and are
still out there, any number of which may be rogue.

Replacing, or marking as untrusted all root certificates which have any
current valid (i.e. non-expired, non-revoked) certificates with MD5 used in
the signature could have tremendous undesirable impact and be an untenable
solution.

The right tool for the job is a client-side solution to fail validation of
any signature which uses MD5, especially certificate signatures. I will not
hold my breath for such a solution.

--Peter

----------------------------------------------------------------
Peter Hesse [email-masked]
http://securitymusings.com http://geminisecurity.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of RL 'Bob' Morgan
Sent: Tuesday, December 30, 2008 4:18 PM
To: Paul Hoffman
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate

> Regardless of that, the authors of the MD5 paper are correct: trust
> anchors signed with MD5 are highly questionable as of today (well,
> actually, since they published their last paper). Hopefully, the
> maintainers of the popular trust anchor repositories (Microsoft,
> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and
> MD2!) as soon as possible.

This is a different claim than "CAs should stop issuing certs with MD5
signatures", which is what I as an amateur take away from a quick scan of
the material. Obviously MD5 is suspect in various ways, but does this new
work lead to the conclusion that MD5-signed roots are untrustworthy today?
Replacing a root is a much bigger deal then changing signing practices.

- RL "Bob"

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULNIAn038040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:23:18 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBULNIdv038039; Tue, 30 Dec 2008 14:23:18 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULNH61038023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:23:17 -0700 (MST) (envelope-from [email-masked])
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id C219450822; Tue, 30 Dec 2008 13:39:34 -0800 (PST)
Date: Tue, 30 Dec 2008 13:39:34 -0800
From: Eric Rescorla
To: Paul Hoffman
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
In-Reply-To:
References: <[email-masked]> <[email-masked]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At Tue, 30 Dec 2008 12:53:06 -0800,
Paul Hoffman wrote:
>
> At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote:
> >This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack.
>
> Your recollection may be off. I believe I was the person who brought
> up the serial number hack at the mic, and I'm pretty sure I said
> "some", not "many" (and certainly not "most"!). When I looked at a
> handful of popular CAs earlier this week, I only found a few who are
> using randomization in their serial numbers.

So it's in my deck from SAAG at IETF 62.

http://www.ietf.org/proceedings/05mar/slides/saag-3.pdf

I don't know whether many or most do it. IMO everyone should.

> >RFC 5280 does not include this advice. It is sound advice that was
> >discussed in PKIX and other venues. Perhaps a BCP is in order.
>
> Man, that is really stretching the definition of "best".
>
> For one, it is only needed in signatures that use known-attackable
> hash functions. A "best practice" in that case is to use a better
> hash function in the signature. Also, it relies on the ability of
> the software using the random number to be sure that the result is a
> positive integer in ASN.1, which seems overly optimistic.
>
> If the IETF feels that adding randomization to signatures is
> important, we should define randomized signature functions. We could
> start with NIST Draft SP 800-106
> (). However,
> I think that doing so is sending the wrong message: we should
> instead be encouraging the use of non-broken hash functions.

I certainly agree we should be encouraging the use of non-broken hash
functions. However, randomizing the SN seems like very cheap backward
compatible insurance against the fact that that's going to take a long time.

-Ekr

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULIest037910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:18:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBULIefq037903; Tue, 30 Dec 2008 14:18:40 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULIShF037889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 14:18:39 -0700 (MST) (envelope-from [email-masked])
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout5.cac.washington.edu (8.14.3+UW08.09/8.14.3+UW08.11) with ESMTP id mBULIO3h014517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Dec 2008 13:18:24 -0800
X-Auth-Received: from D-140-142-21-194.dhcp4.washington.edu (D-140-142-21-194.dhcp4.washington.edu [140.142.21.194]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.14.3+UW08.09/8.14.3+UW08.11) with ESMTP id mBULIOpq023005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Dec 2008 13:18:24 -0800
Date: Tue, 30 Dec 2008 13:17:50 -0800 (PST)
From: "RL 'Bob' Morgan"
X-X-Sender: [email-masked]
To: Paul Hoffman
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
In-Reply-To:
Message-ID:
References: <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.5.0.356843, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2008.12.30.210424
X-Uwash-Spam: Gauge=IIIIIII, Probability=8%, Report='BODY_SIZE_1000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_700_799 0, FROM_EDU_TLD 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0'
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> Regardless of that, the authors of the MD5 paper are correct: trust
> anchors signed with MD5 are highly questionable as of today (well,
> actually, since they published their last paper). Hopefully, the
> maintainers of the popular trust anchor repositories (Microsoft,
> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and
> MD2!) as soon as possible.

This is a different claim than "CAs should stop issuing certs with MD5
signatures", which is what I as an amateur take away from a quick scan of
the material. Obviously MD5 is suspect in various ways, but does this new
work lead to the conclusion that MD5-signed roots are untrustworthy today?
Replacing a root is a much bigger deal then changing signing practices.

- RL "Bob"

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUKrcEw036778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:53:38 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUKrcNS036777; Tue, 30 Dec 2008 13:53:38 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] ([207.62.247.66]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUKrXOU036766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:53:34 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Tue, 30 Dec 2008 12:53:06 -0800
To: [email-masked], [email-masked], [email-masked], [email-masked]
From: Paul Hoffman
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote:
>This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack.

Your recollection may be off. I believe I was the person who brought up the serial number hack at the mic, and I'm pretty sure I said "some", not "many" (and certainly not "most"!). When I looked at a handful of popular CAs earlier this week, I only found a few who are using randomization in their serial numbers.

Regardless of that, the authors of the MD5 paper are correct: trust anchors signed with MD5 are highly questionable as of today (well, actually, since they published their last paper). Hopefully, the maintainers of the popular trust anchor repositories (Microsoft, Mozilla, etc.) will yank out the trust anchors signed with MD5 (and MD2!) as soon as possible.

At 3:10 PM -0500 12/30/08, Russ Housley wrote:
>RFC 5280 does not include this advice. It is sound advice that was discussed in PKIX and other venues. Perhaps a BCP is in order.

Man, that is really stretching the definition of "best".

For one, it is only needed in signatures that use known-attackable hash functions. A "best practice" in that case is to use a better hash function in the signature. Also, it relies on the ability of the software using the random number to be sure that the result is a positive integer in ASN.1, which seems overly optimistic.

If the IETF feels that adding randomization to signatures is important, we should define randomized signature functions. We could start with NIST Draft SP 800-106 (). However, I think that doing so is sending the wrong message: we should instead be encouraging the use of non-broken hash functions.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUKGsOx035034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:16:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUKGs2c035033; Tue, 30 Dec 2008 13:16:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUKGhdl035004 for ; Tue, 30 Dec 2008 13:16:53 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 14731 invoked by uid 0); 30 Dec 2008 20:16:37 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 20:16:37 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Dec 2008 15:10:45 -0500
To: Jeffrey Hutzelman
From: Russ Housley
Subject: Re: Further MD5 breaks: Creating a rogue CA certificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Jeff:

>>http://www.win.tue.nl/hashclash/rogue-ca/
>>
>>MD5 considered harmful today
>>Creating a rogue CA certificate
>>
>>December 30, 2008
>>
>>Alexander Sotirov, Marc Stevens,
>>Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de
>>Weger
>>
>>We have identified a vulnerability in the Internet Public Key
>>Infrastructure (PKI) used to issue digital certificates for secure
>>websites. As a proof of concept we executed a practical attack scenario
>>and successfully created a rogue Certification Authority (CA) certificate
>>trusted by all common web browsers. This certificate allows us to
>>impersonate any website on the Internet, including banking and e-commerce
>>sites secured using the HTTPS protocol.
>>
>>Our attack takes advantage of a weakness in the MD5 cryptographic hash
>>function that allows the construction of different messages with the same
>>MD5 hash. This is known as an MD5 "collision". Previous work on MD5
>>collisions between 2004 and 2007 showed that the use of this hash
>>function in digital signatures can lead to theoretical attack scenarios.
>>Our current work proves that at least one attack scenario can be
>>exploited in practice, thus exposing the security infrastructure of the
>>web to realistic threats.
>
>
>This is a practical application of an approach that I remember being
>brought up during discussions about MD5 at a saag meeting some time
>ago. I also recall someone mentioning at the time that many/most
>CA's were already issuing certificates with random rather than
>sequential serial numbers, which would have thwarted this particular attack.

RFC 5280 does not include this advice. It is sound advice that was
discussed in PKIX and other venues. Perhaps a BCP is in order.

Russ

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUK78Ju034463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:07:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUK78Cg034461; Tue, 30 Dec 2008 13:07:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUK6sZq034429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:07:08 -0700 (MST) (envelope-from [email-masked])
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id DFF4550822; Tue, 30 Dec 2008 12:23:11 -0800 (PST)
Date: Tue, 30 Dec 2008 12:23:11 -0800
From: Eric Rescorla
To: Jeffrey Hutzelman
Cc: Russ Housley , [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At Tue, 30 Dec 2008 13:33:46 -0500,
Jeffrey Hutzelman wrote:
>
> --On Tuesday, December 30, 2008 11:05:28 AM -0500 Russ Housley
> wrote:
>
> > http://www.win.tue.nl/hashclash/rogue-ca/
> >
> > MD5 considered harmful today
> > Creating a rogue CA certificate
> >
> > December 30, 2008
> >
> > Alexander Sotirov, Marc Stevens,
> > Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de
> > Weger
> >
> > We have identified a vulnerability in the Internet Public Key
> > Infrastructure (PKI) used to issue digital certificates for secure
> > websites. As a proof of concept we executed a practical attack scenario
> > and successfully created a rogue Certification Authority (CA) certificate
> > trusted by all common web browsers. This certificate allows us to
> > impersonate any website on the Internet, including banking and e-commerce
> > sites secured using the HTTPS protocol.
> >
> > Our attack takes advantage of a weakness in the MD5 cryptographic hash
> > function that allows the construction of different messages with the same
> > MD5 hash. This is known as an MD5 "collision". Previous work on MD5
> > collisions between 2004 and 2007 showed that the use of this hash
> > function in digital signatures can lead to theoretical attack scenarios.
> > Our current work proves that at least one attack scenario can be
> > exploited in practice, thus exposing the security infrastructure of the
> > web to realistic threats.
>
>
> This is a practical application of an approach that I remember being
> brought up during discussions about MD5 at a saag meeting some time ago. I
> also recall someone mentioning at the time that many/most CA's were already
> issuing certificates with random rather than sequential serial numbers,
> which would have thwarted this particular attack.

Yep. Would that they all were.

FWIW, here is my writeup of this issue, targeted towards a broader
community:

http://www.educatedguesswork.org/2008/12/understanding_the_sotirov_et_a.html

-Ekr

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUIY5KW027105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 11:34:05 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUIY5K6027104; Tue, 30 Dec 2008 11:34:05 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUIXrB8027081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 11:34:04 -0700 (MST) (envelope-from [email-masked])
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUIXkTS014008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:33:47 -0500 (EST)
Date: Tue, 30 Dec 2008 13:33:46 -0500
From: Jeffrey Hutzelman
To: Russ Housley , [email-masked], [email-masked], [email-masked], [email-masked]
cc: [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--On Tuesday, December 30, 2008 11:05:28 AM -0500 Russ Housley
wrote:

> http://www.win.tue.nl/hashclash/rogue-ca/
>
> MD5 considered harmful today
> Creating a rogue CA certificate
>
> December 30, 2008
>
> Alexander Sotirov, Marc Stevens,
> Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de
> Weger
>
> We have identified a vulnerability in the Internet Public Key
> Infrastructure (PKI) used to issue digital certificates for secure
> websites. As a proof of concept we executed a practical attack scenario
> and successfully created a rogue Certification Authority (CA) certificate
> trusted by all common web browsers. This certificate allows us to
> impersonate any website on the Internet, including banking and e-commerce
> sites secured using the HTTPS protocol.
>
> Our attack takes advantage of a weakness in the MD5 cryptographic hash
> function that allows the construction of different messages with the same
> MD5 hash. This is known as an MD5 "collision". Previous work on MD5
> collisions between 2004 and 2007 showed that the use of this hash
> function in digital signatures can lead to theoretical attack scenarios.
> Our current work proves that at least one attack scenario can be
> exploited in practice, thus exposing the security infrastructure of the
> web to realistic threats.

This is a practical application of an approach that I remember being
brought up during discussions about MD5 at a saag meeting some time ago. I
also recall someone mentioning at the time that many/most CA's were already
issuing certificates with random rather than sequential serial numbers,
which would have thwarted this particular attack.

-- Jeff

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUG5kww018631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 09:05:46 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUG5jD9018622; Tue, 30 Dec 2008 09:05:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUG5YRs018576 for ; Tue, 30 Dec 2008 09:05:44 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 4826 invoked by uid 0); 30 Dec 2008 16:05:29 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 16:05:29 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Dec 2008 11:05:28 -0500
To: [email-masked], [email-masked], [email-masked], [email-masked]
From: Russ Housley
Subject: Further MD5 breaks: Creating a rogue CA certificate
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

http://www.win.tue.nl/hashclash/rogue-ca/

MD5 considered harmful today
Creating a rogue CA certificate

December 30, 2008

Alexander Sotirov, Marc Stevens,
Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger

We have identified a vulnerability in the Internet Public Key
Infrastructure (PKI) used to issue digital certificates for secure
websites. As a proof of concept we executed a practical attack
scenario and successfully created a rogue Certification Authority
(CA) certificate trusted by all common web browsers. This certificate
allows us to impersonate any website on the Internet, including
banking and e-commerce sites secured using the HTTPS protocol.

Our attack takes advantage of a weakness in the MD5 cryptographic
hash function that allows the construction of different messages with
the same MD5 hash. This is known as an MD5 "collision". Previous work
on MD5 collisions between 2004 and 2007 showed that the use of this
hash function in digital signatures can lead to theoretical attack
scenarios. Our current work proves that at least one attack scenario
can be exploited in practice, thus exposing the security
infrastructure of the web to realistic threats.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSDgUl0064477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2008 06:42:30 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBSDgUVJ064476; Sun, 28 Dec 2008 06:42:30 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSDgTI8064469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 28 Dec 2008 06:42:30 -0700 (MST) (envelope-from [email-masked])
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id mBSDgTBV016209; Sun, 28 Dec 2008 05:42:29 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Dec 2008 05:42:29 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C968F2.1F8A2075"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: New Version Notification for draft-hallambaker-ocspagility-02
Date: Sun, 28 Dec 2008 05:42:27 -0800
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: New Version Notification for draft-hallambaker-ocspagility-02
Thread-Index: AclUrVTMVGC0OUj3RuOSZcazd8skDgAAWWYUAbAkkKADYA7QBQ==
References: <[email-masked]> <[email-masked]> <[email-masked]>
From: "Hallam-Baker, Phillip"
To: "Stefan Santesson" ,
X-OriginalArrivalTime: 28 Dec 2008 13:42:29.0287 (UTC) FILETIME=[2077DB70:01C968F2]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C968F2.1F8A2075
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

1) On the issue of algorithm strength. The problem here is that the =
accepted strength of an algorithm may change during the validity period =
of the cert. So RSA 1024 might be perfectly acceptable for use in =
conjunction with an OCSP validity check mechanism, provided that the =
OCSP check is solid.

We have for many years had the luxury of being able to avoid concerns =
for crypto algorithm strength by simply adding more bits. Let that =
continue for as long as possible, but if it does happen there are a lot =
of edge cases that are likely to be thrown up during the transition that =
are ugly.

Another case that I have been looking at a lot recently is one where a =
device that is incapable of doing public key crypto is being used in a =
PKI. This is for SCADA type applications. Believe it or not it is =
entirely possible to make this situation work with very low cost, low =
power micro-controller devices. There was a lot of work done on this =
early on in the development of PKI but the ideas were mostly dropped as =
(1) workstation class machines became ubiquitous and the CPU overhead =
issue became moot and (2) these approaches decrease the CPU overhead at =
the periphery by concentrating it at the server, not a winning strategy =
in 1985, but one that is entirely practical today.

These are devices that have too little RAM to generate an RSA 2048 bit =
signature, let alone an Ethernet packet. But they can do AES and there =
are serious reasons for doing so.

2) I left RFC 5019 out of consideration entirely when writing the draft. =
Looking over it again I think that it already makes the decisions for =
us, all we need to do is to make reference to the existing decision =
here, perhaps adding an explanation of the reason why. Cache busting is =
already discouraged in 5019.

Use of request extensions is already a SHOULD NOT in RFC 5019, so this =
would be carried over here. Applications SHOULD NOT be using the =
algorithm selector extension unless there is a compatibility driven =
reason not to. I think we should state this and give the reason (cache =
busting) as the whole point of a SHOULD NOT is that there is a potential =
balance. If an application absolutely needs to specify the extension to =
function then that takes priority over cache busting.

-----Original Message-----
From: [email-masked] on behalf of Stefan Santesson
Sent: Thu 12/11/2008 4:21 AM
To: Hallam-Baker, Phillip; [email-masked]
Subject: RE: New Version Notification for =
draft-hallambaker-ocspagility-02=20
=20
Phil,

=20

I have a few comments on the draft:

=20

This is more a nit, but I don't think the following is a compelling =
argument, strong enough to be mentioned:

o An implementation may intentionally wish to guard against the

possibility of a compromise resulting from a signature algorithm

compromise by employing two separate encryption algorithms.

=20

If an implementation is securing two co-dependent messages with two =
different algorithms, where breaking one of them successfully =
compromises the system, then you have increased your risk of compromise =
rather than reducing it.

=20

Further, I would like to see some explicit text, explaining that this =
approach is not applicable, or at least should not be used in =
combination with implementations of 5019.

Section 4.2. do state that the server can pre-produce several responses =
to the same request signed with different algorithms, but what I'm most =
concerned with is that clients including the extension in the request, =
in combination with RFC 5019 implementations may mess up http caching. =
Http caching is an important aspect of achieving scalability for LW =
OCSP.=20

=20

I would prefer to entirely discourage the use of this client extension =
with RFC 5019, but at least discuss the issue in the draft to make =
implementers aware of the problem.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Hallam-Baker, Phillip
Sent: den 2 december 2008 20:01
To: [email-masked]
Subject: FW: New Version Notification for =
draft-hallambaker-ocspagility-02=20

=20

=20

As promised at the meeting, here is an update to the OCSP agility draft.

With the WG and chair's permission I will resubmit as a WG draft.

The basic history here is that we tried to deploy an OCSP resolver that =
meets a pretty simple set of requirements for multiple algorithm support =
and found that the base specification does not actually say anything =
about how a response signature algorithm should be chosen, except that =
SHA-1 can be implemented.

So a perfectly legal OCSP responder could report the status of a public =
key certificate for an RSA signature key, signed with an RSA signature =
key with ECC.

And it gets worse, if you have an ocsp responder that is managing certs =
signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, =
etc. etc.) and a status request comes in for an unknown cert, there is =
no data for the responder to choose a reasonble response alg. You are =
forced to choose a lowest common denominator alg which is a problem if =
you moved to ECC because RSA 4096 does not cut it.

So this is a pretty simple fix to sort it out. I suggest that this goes =
on standards track and if we progress OCSP from PROPOSED to DRAFT we =
dump the explanatory part and merge the normative text in.

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Tue 12/2/2008 1:39 PM
To: Hallam-Baker, Phillip
Subject: New Version Notification for draft-hallambaker-ocspagility-02

A new version of I-D, draft-hallambaker-ocspagility-02.txt has been =
successfuly submitted by Phillip Hallam-Baker and posted to the IETF =
repository.

Filename: draft-hallambaker-ocspagility
Revision: 02
Title: OCSP Algorithm Agility
Creation_date: 2008-12-02
WG ID: Independent Submission
Number_of_pages: 8

Abstract:
The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.
=
=20

The IETF Secretariat.

------_=_NextPart_001_01C968F2.1F8A2075
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

1) On the issue of algorithm strength. The problem =
here is that the accepted strength of an algorithm may change during the =
validity period of the cert. So RSA 1024 might be perfectly acceptable =
for use in conjunction with an OCSP validity check mechanism, provided =
that the OCSP check is solid.

We have for many years had the luxury of being able to avoid concerns =
for crypto algorithm strength by simply adding more bits. Let that =
continue for as long as possible, but if it does happen there are a lot =
of edge cases that are likely to be thrown up during the transition that =
are ugly.

Another case that I have been looking at a lot recently is one where a =
device that is incapable of doing public key crypto is being used in a =
PKI. This is for SCADA type applications. Believe it or not it is =
entirely possible to make this situation work with very low cost, low =
power micro-controller devices. There was a lot of work done on this =
early on in the development of PKI but the ideas were mostly dropped as =
(1) workstation class machines became ubiquitous and the CPU overhead =
issue became moot and (2) these approaches decrease the CPU overhead at =
the periphery by concentrating it at the server, not a winning strategy =
in 1985, but one that is entirely practical today.

These are devices that have too little RAM to generate an RSA 2048 bit =
signature, let alone an Ethernet packet. But they can do AES and there =
are serious reasons for doing so.

2) I left RFC 5019 out of consideration entirely when writing the draft. =
Looking over it again I think that it already makes the decisions for =
us, all we need to do is to make reference to the existing decision =
here, perhaps adding an explanation of the reason why. Cache busting is =
already discouraged in 5019.

Use of request extensions is already a SHOULD NOT in RFC 5019, so this =
would be carried over here. Applications SHOULD NOT be using the =
algorithm selector extension unless there is a compatibility driven =
reason not to. I think we should state this and give the reason (cache =
busting) as the whole point of a SHOULD NOT is that there is a potential =
balance. If an application absolutely needs to specify the extension to =
function then that takes priority over cache busting.

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

From: [email-masked] on behalf of Stefan Santesson

Sent: Thu 12/11/2008 4:21 AM

To: Hallam-Baker, Phillip; [email-masked]

Subject: RE: New Version Notification for =
draft-hallambaker-ocspagility-02

Phil,

I have a few comments on the draft:

This is more a nit, but I don't think the following is a compelling =
argument, strong enough to be mentioned:

o  An implementation may intentionally wish to guard =
against the

possibility of a compromise resulting =
from a signature algorithm

compromise by employing two separate =
encryption algorithms.

If an implementation is securing two co-dependent messages with two =
different algorithms, where breaking one of them successfully =
compromises the system, then you have increased your risk of compromise =
rather than reducing it.

Further, I would like to see some explicit text, explaining that this =
approach is not applicable, or at least should not be used in =
combination with implementations of 5019.

Section 4.2. do state that the server can pre-produce several responses =
to the same request signed with different algorithms, but what I'm most =
concerned with is that clients including the extension in the request, =
in combination with RFC 5019 implementations may mess up http caching. =
Http caching is an important aspect of achieving scalability for LW =
OCSP.

I would prefer to entirely discourage the use of this client extension =
with RFC 5019, but at least discuss the issue in the draft to make =
implementers aware of the problem.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: [email-masked] [mailto:owner-ietf-pkix@mail.=
imc.org] On Behalf Of Hallam-Baker, Phillip

Sent: den 2 december 2008 20:01

To: [email-masked]

Subject: FW: New Version Notification for =
draft-hallambaker-ocspagility-02

As promised at the meeting, here is an update to the OCSP agility =
draft.

With the WG and chair's permission I will resubmit as a WG draft.

The basic history here is that we tried to deploy an OCSP resolver that =
meets a pretty simple set of requirements for multiple algorithm support =
and found that the base specification does not actually say anything =
about how a response signature algorithm should be chosen, except that =
SHA-1 can be implemented.

So a perfectly legal OCSP responder could report the status of a public =
key certificate for an RSA signature key, signed with an RSA signature =
key with ECC.

And it gets worse, if you have an ocsp responder that is managing certs =
signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, =
etc. etc.) and a status request comes in for an unknown cert, there is =
no data for the responder to choose a reasonble response alg. You are =
forced to choose a lowest common denominator alg which is a problem if =
you moved to ECC because RSA 4096 does not cut it.

So this is a pretty simple fix to sort it out. I suggest that this goes =
on standards track and if we progress OCSP from PROPOSED to DRAFT we =
dump the explanatory part and merge the normative text in.

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

From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Tue 12/2/2008 1:39 PM

To: Hallam-Baker, Phillip

Subject: New Version Notification for =
draft-hallambaker-ocspagility-02

A new version of I-D, draft-hallambaker-ocspagility-02.txt has been =
successfuly submitted by Phillip Hallam-Baker and posted to the IETF =
repository.

Filename:        =
draft-hallambaker-ocspagility

Revision:        02

Title:           OCSP =
Algorithm Agility

Creation_date:   2008-12-02

WG ID:           =
Independent Submission

Number_of_pages: 8

Abstract:

The OSCP specification defined in RFC 2560 requires server responses

to be signed but does not specify a mechanism for selecting the

signature algorithm to be used leading to possible interoperability

failures in contexts where multiple signature algorithms are in use.

This document specifies an algorithm for server signature algorithm

selection and an extension that allows a client to advise a server

that specific signature algorithms are supported.

&=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;            =
;            =

The IETF Secretariat.

------_=_NextPart_001_01C968F2.1F8A2075--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSDNnSx052283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2008 06:23:49 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBSDNneh052282; Sun, 28 Dec 2008 06:23:49 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSDNbc3052156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 28 Dec 2008 06:23:48 -0700 (MST) (envelope-from [email-masked])
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id mBSDNTHV015723; Sun, 28 Dec 2008 05:23:29 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Dec 2008 05:23:29 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C968EF.78855DA5"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: straw poll
Date: Sun, 28 Dec 2008 05:22:58 -0800
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: straw poll
Thread-Index: AclfldXoaVlJ2Y9ATQKYgYj+/Dr6oAJWZBwc
References:
From: "Hallam-Baker, Phillip"
To: "Stephen Kent" ,
X-OriginalArrivalTime: 28 Dec 2008 13:23:29.0403 (UTC) FILETIME=[790B5CB0:01C968EF]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C968EF.78855DA5
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

1 yes
2 yes

-----Original Message-----
From: [email-masked] on behalf of Stephen Kent
Sent: Tue 12/16/2008 9:29 AM
To: [email-masked]
Subject: straw poll
=20

At a previous IETF meeting (Dublin) I agreed to conduct a straw poll=20
on adding a new WG item to address OCSP algorithm agility concerns,=20
after PHB sent a message indicating what status he envisioned for the=20
work. This action for both me and PHB fell through the cracks. At the=20
MSP IETF meeting PHB provided a briefing on the problems that he saw=20
re OCSP ambiguities re algorithm agility, and proposed a standards=20
track document to address these issues (see PHB's message of 12/2).

So, we now have a concrete proposal (draft-hallambaker-ocspagility)=20
available for review. PHB would like to publish this and then merge=20
it into the OCSP document when it progresses from PROPOSED to DRAFT=20
(see his message of 12/2).

Please send a message to the list by January 9th (allowing for=20
holiday outages) indicating whether

1. your support PKIX work in this area
2. you support adopting PHB's document as a starting point=20
for such work

Thanks & Happy Hoplidays,

Steve

------_=_NextPart_001_01C968EF.78855DA5
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: straw poll

1 yes

2 yes

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

From: [email-masked] on behalf of Stephen Kent

Sent: Tue 12/16/2008 9:29 AM

To: [email-masked]

Subject: straw poll

At a previous IETF meeting (Dublin) I agreed to conduct a straw poll

on adding a new WG item to address OCSP algorithm agility concerns,

after PHB sent a message indicating what status he envisioned for =
the

work. This action for both me and PHB fell through the cracks. At =
the

MSP IETF meeting PHB provided a briefing on the problems that he saw

re OCSP ambiguities re algorithm agility, and proposed a standards

track document to address these issues (see PHB's message of 12/2).

So, we now have a concrete proposal (draft-hallambaker-ocspagility)

available for review. PHB would like to publish this and then merge

it into the OCSP document when it progresses from PROPOSED to DRAFT

(see his message of 12/2).

Please send a message to the list by January 9th (allowing for

holiday outages) indicating whether

1. your support PKIX work in =
this area

2. you support adopting PHB's =
document as a starting point

for such work

Thanks & Happy Hoplidays,

Steve

------_=_NextPart_001_01C968EF.78855DA5--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSA6Ggv020552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2008 03:06:16 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBSA6G42020546; Sun, 28 Dec 2008 03:06:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp812.mail.ird.yahoo.com (smtp812.mail.ird.yahoo.com [217.146.188.72]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBSA5teu020340 for ; Sun, 28 Dec 2008 03:06:13 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 82718 invoked from network); 28 Dec 2008 10:05:54 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=H1hf/YBxnVdvsuhHfSDvf2GAbZlm4/WkF/SI/9WiPWKca7LOP0Qyhdb2VSe7i0CM4OJp3AdgsxsC0FYF/n+Q7ePDjLdeNzC7qW4kCrT0jjh6i+sLbbMq1mnrTCB+l5P40JUvYJUc29fbGiiyhWqIZJ2PUheymAhxCslw4XAe5Yo= ;
Received: from unknown (HELO ?192.168.1.67?) ([email-masked] with plain) by smtp812.mail.ird.yahoo.com with SMTP; 28 Dec 2008 10:05:54 -0000
X-YMail-OSG: kc7VFaEVM1nlVjqlZ7Cid.ujlJyL78D6T6.eF28dxzVps_NNxOT.RXIyRnxY5wmAM_6.DkCgBm_Pvkn_1G8BSprCsTk60nX6nPvOx6wiRSQUzD0oYsgjXX_6t52x1Sz3Up9mX8QW6VNrg8YtmCBFYgfa1D0mJjTsovT6FdYeYc_QdBSoKuX7ATaZ1XUzzKSXB7DhXrjCFUrH5REbVOq19eFZETY-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Sun, 28 Dec 2008 10:05:54 +0000
From: John Larmouth
Reply-To: [email-masked]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: Tom Gindin
CC: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , [email-masked], [email-masked], [email-masked], asn1dev
Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
References:
In-Reply-To:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Tom,

There are several comments to be made. Forgive me for being verbose, but I
think that in this area, brief replies can so easily be misunderstood.

1) First, forget the old stuff with identifiers (that is the old and
correct term) for names on arcs of the OID tree. They were always (and
still are) ASCII text, with an initial lower-case letter. Originally,
they were expected to be unique (but were never carried in protocol,
only in human value notation). Then later, it was recognised that
company names changed (due to take-over, merger, etc, and that they wanted to
use a different name for their arc (but not to change the numerical value). It
was then (circa 1992) that they should NOT be regarded as unique, and that
variants would be allowed (this brought the Standard into line with existing
practice). About the same time, CCITT changed its name, and synonyms were
formally assigned for some top-level arcs - but still
restricted to ASCII characters, starting with a lower case letter.
**Forget that stuff - it is historical! But, of course, still in use.**

2) Formally, an arc now has an always unique and unambiguous numerical value
(as before); the old not-necessarily-unique-or-unambiguous identifiers (as
before); but also has one or more Unicode labels (any - more-or-less - Unicode
characters) that is required to be unambiguous from the superior node, but not
necessarily unique (multiple Unicode labels are allowed on an arc to allow for
different language variants). This was much discussed and fought over, but was
eventually agreed as the best solution, but with some people still dissenting,
and wanting only one (unique) Unicode label on an arc.

3) As part of this extension, it was recognised that the limitation to three
top-level arcs (itu-t(0), iso(1), and joint-iso-itu-t(2)) was too limiting.
Fortunately, arc 2 had already been used to provide allocations for other SDOs,
and provided the x is less than 47, the OID {2, x} encodes into a single octet.
We now restrict the allocation of arcs {2, x} to organisations that need the
single octet encoding, but there are still quite a few x values left for future
allocation. For encoding purposes, the top two levels are effectively a single
set of top-level arcs, encoding into a single octet, provided x is less than 47
for arc 2, with similar restrictions on the arcs beneath arcs 0 and 1.

4) When Unicode labels were introduced, the concept of "long arcs" were included
specifically for use at the top level. So it is now possible for long arcs to
be allocated, with Unicode labels (but no numeric identifier) directly from the
root to an arc beneath arc 2, and it is now common practice to allocate a long
arc whenever an arc is allocated beneath arc 2 for any major organisation or SDO.

5) Finally, there was recognition of the problem of mapping a sequence of
Unicode labels (representing a set of arcs) into a canonical list of integers
for the numerical values of those arcs (in the case of a long arc, a Unicode
label would map into - typically - two integers, for example 2.13). This gave
rise to "work in progress" on an "OID resolution process". You will recognise
that this is very much what the ubiquitous DNS service provides - a mapping from
a set of names (domain names, little-endian order in the set) to a set of
numbers (IP addresses, big-endian order in the set). DNS look-up is
universally supported, and well-established, and the current hope/intent is to
be able to do OID resolution using the DNS service, but discussions are still in
progress on this. The alternative of an X.500 base for OID resolution has also
been much discussed, and not abandonned. But deployment of X.500 look-up
software is not as ubiquitous as DNS resolution software and databases. It may
be that at the stardardisation level, we will see two resolution services
documented - DNS-based and X.500-based. But it is too early to comment on that.

6) Now we come to IRI registration of the "oid" scheme, which is what the
Internet Draft is concerned with. This is not essential to support these
developments, but was a target from the start of the work. The sequence of
Unicode labels on a path from the root to a node is undoubtedly, in plain
English language terms, an internationalised resource identifier. So
registration of an IRI "oid" scheme with IANA was always a target for the work.
It was felt that the Standard should be in place before the registration was
attempted. So we now have an Internet Draft under review with uri-review, in
the hope that this can be "massaged" into a form that would allow us to proceed
with the formal IANA registration of the "oid" IRI scheme in the not too distant
future.

I hope this has gone some way towards answering your questions.

John L

Tom Gindin wrote:

> John:
>
> This draft is interesting and useful for some purposes, but I
>don't see how it addresses the case where a high-level arc (beyond the
>control of the development organization) is renamed. Since that's
>precisely the case we are discussing here (although the change took place
>quite a while ago and it's reasonable to expect people to adjust), it
>doesn't actually seem to help us. Am I missing something?
> Also, unless I have missed something, there are only three
>top-level arcs defined for OID's and they all now have names.
>
> Tom Gindin
>
>
>
>
>John Larmouth
>Sent by: [email-masked]
>12/22/2008 10:48 AM
>Please respond to
>[email-masked]
>
>
>To
>Alfred �
>cc
>[email-masked], [email-masked], [email-masked]
>Subject
>Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
>
>
>
>
>
>
>Alfred,
>
>The synonyms were introduced some time ago, and, indeed, the names are
>non-normative, and may not even be unambiguous. Only the numbers matter
>in an OID in an encoding.
>
>However, the recent introduction of Unicode labels, as normative and
>unambigous names gives a new naming scheme to the (same) OID tree that
>enables names (Unicode labels) to be used in machine communication if
>desired. The ASN.1 type is called OID_IRI and provides for node
>identification using Unicode labels. Unicode labels with names similar to
>the old ASCII names have been assigned for many of the top-level arcs, and
>more will be added over time.
>
>The OID_IRI type is related to (but not dependent on) the application for
>an "oid" IRI scheme, but for consistency this is desired. See I-D
>draft-larmouth-oid-iri-00.
>
>John L
>
>Alfred � wrote:
>Folks / to whom it concerns,
>
>during recent reviews of active I-Ds containing ASN.1 related
>to the X.500 framework, I found that a couple of these do not
>consistently employ the revised name of the top-level OID branch
>
> joint-iso-itu-t(2) ,
>
>but instead use the outdated/legacy name
>
> joint-iso-ccitt(2) .
>
>Some drafts use a mix of both names.
>
>I suggest that the modern version joint-iso-itu-t(2) be used
>consistently within all new drafts / draft versions, unless
>intentionally and explicitely for historical evidence reference
>has to be made to the old name.
>
>Kind regards,
> Alfred.
>
>
>
>
>

--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Design Services Ltd)
1 Blueberry Road
Bowdon [email-masked]
Altrincham
Cheshire
WA14 3LS
England
Tel: +44 161 928 1605

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBR5knsi097244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Dec 2008 22:46:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBR5knVg097243; Fri, 26 Dec 2008 22:46:49 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBR5kb3k097231 for ; Fri, 26 Dec 2008 22:46:48 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 29194 invoked from network); 27 Dec 2008 05:47:05 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;27 Dec 2008 05:47:05 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 27 Dec 2008 05:47:04 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C967E6.7A3B5275"
Subject: RE: TA requirements doc - do we need it?
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sat, 27 Dec 2008 00:46:34 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: TA requirements doc - do we need it?
Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9AAC9gTrAAApWoQAAk2WagAEDwEFAACsxGQA==
References: <[email-masked]>
From: "Santosh Chokhani"
To: "Stefan Santesson" , , "Kemp, David P."
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C967E6.7A3B5275
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stefan,

=20

I for one do not see how your e-mail relates to the TA requirements
document or Dave's post. See responses in-line.

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Thursday, December 18, 2008 11:47 AM
To: [email-masked]; Kemp, David P.
Subject: FW: TA requirements doc - do we need it?

I'm resending this as my original mail got filtered due to exceeding
pkix message size restrictions.

I have now replaced the embedded picture with a URL to the screenshot.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

From: Stefan Santesson=20
Sent: den 17 december 2008 11:43
To: 'Kemp, David P.'; [email-masked]
Subject: RE: TA requirements doc - do we need it?

=20

Dave,

=20

You raise valid points and I partly try to avoid them because the answer
is somewhat long and complex. Long and complex answers are seldom
successful in standards discussions :-)

=20

Let me try to show my point through a screenshot that helped explain
this issue to at least one of the original contributors to the proposed
protocol. This is a screenshot of the Microsoft certificate management
snap-in:

=20

http://www.fiddler.nu/pkix/certmgr_mmc.jpg

=20

What you see here is the certificate trust policies in my laptop. It is
not one root store and it is not just about trust anchors. In my laptop
I have a certificate trust management snap-in for:

* Each host (local machine)

* Each user account

* Each service running on any host

[Santosh] This is consistent with TA requirements since TA requirements
deal with each TA store. In your case, the TA and TAMP will be applied
to three stores.

=20

In the Certificate snap-in window to the right, you see a fraction of
the list of services with individual certificate trust settings for one
host/machine.

[Santosh] This is consistent with TA material in that constraints can be
associated individually with the TAs.

=20

And it is not about just TA:s. It is about:

[Santosh] This is not relevant to the topic since it does not relate to
TA management.=20

* My personal certificates

* Trusted roots

* Intermediary CAs=20

* Directly trusted or untrusted certificates

* Etc, etc (See above)

=20

The structure of this information is not globally agreed and generic. It
is just how Microsoft have structured this in the Microsoft OS.

[Santosh] This is precisely why we need TAF and TAMP. That is what
requirements highlight.

=20

One could call this a set of certificate trust policies that are
dynamically managed and as you get closer to reality,=20

[Santosh] I would say a more accurate and complete characterization of
these is the constraints on the trust anchors.

=20

the border between roles, peoples and machines are getting more and more
virtual and dynamic and it becomes harder and harder to reduce this into
one generic, intrusive and centrally managed TA management protocol.

[Santosh] One would think that as things become more virtual and
dynamic, more you need the associated data with the TA and TAMP that can
enforce the constraints on the TA and on the associated data.

=20

Let me take a few examples from the requirements:

* The assumed roles and authorization model

* The assumption that there exist clearly identifiable TA
stores.

=20

The TA requirements are assuming a TA manager responsible for a TA
store.

[Santosh] While operationally this may be one manager managing the TA
store, the requirements and TAMP should be oriented towards many to
many. A TA manager can manage one or more TA in the TA store. A TA in
a TA store can be managed by more that one manager.

=20

The TA manager have authority over this TA store and have the power
update it or replace it. This also assumes that each TA store is
individually identifiable in the protocol itself. In my environment
above, I first of all don't have any isolated identifiable TA stores.

[Santosh] The TA need not be in a specific store, but it is always
identifiable by some combination of name, SPKI, and SKID.=20

=20

Secondly I don't have a clearly defined TA manager that has the right to
view and update this information on a local machine.

[Santosh] The TA requirements and TAMP should clarify this with the
constraints on the TAs.=20

=20

The applications or services that eventually are being affected by these
trust policy updates will not have a clue about what information that
was passed in any TA management protocol, or any IETF defined TA format
file several layers and APIs below their existence.=20

[Santosh] Agree and the applications do not do this. This is part of TA
management and not part of applications using the TA.

=20

So any discussion about how applications should take into account
specific path processing preferences provided by passing TA format
information around, such as applying specific constraints rules, is just
pretty theory without substance unless it is made part of standard RFC
5280 path processing and implemented in the APIs for path validation.

[Santosh] The TA requirements in the area of path processing are
consistent with 5280. 5280 specifically cites additional checks based
on the information associated with TA. See section 6.2 of 5280.

=20

In the environment I'm working with, I have no use for a transaction
based TA management protocol based on the simplified relationship
between a TA manager and a TA store.=20

[Santosh] That does not mean others do not need it. It also does not
mean that the environment you cited above would not benefit from in-band
re-key of the TA.

=20

If I had one, I would not know how to use it.

The only thing I would know how to use, is the TA format specification.
That one I can use to pass TAs around in my existing trust policy
framework.

[Santosh] You as a person will need not be aware of it, just like many
of nuances of PKI. The processing software will securely process the
transactions and update the TAs.

=20

I hope this was a useful clarification and my apology for passing
graphics in a PKIX posting. I hope you can view it.

[Santosh] The primary purpose of TA work is to permit in band, secure
installation and rekey of TAs. Unless you propose an alternative
mechanism to achieve this securely, the discourse you are having is not
providing any critique of the TA work.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kemp, David P.
Sent: den 16 december 2008 18:12
To: [email-masked]
Subject: RE: TA requirements doc - do we need it?

=20

Stefan,

=20

Refining the requirements as a series of I-Ds until "the scope of the
requirements is in harmony with problem space", then publishing as an
RFC once the requirements have converged, certainly sounds like the best
approach.

=20

But you have not explained how "The requirements are radically different
in a device oriented environment with disconnected units compared with a
centrally managed IT environment with a common network and data sharing
infrastructure." The requirements in either case are for managed
devices/applications/services to receive configuration items from
managers without those items being compromised in transit, yes?

=20

* Are you claiming that adversaries have no access to a "common
network and data sharing infrastructure" and therefore no protection is
needed in the networked case? That is patently false for all networks
of interest to the IETF.

* Or that the protection mechanisms appropriate for managing
networked platforms (Connection-oriented? MACs?) are different than
those needed for managing disconnected platforms
(Datagram/message-oriented? Signatures?)

=20

Without understanding the nature of your objections it's hard to tell
whether the scope of the requirements is already in harmony with the
entire problem space or not. Your 4-quadrant slide from Minneapolis is
not self-explanatory - I thought we had already disposed of the
push-pull issue by determining that there is no security-relevant
difference between posting to a repository from which a client may pull
and pushing directly to the client. Therefore the TAM requirements
already cover the left half of the space. If there is a single existing
TAM requirement that precludes pull, or a single missing TAM requirement
needed for pull, please provide an example.

=20

And I need help understanding the difference you see between TA and TA
Policy - if policy is "Host/App A will trust provider X for security
critical firmware category Z", and the TA store of Host/App A has
provider X's TA in the slot for firmware category Z, what is the
difference, other than level of abstraction, between "determine current
TAs in store" and "demonstrate compliance with policy"? Again, an
example of a missing TAM requirement needed to satisfy the right half of
your slide would go a long way toward understanding the scope issue.

=20

Dave

=20

=20

=20

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Tuesday, December 16, 2008 9:58 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: TA requirements doc - do we need it?

=20

Hi Santosh,

=20

As I expect, I sense that we have a slightly different view of the
generality of the proposed solution, but we seem to agree on the main
issue:

=20

The question one have to ask is if these requirements, in the form of an
RFC, would serve us as a community if we encounter a problem with the
proposed protocol. I doubt that it will as it at most will strengthen
the argument for those having an interest to adopt the original
protocol.

[Santosh] Having a requirements document that is a living document,
permits us to evaluate various solutions and protocols. If we do
encounter a security problem, it should be useful to analyze where the
engineering process failed, e.g., did we not articulate some
requirement, did we not have sufficient detail for a requirement, did
our analysis of protocol meeting a requirement was flawed, etc.

=20

I would also prefer to see the requirements document as a living
document as you suggest. I think that purpose is best served if the
requirements document remains in draft form.

=20

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: den 15 december 2008 17:47
To: Stefan Santesson; [email-masked]
Subject: RE: TA requirements doc - do we need it?

=20

Stefan,

=20

See my responses in-line below.=20

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Friday, December 12, 2008 7:25 AM
To: [email-masked]
Subject: TA requirements doc - do we need it?

=20

After all discussions in Minneapolis and going back and looking at the
current situation, I feel less and less convinced that we need to
approve any TA requirements document as an RFC. At least not in its
current form.

I'm fine with having it around as a draft for reference, but I fear it
may be a lot more harmful than beneficiary to us as an RFC.

=20

I have two major reasons:

=20

First, as I have argued and tried to explain with my slide in
Minneapolis, there is no general overall approach to TA management in a
complex IT environment.

[Santosh] In a complex distributed environment that needs to scale
across Enterprises, applying requisite security services to the payload
provides a scalable, interoperable, extensible, and secure solution.

=20

The requirements are radically different in a device oriented
environment with disconnected units compared with a centrally managed IT
environment with a common network and data sharing infrastructure.

[Santosh] The requirements are generally the same in terms of security
services. Some Enterprise IT management implementations may have
implemented Enterprise specific solutions taking advantages of existing
infrastructure and security services provided by the Enterprise network.
But, that solution may not be as scalable or open.

=20

Secondly, the requirements didn't come first. These requirements were
written with an existing protocol in mind. The lasting impression is
therefore that the requirements document was written to match and
support the original protocol, making it a tool to grandfather the
original protocol into IETF. I'm not claiming that this is the case, but
it remains to be my impression.

[Santosh] If you look at many of the engineering endeavors we undertake,
requirements are based on past experience, security vulnerabilities we
have encountered, past systems, etc. I do not know of many successful
efforts where requirements were developed in vacuum. In short, it is
fair to say that the requirements and protocol benefited from each other
and from past experiences with protocols and vulnerabilities.

=20

The question one have to ask is if these requirements, in the form of an
RFC, would serve us as a community if we encounter a problem with the
proposed protocol. I doubt that it will as it at most will strengthen
the argument for those having an interest to adopt the original
protocol.

[Santosh] Having a requirements document that is a living document,
permits us to evaluate various solutions and protocols. If we do
encounter a security problem, it should be useful to analyze where the
engineering process failed, e.g., did we not articulate some
requirement, did we not have sufficient detail for a requirement, did
our analysis of protocol meeting a requirement was flawed, etc.

=20

My proposal going forward is to do the following:

- In any case adjust the scope of the requirements document to
reflect the problem space the problem space it is designed for.

- Leave it as a draft, or at least not publish it as an RFC
before the scope is in harmony with the requirements.

=20

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

------_=_NextPart_001_01C967E6.7A3B5275
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stefan,

I for one do not =
see how
your e-mail relates to the TA requirements document or Dave’s =
post.
See responses in-line.

=

From:
[email-masked] [mailto:[email-masked]] =
On Behalf Of Stefan Santesson

Sent: Thursday, December =
18, 2008
11:47 AM

To: [email-masked]; =
Kemp, David
P.

Subject: FW: TA =
requirements doc -
do we need it?

I’m =
resending
this as my original mail got filtered due to exceeding pkix message size
restrictions.

I have now replaced the =
embedded picture
with a URL to the screenshot.

<=
/p>

<=
/p>

Stefan
Santesson

Senior =
Program Manager

Windows
Security, Standards

<=
/p>

From: =
Stefan Santesson

Sent: den 17 december =
2008 11:43

To: 'Kemp, David P.';
[email-masked]

Subject: RE: TA =
requirements doc -
do we need it?

Dave,

<=
/p>

You raise valid points and I =
partly try
to avoid them because the answer is somewhat long and complex. Long and =
complex
answers are seldom successful in standards discussions =
J

<=
/p>

Let me try to show my point =
through a
screenshot that helped explain this issue to at least one of the =
original
contributors to the proposed protocol. This is a screenshot of the =
Microsoft
certificate management snap-in:

<=
/p>

http://www.fiddler.nu=
/pkix/certmgr_mmc.jpg

<=
/p>

What you see here is the =
certificate
trust policies in my laptop. It is not one root store and it is not just =
about
trust anchors. In my laptop I have a certificate trust management =
snap-in for:

·         =
Each host (local =
machine)

·         =
Each user =
account

·         =
Each service running on =
any host

[Santosh] This is consistent with TA requirements =
since TA
requirements deal with each TA store.  In your case, the TA and =
TAMP will
be applied to three stores.

<=
/p>

In the Certificate snap-in =
window to the
right, you see a fraction of the list of services with individual =
certificate
trust settings for one host/machine.

[Santosh] This is consistent with TA material in that
constraints can be associated individually with the =
TAs.

<=
/p>

And it is not about just TA:s. =
It is
about:

[Santosh] This is not relevant to the topic since it =
does
not relate to TA management.

·         =
My personal =
certificates

·         =
Trusted =
roots

·         =
Intermediary CAs =

·         =
Directly trusted or =
untrusted
certificates

·         =
Etc, etc (See =
above)

<=
/p>

The structure of this =
information is not
globally agreed and generic. It is just how Microsoft have structured =
this in
the Microsoft OS.

[Santosh] This is precisely why we need TAF and TAMP. =
That
is what requirements highlight.

<=
/p>

One could call this a set of =
certificate
trust policies that are dynamically managed and as you get closer to =
reality,

[Santosh] I would say a more accurate and complete =
characterization
of these is the constraints on the trust =
anchors.

<=
/p>

the border between roles, =
peoples and
machines are getting more and more virtual and dynamic and it becomes =
harder
and harder to reduce this into one generic, intrusive and centrally =
managed TA
management protocol.

[Santosh] One would think that as things become more =
virtual
and dynamic, more you need the associated data with the TA and TAMP that =
can
enforce the constraints on the TA and on the associated =
data.

<=
/p>

Let me take a few examples from =
the requirements:

·         =
The assumed roles and =
authorization
model

·         =
The assumption that =
there exist
clearly identifiable TA stores.

<=
/p>

The TA requirements are =
assuming a TA
manager responsible for a TA store.

[Santosh] While operationally this may be one manager
managing the TA store, the requirements and TAMP should be oriented =
towards
many to many.  A TA manager can manage one or more TA in the TA =
store.  A
TA in a TA store can be managed by more that one =
manager.

<=
/p>

The TA manager have =
authority over
this TA store and have the power update it or replace it. This also =
assumes
that each TA store is individually identifiable in the protocol itself. =
In my
environment above, I first of all don’t have any isolated
identifiable TA stores.

[Santosh] The TA need not be in a specific store, but =
it is
always identifiable by some combination of name, SPKI, and SKID. =

<=
/p>

Secondly I don’t have a =
clearly
defined TA manager that has the right to view and update this =
information on a
local machine.

[Santosh] The TA requirements and TAMP should clarify =
this
with the constraints on the TAs.

<=
/p>

The applications or services =
that
eventually are being affected by these trust policy updates will not =
have a
clue about what information that was passed in any TA management =
protocol, or
any IETF defined TA format file several layers and APIs below their =
existence.

[Santosh] Agree and the applications do not do this. =
This
is part of TA management and not part of applications using the =
TA.

<=
/p>

So any discussion about how =
applications
should take into account specific path processing preferences provided =
by
passing TA format information around, such as applying specific =
constraints
rules, is just pretty theory without substance unless it is made part of
standard RFC 5280 path processing and implemented in the APIs for path
validation.

[Santosh] The TA requirements in the area of path =
processing
are consistent with 5280.  5280 specifically cites additional =
checks based
on the  information associated with TA.  See section 6.2 of =
5280.

<=
/p>

In the environment I’m =
working
with, I have no use for a transaction based TA management protocol based =
on the
simplified relationship between a TA manager and a TA store. =

[Santosh] That does not mean others do not need it. =
It
also does not mean that the environment you cited above would not =
benefit from
in-band re-key of the TA.

<=
/p>

If I had one, I would not know =
how to
use it.

The only thing I would know how =
to use,
is the TA format specification. That one I can use to pass TAs around in =
my
existing trust policy framework.

[Santosh] You as a person will need not be aware of =
it, just
like many of nuances of PKI.  The processing software will securely
process the transactions and update the TAs.

<=
/p>

I hope this was a useful =
clarification
and my apology for passing graphics in a PKIX posting. I hope you can =
view it.

[Santosh] The primary purpose of TA work is to permit =
in
band, secure installation and rekey of TAs.  Unless you propose an
alternative mechanism to achieve this securely, the discourse you are =
having is
not providing any critique of the TA work.

<=
/p>

<=
/p>

Stefan
Santesson

Senior =
Program Manager

Windows
Security, Standards

<=
/p>

From: =
[email-masked]
[mailto:[email-masked]] On
Behalf Of Kemp, David P.

Sent: den 16 december =
2008 18:12

To: [email-masked]

Subject: RE: TA =
requirements doc -
do we need it?

Stefan,=

<=
/p>

Refining the requirements as a =
series of
I-Ds until “the scope of the requirements is in harmony with =
problem
space”, then publishing as an RFC once the requirements have =
converged,
certainly sounds like the best approach.

<=
/p>

But you have not explained how =
“The
requirements are radically different in a device oriented environment =
with
disconnected units compared with a centrally managed IT environment with =
a
common network and data sharing infrastructure.”  The requirements in =
either case are
for managed devices/applications/services to receive configuration items =
from
managers without those items being compromised in transit, =
yes?

<=
/p>

·         =
Are you claiming that =
adversaries
have no access to a “common network and data sharing
infrastructure” and therefore no protection is needed in the =
networked
case?  That is patently false for all networks of interest to the =
IETF.

·         =
Or that the protection =
mechanisms
appropriate for managing networked platforms (Connection-oriented?  =
MACs?)
are different than those needed for managing disconnected platforms
(Datagram/message-oriented? Signatures?)

<=
/p>

Without understanding the =
nature of your
objections it’s hard to tell whether the scope of the requirements =
is
already in harmony with the entire problem space or not.   =
Your
4-quadrant slide from Minneapolis is not self-explanatory – I =
thought we
had already disposed of the push-pull issue by determining that there is =
no
security-relevant difference between posting to a repository from which =
a
client may pull and pushing directly to the client.  Therefore the =
TAM
requirements already cover the left half of the space.  If there is =
a
single existing TAM requirement that precludes pull, or a single missing =
TAM
requirement needed for pull, please provide an =
example.

<=
/p>

And I need help understanding =
the
difference you see between TA and TA Policy – if policy is
“Host/App A will trust provider X for security critical firmware =
category
Z”, and the TA store of Host/App A has provider X’s TA in =
the slot
for firmware category Z, what is the difference, other than level of
abstraction, between “determine current TAs in store” and
“demonstrate compliance with policy”?  Again, an =
example of a
missing TAM requirement needed to satisfy the right half of your slide =
would go
a long way toward understanding the scope =
issue.

<=
/p>

Dave

<=
/p>

<=
/p>

<=
/p>

From:
[email-masked] [mailto:[email-masked]] =
On Behalf Of Stefan Santesson

Sent: Tuesday, December =
16, 2008
9:58 AM

To: Santosh
Chokhani; [email-masked]

Subject: RE: TA =
requirements doc -
do we need it?

Hi =
Santosh,

<=
/p>

As I expect, I sense that we =
have a
slightly different view of the generality of the proposed solution, but =
we seem
to agree on the main issue:

<=
/p>

The
question one have to ask is if these requirements, in the form of an =
RFC, would
serve us as a community if we encounter a problem with the proposed =
protocol. I
doubt that it will as it at most will strengthen the argument for those =
having
an interest to adopt the original protocol.

[Santosh] Having a requirements document that is a =
living
document, permits us to evaluate various solutions and protocols. =
If we
do encounter a security problem, it should be useful to analyze where =
the
engineering process failed, e.g., did we not articulate some =
requirement, did
we not have sufficient detail for a requirement, did our analysis of =
protocol
meeting a requirement was flawed, etc.

<=
/p>

I would also prefer to see the
requirements document as a living document as you suggest. I think that =
purpose
is best served if the requirements document remains in draft =
form.

<=
/p>

<=
/p>

<=
/p>

Stefan
Santesson

Senior =
Program Manager

Windows
Security, Standards

<=
/p>

From:
[email-masked] [mailto:[email-masked]] =
On Behalf Of Santosh
Chokhani

Sent: den 15 december =
2008 17:47

To: Stefan Santesson;
[email-masked]

Subject: RE: TA =
requirements doc -
do we need it?

Stefan,
=

See my responses in-line below. =

From:
[email-masked] [mailto:[email-masked]] =
On Behalf Of Stefan Santesson

Sent: Friday, December =
12, 2008
7:25 AM

To: [email-masked]

Subject: TA requirements =
doc - do
we need it?

After
all discussions in Minneapolis
and going back and looking at the current situation, I feel less and =
less
convinced that we need to approve any TA requirements document as an =
RFC. At
least not in its current form.

I’m
fine with having it around as a draft for reference, but I fear it may =
be a lot
more harmful than beneficiary to us as an =
RFC.

I
have two major reasons:

First,
as I have argued and tried to explain with my slide in Minneapolis, there is no general =
overall
approach to TA management in a complex IT =
environment.

[Santosh] In a complex distributed environment that =
needs to
scale across Enterprises, applying requisite security services to the =
payload
provides a scalable, interoperable, extensible, and secure =
solution.

The
requirements are radically different in a device oriented environment =
with
disconnected units compared with a centrally managed IT environment with =
a
common network and data sharing =
infrastructure.

[Santosh] The requirements are generally the same in =
terms
of security services.  Some Enterprise IT
management implementations may have implemented Enterprise
specific solutions taking advantages of existing infrastructure and =
security
services provided by the Enterprise
network.  But, that solution may not be as scalable or =
open.

Secondly,
the requirements didn’t come first. These requirements were =
written with
an existing protocol in mind. The lasting impression is therefore that =
the
requirements document was written to match and support the original =
protocol,
making it a tool to grandfather the original protocol into IETF. =
I’m not
claiming that this is the case, but it remains to be my =
impression.

[Santosh] If you look at many of the engineering =
endeavors
we undertake, requirements are based on past experience, security
vulnerabilities we have encountered, past systems, etc.  I do not =
know of
many successful efforts where requirements were developed in vacuum. In =
short,
it is fair to say that the requirements and protocol benefited from each =
other
and from past experiences with protocols and =
vulnerabilities.

The
question one have to ask is if these requirements, in the form of an =
RFC, would
serve us as a community if we encounter a problem with the proposed =
protocol. I
doubt that it will as it at most will strengthen the argument for those =
having
an interest to adopt the original protocol.

[Santosh] Having a requirements document that is a =
living
document, permits us to evaluate various solutions and protocols. =
If we
do encounter a security problem, it should be useful to analyze where =
the
engineering process failed, e.g., did we not articulate some =
requirement, did
we not have sufficient detail for a requirement, did our analysis of =
protocol
meeting a requirement was flawed, etc.

My
proposal going forward is to do the =
following:

-
In any case adjust the scope of the requirements document =
to
reflect the problem space the problem space it is designed =
for.

-
Leave it as a draft, or at least not publish it as an RFC =
before
the scope is in harmony with the requirements.

Stefan
Santesson

Senior =
Program Manager

Windows
Security, Standards

------_=_NextPart_001_01C967E6.7A3B5275--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBOJFZYk016887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Dec 2008 12:15:35 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBOJFZ9Y016884; Wed, 24 Dec 2008 12:15:35 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBOJFMd1016857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Dec 2008 12:15:33 -0700 (MST) (envelope-from [email-masked])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mBOJFARG009894; Wed, 24 Dec 2008 14:15:10 -0500
Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBOJFJlC197854; Wed, 24 Dec 2008 14:15:19 -0500
Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id mBOJFJPr026105; Wed, 24 Dec 2008 14:15:19 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id mBOJFIoj026095; Wed, 24 Dec 2008 14:15:18 -0500
In-Reply-To: <[email-masked]>
To: [email-masked]
Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , [email-masked], [email-masked], [email-masked]
MIME-Version: 1.0
Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin
Message-ID:
Date: Wed, 24 Dec 2008 14:15:17 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/24/2008 14:15:18, Serialize complete at 12/24/2008 14:15:18
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

ICAgICAgICBKb2huOg0KDQogICAgICAgIFRoaXMgZHJhZnQgaXMgaW50ZXJlc3RpbmcgYW5kIHVz
ZWZ1bCBmb3Igc29tZSBwdXJwb3NlcywgYnV0IEkgDQpkb24ndCBzZWUgaG93IGl0IGFkZHJlc3Nl
cyB0aGUgY2FzZSB3aGVyZSBhIGhpZ2gtbGV2ZWwgYXJjIChiZXlvbmQgdGhlIA0KY29udHJvbCBv
ZiB0aGUgZGV2ZWxvcG1lbnQgb3JnYW5pemF0aW9uKSBpcyByZW5hbWVkLiAgU2luY2UgdGhhdCdz
IA0KcHJlY2lzZWx5IHRoZSBjYXNlIHdlIGFyZSBkaXNjdXNzaW5nIGhlcmUgKGFsdGhvdWdoIHRo
ZSBjaGFuZ2UgdG9vayBwbGFjZSANCnF1aXRlIGEgd2hpbGUgYWdvIGFuZCBpdCdzIHJlYXNvbmFi
bGUgdG8gZXhwZWN0IHBlb3BsZSB0byBhZGp1c3QpLCBpdCANCmRvZXNuJ3QgYWN0dWFsbHkgc2Vl
bSB0byBoZWxwIHVzLiAgQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCiAgICAgICAgQWxzbywgdW5s
ZXNzIEkgaGF2ZSBtaXNzZWQgc29tZXRoaW5nLCB0aGVyZSBhcmUgb25seSB0aHJlZSANCnRvcC1s
ZXZlbCBhcmNzIGRlZmluZWQgZm9yIE9JRCdzIGFuZCB0aGV5IGFsbCBub3cgaGF2ZSBuYW1lcy4N
Cg0KICAgICAgICAgICAgICAgIFRvbSBHaW5kaW4NCg0KDQoNCg0KSm9obiBMYXJtb3V0aCA8ai5s
YXJtb3V0aEBidGludGVybmV0LmNvbT4gDQpTZW50IGJ5OiBvd25lci1pZXRmLXBraXhAbWFpbC5p
bWMub3JnDQoxMi8yMi8yMDA4IDEwOjQ4IEFNDQpQbGVhc2UgcmVzcG9uZCB0bw0Kai5sYXJtb3V0
aEBidGludGVybmV0LmNvbQ0KDQoNClRvDQpBbGZyZWQg77+9IDxhaEB0ci1zeXMuZGU+DQpjYw0K
dHVybmVyc0BpZWNhLmNvbSwgaWV0Zi1wa2l4QGltYy5vcmcsIGlldGYtc21pbWVAaW1jLm9yZw0K
U3ViamVjdA0KUmU6IGNvbnNpc3RlbiB1c2Ugb2YgdG9wLWxldmVsIG9pZCBicmFuY2ggbmFtZSBq
b2ludC1pc28taXR1LXQoMikNCg0KDQoNCg0KDQoNCkFsZnJlZCwNCg0KVGhlIHN5bm9ueW1zIHdl
cmUgaW50cm9kdWNlZCBzb21lIHRpbWUgYWdvLCBhbmQsIGluZGVlZCwgdGhlIG5hbWVzIGFyZSAN
Cm5vbi1ub3JtYXRpdmUsIGFuZCBtYXkgbm90IGV2ZW4gYmUgdW5hbWJpZ3VvdXMuICBPbmx5IHRo
ZSBudW1iZXJzIG1hdHRlciANCmluIGFuIE9JRCBpbiBhbiBlbmNvZGluZy4NCg0KSG93ZXZlciwg
dGhlIHJlY2VudCBpbnRyb2R1Y3Rpb24gb2YgVW5pY29kZSBsYWJlbHMsIGFzIG5vcm1hdGl2ZSBh
bmQgDQp1bmFtYmlnb3VzIG5hbWVzIGdpdmVzIGEgbmV3IG5hbWluZyBzY2hlbWUgdG8gdGhlIChz
YW1lKSBPSUQgdHJlZSB0aGF0IA0KZW5hYmxlcyBuYW1lcyAoVW5pY29kZSBsYWJlbHMpIHRvIGJl
IHVzZWQgaW4gbWFjaGluZSBjb21tdW5pY2F0aW9uIGlmIA0KZGVzaXJlZC4gIFRoZSBBU04uMSB0
eXBlIGlzIGNhbGxlZCBPSURfSVJJIGFuZCBwcm92aWRlcyBmb3Igbm9kZSANCmlkZW50aWZpY2F0
aW9uIHVzaW5nIFVuaWNvZGUgbGFiZWxzLiAgVW5pY29kZSBsYWJlbHMgd2l0aCBuYW1lcyBzaW1p
bGFyIHRvIA0KdGhlIG9sZCBBU0NJSSBuYW1lcyBoYXZlIGJlZW4gYXNzaWduZWQgZm9yIG1hbnkg
b2YgdGhlIHRvcC1sZXZlbCBhcmNzLCBhbmQgDQptb3JlIHdpbGwgYmUgYWRkZWQgb3ZlciB0aW1l
Lg0KDQpUaGUgT0lEX0lSSSB0eXBlICBpcyByZWxhdGVkIHRvIChidXQgbm90IGRlcGVuZGVudCBv
bikgdGhlIGFwcGxpY2F0aW9uIGZvciANCmFuICJvaWQiIElSSSBzY2hlbWUsICBidXQgZm9yIGNv
bnNpc3RlbmN5IHRoaXMgaXMgZGVzaXJlZC4gIFNlZSBJLUQgDQpkcmFmdC1sYXJtb3V0aC1vaWQt
aXJpLTAwLg0KDQpKb2huIEwNCg0KQWxmcmVkIO+/vSB3cm90ZTogDQpGb2xrcyAvIHRvIHdob20g
aXQgY29uY2VybnMsDQoNCmR1cmluZyByZWNlbnQgcmV2aWV3cyBvZiBhY3RpdmUgSS1EcyBjb250
YWluaW5nIEFTTi4xIHJlbGF0ZWQNCnRvIHRoZSBYLjUwMCBmcmFtZXdvcmssIEkgZm91bmQgdGhh
dCBhIGNvdXBsZSBvZiB0aGVzZSBkbyBub3QNCmNvbnNpc3RlbnRseSBlbXBsb3kgdGhlIHJldmlz
ZWQgbmFtZSBvZiB0aGUgdG9wLWxldmVsIE9JRCBicmFuY2gNCg0KICAgIGpvaW50LWlzby1pdHUt
dCgyKSAsDQoNCmJ1dCBpbnN0ZWFkIHVzZSB0aGUgb3V0ZGF0ZWQvbGVnYWN5IG5hbWUNCg0KICAg
IGpvaW50LWlzby1jY2l0dCgyKSAuDQoNClNvbWUgZHJhZnRzIHVzZSBhIG1peCBvZiBib3RoIG5h
bWVzLg0KDQpJIHN1Z2dlc3QgdGhhdCB0aGUgbW9kZXJuIHZlcnNpb24gIGpvaW50LWlzby1pdHUt
dCgyKSAgYmUgdXNlZA0KY29uc2lzdGVudGx5IHdpdGhpbiBhbGwgbmV3IGRyYWZ0cyAvIGRyYWZ0
IHZlcnNpb25zLCB1bmxlc3MNCmludGVudGlvbmFsbHkgYW5kIGV4cGxpY2l0ZWx5IGZvciBoaXN0
b3JpY2FsIGV2aWRlbmNlIHJlZmVyZW5jZQ0KaGFzIHRvIGJlIG1hZGUgdG8gdGhlIG9sZCBuYW1l
Lg0KDQpLaW5kIHJlZ2FyZHMsDQogIEFsZnJlZC4NCg0KIA0KDQotLSANCiAgIFByb2YgSm9obiBM
YXJtb3V0aA0KICAgTGFybW91dGggVCZQRFMgTHRkDQogICAoVHJhaW5pbmcgYW5kIFByb3RvY29s
IERlc2lnbiBTZXJ2aWNlcyBMdGQpDQogICAxIEJsdWViZXJyeSBSb2FkIA0KICAgQm93ZG9uICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGoubGFybW91dGhAYnRpbnRlcm5ldC5jb20NCiAg
IEFsdHJpbmNoYW0NCiAgIENoZXNoaXJlDQogICBXQTE0IDNMUyANCiAgIEVuZ2xhbmQNCiAgIFRl
bDogKzQ0IDE2MSA5MjggMTYwNQ0KDQoNCg==

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBNBCPA1081225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Dec 2008 04:12:25 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBNBCP7P081221; Tue, 23 Dec 2008 04:12:25 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp811.mail.ird.yahoo.com (smtp811.mail.ird.yahoo.com [217.146.188.71]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBNBCD5j081188 for ; Tue, 23 Dec 2008 04:12:23 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 19382 invoked from network); 23 Dec 2008 11:12:12 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=ZgjNwUWwaAPfQyogg8vHfLojoDj2f6PPl6jLyMT1LX+GOZgYVsd+zYVe1pstplrU7roUTsoWhQU7rM+hxAxtO3KVP5DSctcXkIPh3CNNymNj4/TAan4LVlRGK07rc8liEWhvwMooVHIdWKw5LD8yHCu2xqLJhg7WxlFKcO54JdA= ;
Received: from unknown (HELO ?192.168.1.67?) ([email-masked] with plain) by smtp811.mail.ird.yahoo.com with SMTP; 23 Dec 2008 11:12:12 -0000
X-YMail-OSG: vrgTfU8VM1mhkBOfr2CSHGEqUVui2P3Vnd3ljSE7EVqJa89BjIvhiI93Btn7MNC9fVMoUaSwuOrYO4OSMY882lno3YQrlrLp5P8jEjFTpTp_wFt6VP8hPxnFtyPN_Lx5ksOKw39eNumGWr57Q0Sw3cKgBLS2H37M3bNaMaCviyfwvDRRD0xxU_Y5r.Abk3_Lxf2L8VqTfMACOHM4ip3OB39LJI6k_diIJGQh
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Tue, 23 Dec 2008 11:12:12 +0000
From: John Larmouth
Reply-To: [email-masked]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: Paul Hoffman
CC: Alfred ? , [email-masked], [email-masked], [email-masked]
Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
References: <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: multipart/alternative; boundary="------------050009060805000700080909"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.
--------------050009060805000700080909
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Please note my use of "if desired" below. This presents an opportunity,
not a requirement.

Nothing has been removed from the old OID capability.

I agree that the use of Unicode labels has not been adopted by PKIX or
S/MIME (and may well never be), nor presented to them. However, unless
or until the "oid" IRI format is accepted by URI-review, it would be
premature for PKIX or SMIME to even consider it.

John L

Paul Hoffman wrote:

>At 3:48 PM +0000 12/22/08, John Larmouth wrote:
>
>
>>However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired.
>>
>>
>
>Note that this scheme has not been adopted by PKIX nor S/MIME, nor has it even been proposed to either of the working groups.
>
>
>
>>The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels.
>>
>>
>
>Paging Peter Gutmann....
>
>--Paul Hoffman, Director
>--VPN Consortium
>
>
>

--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Design Services Ltd)
1 Blueberry Road
Bowdon [email-masked]
Altrincham
Cheshire
WA14 3LS
England
Tel: +44 161 928 1605

--------------050009060805000700080909
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Please note my use of "if desired" below.  This presents an
opportunity, not a requirement.

Nothing has been removed from the old OID capability.

I agree that the use of Unicode labels has not been adopted by PKIX or
S/MIME (and may well never be), nor presented to them.  However, unless
or until the "oid" IRI format is accepted by URI-review, it would be
premature for PKIX or SMIME to even consider it.

John L

Paul Hoffman wrote:

At 3:48 PM +0000 12/22/08, John Larmouth wrote:

However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired.

Note that this scheme has not been adopted by PKIX nor S/MIME, nor has it even been proposed to either of the working groups.

The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels.

Paging Peter Gutmann....

--Paul Hoffman, Director
--VPN Consortium

--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Design Services Ltd)
1 Blueberry Road
Bowdon [email-masked]
Altrincham
Cheshire
WA14 3LS
England
Tel: +44 161 928 1605

--------------050009060805000700080909--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMKQ2sk044002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 13:26:02 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMKQ2O2044001; Mon, 22 Dec 2008 13:26:02 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMKPsKO043973 for ; Mon, 22 Dec 2008 13:26:01 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 30) id 2809B3A6AA0; Mon, 22 Dec 2008 12:26:02 -0800 (PST)
X-idtracker: yes
From: The IESG
To: IETF-Announce
Cc: Internet Architecture Board , RFC Editor , pkix mailing list , pkix chair
Subject: Protocol Action: 'Elliptic Curve Cryptography Subject Public Key Information' to Proposed Standard
Message-Id: <[email-masked]>
Date: Mon, 22 Dec 2008 12:26:02 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

The IESG has approved the following document:

- 'Elliptic Curve Cryptography Subject Public Key Information '
as a Proposed Standard

This document is the product of the Public-Key Infrastructure (X.509)
Working Group.

The IESG contact persons are Pasi Eronen and Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-11.txt

Technical Summary

The subjectPublicKeyInfo field of an X.509 certificate carries
three data items: an algorithm identifier, optional parameters, and
a bit string that represents the public key. The parameters are
specific to the algorithm and this field usually contains simple
values needed to characterize the public key algorithm, e.g., the
generator and modulus for Diffie-Hellman. However, X.509 does not
constrain the scope of this parameters field. The ANSI X9.62
standards allow parameters to name the curve via an object
identifier, inherit the curve from an issuer, or fully specify the
curve. To fully specify the curve a complex structure is required.
Further, the ANSI X9.62 standards committee elected to use this
field to express potentially complex limitations on how the public
key in the certificate can be used, e.g., which key derivation
functions can be applied to the bit string that results from a
Diffie-Hellman key exchange.

After considerable debate the PKIX WG decided to limit the number
of parameter choices to one: the name the curve with an object
identifier (namedCurve). This decision was based on implementers
desire to use well known curves from NIST and the complexity of the
specifiedCurve field (not to mention the 20+ pages it saved).

The WG also decided to restrict the number of algorithm identifiers
to three: id-ecPublicKey, id-ecDH, and id-ECMQV. The
id-ecPublicKey object identifier is when a CA does not want to
limit the key for use with a particular ECC algorithm. ECDSA will
use this object identifier, as it is already widely implemented.
The id-ecDH and id-ecMQV object identifiers are used to restrict
the key for use with ECDH and ECMQV, respectively.

The SHA-224, SHA-256, SHA-384, and SHA-512 algorithms and the NIST
curves were added to the ASN.1 modules.

Working Group Summary

This ID was discussed extensively on the PKIX WG mailing list. A
poll was taken to remove the specifiedCurve option. The WG was in
favor of the change. The other comments were about document
quality.

Document Quality

This document is a fairly length update of three sections of RFC
3279 (Sections 2.3.5, 3, and 5) and includes a long ASN.1 module.
The quality of the draft is comparable in quality to its predecessor

Personnel

The document shepherd is Stefan Santesson. The responsible
area director is Pasi Eronen.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMHxrJd037374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 10:59:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMHxrBG037373; Mon, 22 Dec 2008 10:59:53 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMHxrgB037367 for ; Mon, 22 Dec 2008 10:59:53 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id 44D393A6A56; Mon, 22 Dec 2008 10:00:01 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-3281update-03.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Mon, 22 Dec 2008 10:00:01 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

Title : An Internet Attribute Certificate Profile for Authorization
Author(s) : R. Housley, S. Farrell, S. Turner
Filename : draft-ietf-pkix-3281update-03.txt
Pages : 45
Date : 2008-12-22

This specification defines a profile for the use of X.509 Attribute
Certificates in Internet Protocols. Attribute certificates may be
used in a wide range of applications and environments covering a
broad spectrum of interoperability goals and a broader spectrum of
operational and assurance requirements. The goal of this document is
to establish a common baseline for generic applications requiring
broad interoperability as well as limited special purpose
requirements. The profile places emphasis on attribute certificate
support for Internet electronic mail, IPSec, and WWW security
applications. This document obsoletes RFC 3281.

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

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

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

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

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

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMGow4d034237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 09:50:58 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMGowgI034236; Mon, 22 Dec 2008 09:50:58 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMGon8p034216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 09:50:50 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Mon, 22 Dec 2008 08:50:47 -0800
To: [email-masked], Alfred ?
From: Paul Hoffman
Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
Cc: [email-masked], [email-masked], [email-masked]
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 3:48 PM +0000 12/22/08, John Larmouth wrote:
>However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired.

Note that this scheme has not been adopted by PKIX nor S/MIME, nor has it even been proposed to either of the working groups.

>The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels.

Paging Peter Gutmann....

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMFmORn029597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 08:48:34 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMFmO90029594; Mon, 22 Dec 2008 08:48:24 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp816.mail.ird.yahoo.com (smtp816.mail.ird.yahoo.com [77.238.189.16]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBMFmBgA029575 for ; Mon, 22 Dec 2008 08:48:23 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 20008 invoked from network); 22 Dec 2008 15:48:10 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=tQkoL9owhPwHWzOzbPimY2Dt9JLv9nU5CWYe5StO2PIWznWDtp9LPE29yxgnkSh5p8FCRwMbeYsCDH0gIdW6yYtovDwrpS3BpGS1jCw403OGtrbrc9pUWokxAf3jy0SmO3OIR/qUTkI8GHgcJXuL/In61WOVFOZ+PzzhYby+X1U= ;
Received: from unknown (HELO ?192.168.1.67?) ([email-masked] with plain) by smtp816.mail.ird.yahoo.com with SMTP; 22 Dec 2008 15:48:10 -0000
X-YMail-OSG: Rhsm3igVM1nRvqWJciSouoY2o6CT9wZveZw3YFTc9fQIuZHvz7kL1MGbOApNbshcIfLe78WzVfRaVJspyziFxx2Xc10jC7vH5WxKe_96btpwxv4OEbQEtxiUo5SZVvvIcA.aMYmWsReum7fstMynnnCtCoEmr.C8ANenOiYBqSp.Hy2stujeRFiUsQ1X61Yo
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Mon, 22 Dec 2008 15:48:10 +0000
From: John Larmouth
Reply-To: [email-masked]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: =?UTF-8?B?QWxmcmVkIO+/vQ==?=
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/alternative; boundary="------------060306020603010708080909"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.
--------------060306020603010708080909
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Alfred,

The synonyms were introduced some time ago, and, indeed, the names are
non-normative, and may not even be unambiguous. Only the numbers matter
in an OID in an encoding.

However, the recent introduction of Unicode labels, as normative and
unambigous names gives a new naming scheme to the (same) OID tree that
enables names (Unicode labels) to be used in machine communication if
desired. The ASN.1 type is called OID_IRI and provides for node
identification using Unicode labels. Unicode labels with names similar
to the old ASCII names have been assigned for many of the top-level
arcs, and more will be added over time.

The OID_IRI type is related to (but not dependent on) the application
for an "oid" IRI scheme, but for consistency this is desired. See I-D
draft-larmouth-oid-iri-00.

John L

Alfred � wrote:

>Folks / to whom it concerns,
>
>during recent reviews of active I-Ds containing ASN.1 related
>to the X.500 framework, I found that a couple of these do not
>consistently employ the revised name of the top-level OID branch
>
> joint-iso-itu-t(2) ,
>
>but instead use the outdated/legacy name
>
> joint-iso-ccitt(2) .
>
>Some drafts use a mix of both names.
>
>I suggest that the modern version joint-iso-itu-t(2) be used
>consistently within all new drafts / draft versions, unless
>intentionally and explicitely for historical evidence reference
>has to be made to the old name.
>
>Kind regards,
> Alfred.
>
>
>

--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Design Services Ltd)
1 Blueberry Road
Bowdon [email-masked]
Altrincham
Cheshire
WA14 3LS
England
Tel: +44 161 928 1605

--------------060306020603010708080909
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

Alfred,

The synonyms were introduced some time ago, and, indeed, the names are
non-normative, and may not even be unambiguous.  Only the numbers
matter in an OID in an encoding.

However, the recent introduction of Unicode labels, as normative and
unambigous names gives a new naming scheme to the (same) OID tree that
enables names (Unicode labels) to be used in machine communication if
desired.  The ASN.1 type is called OID_IRI and provides for node
identification using Unicode labels.  Unicode labels with names similar
to the old ASCII names have been assigned for many of the top-level
arcs, and more will be added over time.

The OID_IRI type  is related to (but not dependent on) the application
for an "oid" IRI scheme,  but for consistency this is desired.  See I-D
draft-larmouth-oid-iri-00.

John L

Alfred � wrote:

Folks / to whom it concerns,

during recent reviews of active I-Ds containing ASN.1 related
to the X.500 framework, I found that a couple of these do not
consistently employ the revised name of the top-level OID branch

joint-iso-itu-t(2) ,

but instead use the outdated/legacy name

joint-iso-ccitt(2) .

Some drafts use a mix of both names.

I suggest that the modern version joint-iso-itu-t(2) be used
consistently within all new drafts / draft versions, unless
intentionally and explicitely for historical evidence reference
has to be made to the old name.

Kind regards,
Alfred.

--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Design Services Ltd)
1 Blueberry Road
Bowdon [email-masked]
Altrincham
Cheshire
WA14 3LS
England
Tel: +44 161 928 1605

--------------060306020603010708080909--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMEalxR024585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 07:36:47 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMEalV8024583; Mon, 22 Dec 2008 07:36:47 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMEagXw024570; Mon, 22 Dec 2008 07:36:44 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA080886501; Mon, 22 Dec 2008 15:35:01 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA13232; Mon, 22 Dec 2008 15:34:56 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: Re: consistent use of top-level oid branch name joint-iso-itu-t(2)
To: [email-masked]
Date: Mon, 22 Dec 2008 15:34:56 +0100 (MEZ)
Cc: [email-masked], [email-masked], [email-masked]
In-Reply-To: <200812221358.AA080714339@w.> from Russ Housley at Dec "22," 2008 "08:33:51" am
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Russ,
thanks for your response.

> Alfred:
>
> This is a result of the name change from CCITT to ITU-T. So,
> different documents use different names depending on when they were
> published. The bits on the wire are not impacted, so I have never
> worried about it.
>
> Russ

I am fully aware of the history, but that change is back quite
a couple of years now. IIRC, that must have been more than 15 years
ago; in particular, the X.680 1994 Edition (== ISO/IEC 8824-1:1995)
already specified the new name(s) as the primary identifier(s).

My arguments are primarily:

o avoiding possible confusion;

o making new documents easier to read for newcomers not aware
of the history of the ITU-T;

o self-consistency within new documents (a major goal of RFC Editor
policy);

o consistency within the set of related document revisions
currently in progress;

o using current terminology and names in new documents;

o referring to the new name when making citations of the X.680
series of IUT-T Recommendations (and that's the way SMIME and
PKIX are moving forward).

Kind regards,
Alfred.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBME0eMV022581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 07:00:40 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBME0eRF022579; Mon, 22 Dec 2008 07:00:40 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBME0S1G022564 for ; Mon, 22 Dec 2008 07:00:38 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 3615 invoked from network); 22 Dec 2008 14:00:25 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 22 Dec 2008 14:00:25 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 22 Dec 2008 08:33:51 -0500
To: Alfred =?hp-roman8?B?SM5uZXM=?=
From: Russ Housley
Subject: Re: consistent use of top-level oid branch name joint-iso-itu-t(2)
Cc: [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Alfred:

This is a result of the name change from CCITT to ITU-T. So,
different documents use different names depending on when they were
published. The bits on the wire are not impacted, so I have never
worried about it.

Russ

At 07:56 AM 12/22/2008, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:

>Folks / to whom it concerns,
>
>during recent reviews of active I-Ds containing ASN.1 related
>to the X.500 framework, I found that a couple of these do not
>consistently employ the revised name of the top-level OID branch
>
> joint-iso-itu-t(2) ,
>
>but instead use the outdated/legacy name
>
> joint-iso-ccitt(2) .
>
>Some drafts use a mix of both names.
>
>I suggest that the modern version joint-iso-itu-t(2) be used
>consistently within all new drafts / draft versions, unless
>intentionally and explicitely for historical evidence reference
>has to be made to the old name.
>
>Kind regards,
> Alfred.
>
>--
>
>+------------------------+--------------------------------------------+
>| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
>| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
>| D-71254 Ditzingen | E-Mail: [email-masked] |
>+------------------------+--------------------------------------------+

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMCvv5i018746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 05:57:57 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMCvvoO018744; Mon, 22 Dec 2008 05:57:57 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMCvhUl018724; Mon, 22 Dec 2008 05:57:55 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA080420566; Mon, 22 Dec 2008 13:56:06 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA13071; Mon, 22 Dec 2008 13:56:05 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: consisten use of top-level oid branch name joint-iso-itu-t(2)
To: [email-masked], [email-masked], [email-masked]
Date: Mon, 22 Dec 2008 13:56:04 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Folks / to whom it concerns,

during recent reviews of active I-Ds containing ASN.1 related
to the X.500 framework, I found that a couple of these do not
consistently employ the revised name of the top-level OID branch

joint-iso-itu-t(2) ,

but instead use the outdated/legacy name

joint-iso-ccitt(2) .

Some drafts use a mix of both names.

I suggest that the modern version joint-iso-itu-t(2) be used
consistently within all new drafts / draft versions, unless
intentionally and explicitely for historical evidence reference
has to be made to the old name.

Kind regards,
Alfred.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: [email-masked] |
+------------------------+--------------------------------------------+

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMCtLQn018637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 05:55:21 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMCtLTM018636; Mon, 22 Dec 2008 05:55:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMCt2gN018622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Dec 2008 05:55:20 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.1.102] (dslstat-77-ppp-125.fastq.com [65.39.77.125] (may be forged)) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id mBMCqlCQ027942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Dec 2008 05:53:43 -0700
Cc: [email-masked]
Message-Id: <[email-masked]>
From: Michael Myers
To: Stephen Kent
In-Reply-To:
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: straw poll
Date: Mon, 22 Dec 2008 05:51:02 -0700
References:
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

1. yes

2. yes

Mike

On Dec 16, 2008, at 7:29 AM, Stephen Kent wrote:

>
> At a previous IETF meeting (Dublin) I agreed to conduct a straw poll
> on adding a new WG item to address OCSP algorithm agility concerns,
> after PHB sent a message indicating what status he envisioned for
> the work. This action for both me and PHB fell through the cracks.
> At the MSP IETF meeting PHB provided a briefing on the problems that
> he saw re OCSP ambiguities re algorithm agility, and proposed a
> standards track document to address these issues (see PHB's message
> of 12/2).
>
> So, we now have a concrete proposal (draft-hallambaker-ocspagility)
> available for review. PHB would like to publish this and then merge
> it into the OCSP document when it progresses from PROPOSED to DRAFT
> (see his message of 12/2).
>
> Please send a message to the list by January 9th (allowing for
> holiday outages) indicating whether
>
> 1. your support PKIX work in this area
> 2. you support adopting PHB's document as a starting point for such
> work
>
> Thanks & Happy Hoplidays,
>
> Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBLI2bAb069859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Dec 2008 11:02:37 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBLI2bc5069858; Sun, 21 Dec 2008 11:02:37 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBLI2QJm069851 for ; Sun, 21 Dec 2008 11:02:37 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 17156 invoked from network); 21 Dec 2008 18:02:20 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 21 Dec 2008 18:02:20 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sun, 21 Dec 2008 12:27:36 -0500
To:
From: Russ Housley
Subject: RE: straw poll
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

1. Yes
2. Yes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: Tuesday, December 16, 2008 9:29 AM
To: [email-masked]
Subject: straw poll

At a previous IETF meeting (Dublin) I agreed to conduct a straw poll
on adding a new WG item to address OCSP algorithm agility concerns,
after PHB sent a message indicating what status he envisioned for the
work. This action for both me and PHB fell through the cracks. At the
MSP IETF meeting PHB provided a briefing on the problems that he saw
re OCSP ambiguities re algorithm agility, and proposed a standards
track document to address these issues (see PHB's message of 12/2).

So, we now have a concrete proposal (draft-hallambaker-ocspagility)
available for review. PHB would like to publish this and then merge
it into the OCSP document when it progresses from PROPOSED to DRAFT
(see his message of 12/2).

Please send a message to the list by January 9th (allowing for
holiday outages) indicating whether

1. your support PKIX work in this area
2. you support adopting PHB's document as a starting point
for such work

Thanks & Happy Holidays,

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBJIxsIK054686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2008 11:59:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBJIxsQF054685; Fri, 19 Dec 2008 11:59:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBJIxsUa054679 for ; Fri, 19 Dec 2008 11:59:54 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id 4E1CA3A6906; Fri, 19 Dec 2008 11:00:00 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-tac-02.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Fri, 19 Dec 2008 11:00:01 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

Title : Traceable Anonymous Certificate
Author(s) : S. Park, H. Park, Y. Won, J. Lee, S. Kent
Filename : draft-ietf-pkix-tac-02.txt
Pages : 34
Date : 2008-12-19

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

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

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

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

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

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

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

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIIbvoS089248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2008 11:37:57 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBIIbvA6089247; Thu, 18 Dec 2008 11:37:57 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBIIbj9G089219 for ; Thu, 18 Dec 2008 11:37:56 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 99910 invoked from network); 18 Dec 2008 18:37:45 -0000
Received: from unknown (HELO Wylie) ([email-masked] with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 18 Dec 2008 18:37:44 -0000
X-YMail-OSG: Havn4LwVM1l3S1zRHQ5eiGE0btx5mBjgb2lI3t2f0Pc53jzV7MUdQ7if48MyPzlvFjNnTHhfcNOHvpb0La7xa7MjEGFFOWoXJ8I6_5DiShFg9b_kJVJ.nv2ozzGe.731tnwCZDNHMC9d4WEUoJxBvg3q7qI78MaL2WgbdAzc9fva5Nf0DqyMaPttHW7ZjTe8.MUE3GVUQwETQeOWcHOkSddCEOc-
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P."
To: ,
References: <[email-masked]>
Subject: RE: AD review comments for draft-ietf-pkix-rfc4055-update-01
Date: Thu, 18 Dec 2008 13:37:19 -0500
Organization: IECA, Inc.
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AclhOURfo6N+b0JqRwyqq4U9konBCwABkvJA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
In-Reply-To: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

These look correct to me.

spt

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of
>[email-masked]
>Sent: Thursday, December 18, 2008 12:52 PM
>To: [email-masked]
>Subject: AD review comments for draft-ietf-pkix-rfc4055-update-01
>
>
>
>I've now reviewed draft-ietf-pkix-rfc4055-update-01, and it
>looks good. I have only one nit: the draft doesn't touch any
>of the parts related to PKCS#1 v1.5 signatures (RFC 4055 also
>specified OIDs for PKCS#1 v1.5 signatures with
>SHA-224/256/384/512), so I'd suggest the following edits:
>
>Abstract:
>OLD:
> It updates the conventions for using the RSA Encryption Scheme -
> Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport
> algorithm with the Public-Key Cryptography Standards (PKCS)
>#1 version
> 1.5 signature algorithm in the Internet X.509 Public Key
> Infrastructure (PKI).
>NEW:
> It updates the conventions for using the RSA Encryption Scheme -
> Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport
> algorithm in the Internet X.509 Public Key Infrastructure (PKI).
>
>Section 1:
>OLD:
> RFC 4055 specifies conventions for using the RSA Encryption
>Scheme -
> Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport
> algorithm with the Public-Key Cryptography Standards (PKCS) #1
> version 1.5 signature algorithm in the Internet X.509 Public Key
> Infrastructure (PKI).
>NEW:
> RFC 4055 specifies conventions for using the RSA Encryption
>Scheme -
> Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport
> algorithm in the Internet X.509 Public Key Infrastructure (PKI).
>
>
>Sean and others, do these look correct?
>
>Best regards,
>Pasi
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIHppEj086742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2008 10:51:51 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBIHppon086741; Thu, 18 Dec 2008 10:51:51 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIHpcBe086726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 18 Dec 2008 10:51:50 -0700 (MST) (envelope-from [email-masked])
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mBIHpY8Y010772 for ; Thu, 18 Dec 2008 19:51:36 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Dec 2008 19:51:34 +0200
Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Dec 2008 19:51:34 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AD review comments for draft-ietf-pkix-rfc4055-update-01
Date: Thu, 18 Dec 2008 19:51:34 +0200
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: AD review comments for draft-ietf-pkix-rfc4055-update-01
Thread-Index: AclhOURfo6N+b0JqRwyqq4U9konBCw==
From:
To:
X-OriginalArrivalTime: 18 Dec 2008 17:51:34.0375 (UTC) FILETIME=[444DCF70:01C96139]
X-Nokia-AV: Clean
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I've now reviewed draft-ietf-pkix-rfc4055-update-01, and it looks
good. I have only one nit: the draft doesn't touch any of the parts
related to PKCS#1 v1.5 signatures (RFC 4055 also specified OIDs=20
for PKCS#1 v1.5 signatures with SHA-224/256/384/512), so I'd=20
suggest the following edits:

Abstract:
OLD:=20
It updates the conventions for using the RSA Encryption Scheme -
Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport
algorithm with the Public-Key Cryptography Standards (PKCS) #1 =
version
1.5 signature algorithm in the Internet X.509 Public Key
Infrastructure (PKI).
NEW:
It updates the conventions for using the RSA Encryption Scheme -
Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport
algorithm in the Internet X.509 Public Key Infrastructure (PKI).

Section 1:
OLD:
RFC 4055 specifies conventions for using the RSA Encryption Scheme -=20
Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport=20
algorithm with the Public-Key Cryptography Standards (PKCS) #1=20
version 1.5 signature algorithm in the Internet X.509 Public Key=20
Infrastructure (PKI).
NEW:
RFC 4055 specifies conventions for using the RSA Encryption Scheme -=20
Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport=20
algorithm in the Internet X.509 Public Key Infrastructure (PKI).

Sean and others, do these look correct?

Best regards,
Pasi

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIGlNfP083413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2008 09:47:23 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBIGlNjY083412; Thu, 18 Dec 2008 09:47:23 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIGlAIx083401 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 18 Dec 2008 09:47:21 -0700 (MST) (envelope-from [email-masked])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 18 Dec 2008 16:47:09 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.54]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 18 Dec 2008 16:47:09 +0000
From: Stefan Santesson
To: "[email-masked]" , "Kemp, David P."
Date: Thu, 18 Dec 2008 16:47:13 +0000
Subject: FW: TA requirements doc - do we need it?
Thread-Topic: TA requirements doc - do we need it?
Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9AAC9gTrAAApWoQAAk2WagAEDwEFA=
Message-ID: <[email-masked]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AF3E6206DEAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

I'm resending this as my original mail got filtered due to exceeding pkix m=
essage size restrictions.
I have now replaced the embedded picture with a URL to the screenshot.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: Stefan Santesson
Sent: den 17 december 2008 11:43
To: 'Kemp, David P.'; [email-masked]
Subject: RE: TA requirements doc - do we need it?

Dave,

You raise valid points and I partly try to avoid them because the answer is=
somewhat long and complex. Long and complex answers are seldom successful =
in standards discussions :)

Let me try to show my point through a screenshot that helped explain this i=
ssue to at least one of the original contributors to the proposed protocol.=
This is a screenshot of the Microsoft certificate management snap-in:

http://www.fiddler.nu/pkix/certmgr_mmc.jpg

What you see here is the certificate trust policies in my laptop. It is not=
one root store and it is not just about trust anchors. In my laptop I have=
a certificate trust management snap-in for:

* Each host (local machine)

* Each user account

* Each service running on any host

In the Certificate snap-in window to the right, you see a fraction of the l=
ist of services with individual certificate trust settings for one host/mac=
hine.

And it is not about just TA:s. It is about:

* My personal certificates

* Trusted roots

* Intermediary CAs

* Directly trusted or untrusted certificates

* Etc, etc (See above)

The structure of this information is not globally agreed and generic. It is=
just how Microsoft have structured this in the Microsoft OS.

One could call this a set of certificate trust policies that are dynamicall=
y managed and as you get closer to reality, the border between roles, peopl=
es and machines are getting more and more virtual and dynamic and it become=
s harder and harder to reduce this into one generic, intrusive and centrall=
y managed TA management protocol.

Let me take a few examples from the requirements:

* The assumed roles and authorization model

* The assumption that there exist clearly identifiable TA stores.

The TA requirements are assuming a TA manager responsible for a TA store. T=
he TA manager have authority over this TA store and have the power update i=
t or replace it. This also assumes that each TA store is individually ident=
ifiable in the protocol itself. In my environment above, I first of all don=
't have any isolated identifiable TA stores. Secondly I don't have a clear=
ly defined TA manager that has the right to view and update this informatio=
n on a local machine.

The applications or services that eventually are being affected by these tr=
ust policy updates will not have a clue about what information that was pas=
sed in any TA management protocol, or any IETF defined TA format file sever=
al layers and APIs below their existence. So any discussion about how appli=
cations should take into account specific path processing preferences provi=
ded by passing TA format information around, such as applying specific cons=
traints rules, is just pretty theory without substance unless it is made pa=
rt of standard RFC 5280 path processing and implemented in the APIs for pat=
h validation.

In the environment I'm working with, I have no use for a transaction based =
TA management protocol based on the simplified relationship between a TA ma=
nager and a TA store.
If I had one, I would not know how to use it.
The only thing I would know how to use, is the TA format specification. Tha=
t one I can use to pass TAs around in my existing trust policy framework.

I hope this was a useful clarification and my apology for passing graphics =
in a PKIX posting. I hope you can view it.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On=
Behalf Of Kemp, David P.
Sent: den 16 december 2008 18:12
To: [email-masked]
Subject: RE: TA requirements doc - do we need it?

Stefan,

Refining the requirements as a series of I-Ds until "the scope of the requi=
rements is in harmony with problem space", then publishing as an RFC once t=
he requirements have converged, certainly sounds like the best approach.

But you have not explained how "The requirements are radically different in=
a device oriented environment with disconnected units compared with a cent=
rally managed IT environment with a common network and data sharing infrast=
ructure." The requirements in either case are for managed devices/applicat=
ions/services to receive configuration items from managers without those it=
ems being compromised in transit, yes?

* Are you claiming that adversaries have no access to a "common net=
work and data sharing infrastructure" and therefore no protection is needed=
in the networked case? That is patently false for all networks of interes=
t to the IETF.

* Or that the protection mechanisms appropriate for managing networ=
ked platforms (Connection-oriented? MACs?) are different than those needed=
for managing disconnected platforms (Datagram/message-oriented? Signatures=
?)

Without understanding the nature of your objections it's hard to tell wheth=
er the scope of the requirements is already in harmony with the entire prob=
lem space or not. Your 4-quadrant slide from Minneapolis is not self-expl=
anatory - I thought we had already disposed of the push-pull issue by deter=
mining that there is no security-relevant difference between posting to a r=
epository from which a client may pull and pushing directly to the client. =
Therefore the TAM requirements already cover the left half of the space. =
If there is a single existing TAM requirement that precludes pull, or a sin=
gle missing TAM requirement needed for pull, please provide an example.

And I need help understanding the difference you see between TA and TA Poli=
cy - if policy is "Host/App A will trust provider X for security critical f=
irmware category Z", and the TA store of Host/App A has provider X's TA in =
the slot for firmware category Z, what is the difference, other than level =
of abstraction, between "determine current TAs in store" and "demonstrate c=
ompliance with policy"? Again, an example of a missing TAM requirement nee=
ded to satisfy the right half of your slide would go a long way toward unde=
rstanding the scope issue.

Dave

From: [email-masked] [mailto:[email-masked]] On=
Behalf Of Stefan Santesson
Sent: Tuesday, December 16, 2008 9:58 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: TA requirements doc - do we need it?

Hi Santosh,

As I expect, I sense that we have a slightly different view of the generali=
ty of the proposed solution, but we seem to agree on the main issue:

The question one have to ask is if these requirements, in the form of an RF=
C, would serve us as a community if we encounter a problem with the propose=
d protocol. I doubt that it will as it at most will strengthen the argument=
for those having an interest to adopt the original protocol.
[Santosh] Having a requirements document that is a living document, permits=
us to evaluate various solutions and protocols. If we do encounter a secu=
rity problem, it should be useful to analyze where the engineering process =
failed, e.g., did we not articulate some requirement, did we not have suffi=
cient detail for a requirement, did our analysis of protocol meeting a requ=
irement was flawed, etc.

I would also prefer to see the requirements document as a living document a=
s you suggest. I think that purpose is best served if the requirements docu=
ment remains in draft form.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On=
Behalf Of Santosh Chokhani
Sent: den 15 december 2008 17:47
To: Stefan Santesson; [email-masked]
Subject: RE: TA requirements doc - do we need it?

Stefan,

See my responses in-line below.

________________________________
From: [email-masked] [mailto:[email-masked]] On=
Behalf Of Stefan Santesson
Sent: Friday, December 12, 2008 7:25 AM
To: [email-masked]
Subject: TA requirements doc - do we need it?

After all discussions in Minneapolis and going back and looking at the curr=
ent situation, I feel less and less convinced that we need to approve any T=
A requirements document as an RFC. At least not in its current form.
I'm fine with having it around as a draft for reference, but I fear it may =
be a lot more harmful than beneficiary to us as an RFC.

I have two major reasons:

First, as I have argued and tried to explain with my slide in Minneapolis, =
there is no general overall approach to TA management in a complex IT envir=
onment.
[Santosh] In a complex distributed environment that needs to scale across E=
nterprises, applying requisite security services to the payload provides a =
scalable, interoperable, extensible, and secure solution.

The requirements are radically different in a device oriented environment w=
ith disconnected units compared with a centrally managed IT environment wit=
h a common network and data sharing infrastructure.
[Santosh] The requirements are generally the same in terms of security serv=
ices. Some Enterprise IT management implementations may have implemented E=
nterprise specific solutions taking advantages of existing infrastructure a=
nd security services provided by the Enterprise network. But, that solutio=
n may not be as scalable or open.

Secondly, the requirements didn't come first. These requirements were writt=
en with an existing protocol in mind. The lasting impression is therefore t=
hat the requirements document was written to match and support the original=
protocol, making it a tool to grandfather the original protocol into IETF.=
I'm not claiming that this is the case, but it remains to be my impression=
.
[Santosh] If you look at many of the engineering endeavors we undertake, re=
quirements are based on past experience, security vulnerabilities we have e=
ncountered, past systems, etc. I do not know of many successful efforts wh=
ere requirements were developed in vacuum. In short, it is fair to say that=
the requirements and protocol benefited from each other and from past expe=
riences with protocols and vulnerabilities.

The question one have to ask is if these requirements, in the form of an RF=
C, would serve us as a community if we encounter a problem with the propose=
d protocol. I doubt that it will as it at most will strengthen the argument=
for those having an interest to adopt the original protocol.
[Santosh] Having a requirements document that is a living document, permits=
us to evaluate various solutions and protocols. If we do encounter a secu=
rity problem, it should be useful to analyze where the engineering process =
failed, e.g., did we not articulate some requirement, did we not have suffi=
cient detail for a requirement, did our analysis of protocol meeting a requ=
irement was flawed, etc.

My proposal going forward is to do the following:

- In any case adjust the scope of the requirements document to ref=
lect the problem space the problem space it is designed for.

- Leave it as a draft, or at least not publish it as an RFC before=
the scope is in harmony with the requirements.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

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

I’m resending this as my original mail got filtered due to e=
xceeding pkix
message size restrictions.

I have now =
replaced
the embedded picture with a URL to the screenshot.

=

=

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<=
span
lang=3DEN-US style=3D'color:#1F497D'>

=

From: Stefan Santesson

Sent: den 17 december 2008 11:43

To: 'Kemp, David P.'; [email-masked]

Subject: RE: TA requirements doc - do we need it?<=
/p>

Dave,<=
/p>

=

You raise v=
alid
points and I partly try to avoid them because the answer is somewhat long a=
nd
complex. Long and complex answers are seldom successful in standards
discussions J

=

Let me try =
to show my
point through a screenshot that helped explain this issue to at least one o=
f
the original contributors to the proposed protocol. This is a screenshot of=
the
Microsoft certificate management snap-in:

=

http://www.fiddler.nu/p=
kix/certmgr_mmc.jpg

=

What you se=
e here is
the certificate trust policies in my laptop. It is not one root store and i=
t is
not just about trust anchors. In my laptop I have a certificate trust
management snap-in for:

·      =

E=
ach host
(local machine)

·      =

E=
ach user
account

·      =

E=
ach
service running on any host

=

In the Cert=
ificate
snap-in window to the right, you see a fraction of the list of services wit=
h
individual certificate trust settings for one host/machine.

=

And it is n=
ot about
just TA:s. It is about:

·      =

M=
y
personal certificates

·      =

T=
rusted
roots

·      =

I=
ntermediary
CAs

·      =

D=
irectly
trusted or untrusted certificates

·      =

E=
tc, etc
(See above)

=

The structu=
re of this
information is not globally agreed and generic. It is just how Microsoft ha=
ve
structured this in the Microsoft OS.

=

One could c=
all this a
set of certificate trust policies that are dynamically managed and as you g=
et
closer to reality, the border between roles, peoples and machines are getti=
ng
more and more virtual and dynamic and it becomes harder and harder to reduc=
e
this into one generic, intrusive and centrally managed TA management protoc=
ol.

=

Let me take=
a few
examples from the requirements:

·      =

T=
he
assumed roles and authorization model

·      =

T=
he assumption
that there exist clearly identifiable TA stores.

=

The TA requ=
irements
are assuming a TA manager responsible for a TA store. The TA manager have
authority over this TA store and have the power update it or replace it. Th=
is
also assumes that each TA store is individually identifiable in the protoco=
l
itself. In my environment above, I first of all don’t have any isolat=
ed
identifiable TA stores. Secondly I don’t have a clearly defined=
TA
manager that has the right to view and update this information on a local
machine.

=

The applica=
tions or
services that eventually are being affected by these trust policy updates w=
ill
not have a clue about what information that was passed in any TA management
protocol, or any IETF defined TA format file several layers and APIs below
their existence. So any discussion about how applications should take into
account specific path processing preferences provided by passing TA format
information around, such as applying specific constraints rules, is just pr=
etty
theory without substance unless it is made part of standard RFC 5280 path
processing and implemented in the APIs for path validation.

=

In the envi=
ronment
I’m working with, I have no use for a transaction based TA management=
protocol
based on the simplified relationship between a TA manager and a TA store. <=
o:p>

If I had on=
e, I would
not know how to use it.

The only th=
ing I
would know how to use, is the TA format specification. That one I can use t=
o
pass TAs around in my existing trust policy framework.

=

I hope this=
was a useful
clarification and my apology for passing graphics in a PKIX posting. I hope=
you
can view it.

=

=

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<=
span
lang=3DEN-US style=3D'color:#1F497D'>

=

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: den 16 december 2008 18:12

To: [email-masked]

Subject: RE: TA requirements doc - do we need it?<=
/p>

Stefan,

=

Refining th=
e
requirements as a series of I-Ds until “the scope of the requirements=
is in
harmony with problem space”, then publishing as an RFC once the requi=
rements
have converged, certainly sounds like the best approach.<=
/p>

=

But you hav=
e not
explained how “The requirements are radical=
ly different
in a device oriented environment with disconnected units compared with a ce=
ntrally
managed IT environment with a common network and data sharing
infrastructure.”  The requirements=
in either
case are for managed devices/applications/services to receive configuration
items from managers without those items being compromised in transit, yes?<=
o:p>

=

·      =

A=
re you
claiming that adversaries have no access to a “common network and dat=
a sharing
infrastructure” and therefore no protection is needed in the networke=
d
case?  That is patently false for all networks of interest to the IETF=
.

·      =

O=
r that
the protection mechanisms appropriate for managing networked platforms
(Connection-oriented?  MACs?) are different than those needed for mana=
ging
disconnected platforms (Datagram/message-oriented? Signatures?)<=
/span>

=

Without und=
erstanding
the nature of your objections it’s hard to tell whether the scope of =
the
requirements is already in harmony with the entire problem space or
not.   Your 4-quadrant slide from Minneapolis is not self-explana=
tory
– I thought we had already disposed of the push-pull issue by determi=
ning that
there is no security-relevant difference between posting to a repository fr=
om
which a client may pull and pushing directly to the client.  Therefore=
the
TAM requirements already cover the left half of the space.  If there i=
s a
single existing TAM requirement that precludes pull, or a single missing TA=
M
requirement needed for pull, please provide an example.

=

And I need =
help
understanding the difference you see between TA and TA Policy – if po=
licy is
“Host/App A will trust provider X for security critical firmware cate=
gory Z”,
and the TA store of Host/App A has provider X’s TA in the slot for fi=
rmware
category Z, what is the difference, other than level of abstraction, betwee=
n
“determine current TAs in store” and “demonstrate complia=
nce with policy”?
Again, an example of a missing TAM requirement needed to satisfy the right =
half
of your slide would go a long way toward understanding the scope issue.

=

Dave

=

=

=

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson<=
br>
Sent: Tuesday, December 16, 2008 9:58 AM

To: Santosh Chokhani; [email-masked]

Subject: RE: TA requirements doc - do we need it?<=
/p>

Hi Santosh,

=

As I expect=
, I sense
that we have a slightly different view of the generality of the proposed
solution, but we seem to agree on the main issue:

=

The question one have to ask is if =
these
requirements, in the form of an RFC, would serve us as a community if we
encounter a problem with the proposed protocol. I doubt that it will as it =
at
most will strengthen the argument for those having an interest to adopt the
original protocol.

[Santosh] Having a requirements document t=
hat
is a living document, permits us to evaluate various solutions and protocol=
s.
If we do encounter a security problem, it should be useful to analyze
where the engineering process failed, e.g., did we not articulate some
requirement, did we not have sufficient detail for a requirement, did our
analysis of protocol meeting a requirement was flawed, etc.<=
span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:navy'>

=

I would als=
o prefer
to see the requirements document as a living document as you suggest. I thi=
nk
that purpose is best served if the requirements document remains in draft f=
orm.

=

=

=

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<=
span
lang=3DEN-US style=3D'color:#1F497D'>

=

From: [email-masked] [mailto:ow=
[email-masked]]
On Behalf Of Santosh Chokhani

Sent: den 15 december 2008 17:47

To: Stefan Santesson; [email-masked]

Subject: RE: TA requirements doc - do we need it?<=
/p>

Stefan,

See my responses in-line below.

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson<=
br>
Sent: Friday, December 12, 2008 7:25 AM

To: [email-masked]

Subject: TA requirements doc - do we need it?

After all discussions in Minneapoli=
s and
going back and looking at the current situation, I feel less and less convi=
nced
that we need to approve any TA requirements document as an RFC. At least no=
t in
its current form.

I’m fine with having it aroun=
d as a draft
for reference, but I fear it may be a lot more harmful than beneficiary to =
us
as an RFC.

I have two major reasons:

First, as I have argued and tried t=
o
explain with my slide in Minneapolis, there is no general overall approach =
to
TA management in a complex IT environment.

[Santosh] In a complex distributed environ=
ment
that needs to scale across Enterprises, applying requisite security service=
s to
the payload provides a scalable, interoperable, extensible, and secure
solution.

The requirements are radically diff=
erent in
a device oriented environment with disconnected units compared with a centr=
ally
managed IT environment with a common network and data sharing infrastructur=
e.

[Santosh] The requirements are generally t=
he
same in terms of security services.  Some Enterprise IT management
implementations may have implemented Enterprise specific solutions taking
advantages of existing infrastructure and security services provided by the
Enterprise network.  But, that solution may not be as scalable or open=
.

Secondly, the requirements didnR=
17;t come
first. These requirements were written with an existing protocol in mind. T=
he lasting
impression is therefore that the requirements document was written to match=
and
support the original protocol, making it a tool to grandfather the original
protocol into IETF. I’m not claiming that this is the case, but it re=
mains to
be my impression.

[Santosh] If you look at many of the
engineering endeavors we undertake, requirements are based on past experien=
ce,
security vulnerabilities we have encountered, past systems, etc.  I do=
not
know of many successful efforts where requirements were developed in vacuum=
. In
short, it is fair to say that the requirements and protocol benefited from =
each
other and from past experiences with protocols and vulnerabilities.<=
/i>

The question one have to ask is if =
these
requirements, in the form of an RFC, would serve us as a community if we
encounter a problem with the proposed protocol. I doubt that it will as it =
at
most will strengthen the argument for those having an interest to adopt the
original protocol.

[Santosh] Having a requirements document t=
hat
is a living document, permits us to evaluate various solutions and protocol=
s.
If we do encounter a security problem, it should be useful to analyze
where the engineering process failed, e.g., did we not articulate some
requirement, did we not have sufficient detail for a requirement, did our
analysis of protocol meeting a requirement was flawed, etc.<=
span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:navy'>

My proposal going forward is to do =
the
following:

-
In any case adjust the sc=
ope of
the requirements document to reflect the problem space the problem space it=
is
designed for.

-
Leave it as a draft, or a=
t
least not publish it as an RFC before the scope is in harmony with the
requirements.

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<=
span
lang=3DEN-US style=3D'color:#1F497D'>

--_000_9F11911AED01D24BAA1C2355723C3D321AF3E6206DEAEXMSGC332eu_--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGHCt8I014283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 10:12:55 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGHCt4w014282; Tue, 16 Dec 2008 10:12:55 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGHCsRZ014274 for ; Tue, 16 Dec 2008 10:12:54 -0700 (MST) (envelope-from [email-masked])
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95FA1.71A77FB7"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: TA requirements doc - do we need it?
Date: Tue, 16 Dec 2008 12:12:15 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: TA requirements doc - do we need it?
Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9AAC9gTrAAApWoQA==
References: <[email-masked]> <[email-masked]>
From: "Kemp, David P."
To:
X-OriginalArrivalTime: 16 Dec 2008 17:09:50.0062 (UTC) FILETIME=[1ACA78E0:01C95FA1]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C95FA1.71A77FB7
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stefan,

=20

Refining the requirements as a series of I-Ds until "the scope of the
requirements is in harmony with problem space", then publishing as an
RFC once the requirements have converged, certainly sounds like the best
approach.

=20

But you have not explained how "The requirements are radically different
in a device oriented environment with disconnected units compared with a
centrally managed IT environment with a common network and data sharing
infrastructure." The requirements in either case are for managed
devices/applications/services to receive configuration items from
managers without those items being compromised in transit, yes?

=20

* Are you claiming that adversaries have no access to a "common
network and data sharing infrastructure" and therefore no protection is
needed in the networked case? That is patently false for all networks
of interest to the IETF.

* Or that the protection mechanisms appropriate for managing
networked platforms (Connection-oriented? MACs?) are different than
those needed for managing disconnected platforms
(Datagram/message-oriented? Signatures?)

=20

Without understanding the nature of your objections it's hard to tell
whether the scope of the requirements is already in harmony with the
entire problem space or not. Your 4-quadrant slide from Minneapolis is
not self-explanatory - I thought we had already disposed of the
push-pull issue by determining that there is no security-relevant
difference between posting to a repository from which a client may pull
and pushing directly to the client. Therefore the TAM requirements
already cover the left half of the space. If there is a single existing
TAM requirement that precludes pull, or a single missing TAM requirement
needed for pull, please provide an example.

=20

And I need help understanding the difference you see between TA and TA
Policy - if policy is "Host/App A will trust provider X for security
critical firmware category Z", and the TA store of Host/App A has
provider X's TA in the slot for firmware category Z, what is the
difference, other than level of abstraction, between "determine current
TAs in store" and "demonstrate compliance with policy"? Again, an
example of a missing TAM requirement needed to satisfy the right half of
your slide would go a long way toward understanding the scope issue.

=20

Dave

=20

=20

=20

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Tuesday, December 16, 2008 9:58 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: TA requirements doc - do we need it?

=20

Hi Santosh,

=20

As I expect, I sense that we have a slightly different view of the
generality of the proposed solution, but we seem to agree on the main
issue:

=20

The question one have to ask is if these requirements, in the form of an
RFC, would serve us as a community if we encounter a problem with the
proposed protocol. I doubt that it will as it at most will strengthen
the argument for those having an interest to adopt the original
protocol.

[Santosh] Having a requirements document that is a living document,
permits us to evaluate various solutions and protocols. If we do
encounter a security problem, it should be useful to analyze where the
engineering process failed, e.g., did we not articulate some
requirement, did we not have sufficient detail for a requirement, did
our analysis of protocol meeting a requirement was flawed, etc.

=20

I would also prefer to see the requirements document as a living
document as you suggest. I think that purpose is best served if the
requirements document remains in draft form.

=20

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: den 15 december 2008 17:47
To: Stefan Santesson; [email-masked]
Subject: RE: TA requirements doc - do we need it?

=20

Stefan,

=20

See my responses in-line below.=20

=20

_____ =20

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Friday, December 12, 2008 7:25 AM
To: [email-masked]
Subject: TA requirements doc - do we need it?

=20

After all discussions in Minneapolis and going back and looking at the
current situation, I feel less and less convinced that we need to
approve any TA requirements document as an RFC. At least not in its
current form.

I'm fine with having it around as a draft for reference, but I fear it
may be a lot more harmful than beneficiary to us as an RFC.

=20

I have two major reasons:

=20

First, as I have argued and tried to explain with my slide in
Minneapolis, there is no general overall approach to TA management in a
complex IT environment.

[Santosh] In a complex distributed environment that needs to scale
across Enterprises, applying requisite security services to the payload
provides a scalable, interoperable, extensible, and secure solution.

=20

The requirements are radically different in a device oriented
environment with disconnected units compared with a centrally managed IT
environment with a common network and data sharing infrastructure.

[Santosh] The requirements are generally the same in terms of security
services. Some Enterprise IT management implementations may have
implemented Enterprise specific solutions taking advantages of existing
infrastructure and security services provided by the Enterprise network.
But, that solution may not be as scalable or open.

=20

Secondly, the requirements didn't come first. These requirements were
written with an existing protocol in mind. The lasting impression is
therefore that the requirements document was written to match and
support the original protocol, making it a tool to grandfather the
original protocol into IETF. I'm not claiming that this is the case, but
it remains to be my impression.

[Santosh] If you look at many of the engineering endeavors we undertake,
requirements are based on past experience, security vulnerabilities we
have encountered, past systems, etc. I do not know of many successful
efforts where requirements were developed in vacuum. In short, it is
fair to say that the requirements and protocol benefited from each other
and from past experiences with protocols and vulnerabilities.

=20

The question one have to ask is if these requirements, in the form of an
RFC, would serve us as a community if we encounter a problem with the
proposed protocol. I doubt that it will as it at most will strengthen
the argument for those having an interest to adopt the original
protocol.

[Santosh] Having a requirements document that is a living document,
permits us to evaluate various solutions and protocols. If we do
encounter a security problem, it should be useful to analyze where the
engineering process failed, e.g., did we not articulate some
requirement, did we not have sufficient detail for a requirement, did
our analysis of protocol meeting a requirement was flawed, etc.

=20

My proposal going forward is to do the following:

- In any case adjust the scope of the requirements document to
reflect the problem space the problem space it is designed for.

- Leave it as a draft, or at least not publish it as an RFC
before the scope is in harmony with the requirements.

=20

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

------_=_NextPart_001_01C95FA1.71A77FB7
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stefan,

Refining the =
requirements as a
series of I-Ds until “the scope of the requirements is in harmony =
with problem
space”, then publishing as an RFC once the requirements have =
converged, certainly
sounds like the best approach.

But you have not =
explained how “The
requirements are radically different in a device oriented environment =
with
disconnected units compared with a centrally managed IT environment with =
a
common network and data sharing infrastructure.”  The
requirements in either case are for managed =
devices/applications/services to
receive configuration items from managers without those items being =
compromised
in transit, yes?

·
Are you =
claiming
that adversaries have no access to a “common network and data =
sharing
infrastructure” and therefore no protection is needed in the =
networked case?
That is patently false for all networks of interest to the =
IETF.

·
Or that the
protection mechanisms appropriate for managing networked platforms =
(Connection-oriented?
MACs?) are different than those needed for managing disconnected =
platforms (Datagram/message-oriented?
Signatures?)

Without understanding =
the nature
of your objections it’s hard to tell whether the scope of the =
requirements is
already in harmony with the entire problem space or not.   =
Your 4-quadrant
slide from Minneapolis is not self-explanatory – I thought we had =
already
disposed of the push-pull issue by determining that there is no =
security-relevant
difference between posting to a repository from which a client may pull =
and
pushing directly to the client.  Therefore the TAM requirements =
already cover
the left half of the space.  If there is a single existing TAM =
requirement that
precludes pull, or a single missing TAM requirement needed for pull, =
please provide
an example.

And I need help =
understanding
the difference you see between TA and TA Policy – if policy is =
“Host/App A will
trust provider X for security critical firmware category Z”, and =
the TA store
of Host/App A has provider X’s TA in the slot for firmware =
category Z, what is
the difference, other than level of abstraction, between =
“determine current TAs
in store” and “demonstrate compliance with =
policy”?  Again, an example of a
missing TAM requirement needed to satisfy the right half of your slide =
would go
a long way toward understanding the scope issue.

Dave

From:=

[email-masked] [mailto:[email-masked]] On =
Behalf
Of Stefan Santesson

Sent: Tuesday, December 16, 2008 9:58 AM

To: Santosh Chokhani; [email-masked]

Subject: RE: TA requirements doc - do we need =
it?

Hi
Santosh,

As I expect, I sense =
that we
have a slightly different view of the generality of the proposed =
solution, but
we seem to agree on the main issue:

The question one have to ask is if these =
requirements, in
the form of an RFC, would serve us as a community if we encounter a =
problem
with the proposed protocol. I doubt that it will as it at most will =
strengthen
the argument for those having an interest to adopt the original =
protocol.

[Santosh] Having a requirements document that is a living =
document,
permits us to evaluate various solutions and protocols.  If we do
encounter a security problem, it should be useful to analyze where the
engineering process failed, e.g., did we not articulate some =
requirement, did
we not have sufficient detail for a requirement, did our analysis of =
protocol
meeting a requirement was flawed, etc.

I would also prefer =
to see the
requirements document as a living document as you suggest. I think that =
purpose
is best served if the requirements document remains in draft =
form.

Stefan Santesson

Senior Program Manager

Windows Security, =
Standards

From:=

[email-masked] [mailto:[email-masked]] On =
Behalf
Of Santosh Chokhani

Sent: den 15 december 2008 17:47

To: Stefan Santesson; [email-masked]

Subject: RE: TA requirements doc - do we need =
it?

Stefan,

See my responses in-line below.

From:=

[email-masked] [mailto:[email-masked]] On =
Behalf
Of Stefan Santesson

Sent: Friday, December 12, 2008 7:25 AM

To: [email-masked]

Subject: TA requirements doc - do we need it?

After all discussions in Minneapolis and going back =
and
looking at the current situation, I feel less and less convinced that we =
need
to approve any TA requirements document as an RFC. At least not in its =
current
form.

I’m fine with having it around as a draft for =
reference, but
I fear it may be a lot more harmful than beneficiary to us as an =
RFC.

I have two major reasons:

First, as I have argued and tried to explain with =
my slide
in Minneapolis, there is no general overall approach to TA management in =
a
complex IT environment.

[Santosh] In a complex distributed environment that needs to =
scale
across Enterprises, applying requisite security services to the payload
provides a scalable, interoperable, extensible, and secure =
solution.

The requirements are radically different in a =
device
oriented environment with disconnected units compared with a centrally =
managed
IT environment with a common network and data sharing =
infrastructure.

[Santosh] The requirements are generally the same in terms =
of
security services.  Some Enterprise IT management implementations =
may have
implemented Enterprise specific solutions taking advantages of existing
infrastructure and security services provided by the Enterprise network.
But, that solution may not be as scalable or =
open.

Secondly, the requirements didn’t come first. =
These
requirements were written with an existing protocol in mind. The lasting
impression is therefore that the requirements document was written to =
match and
support the original protocol, making it a tool to grandfather the =
original
protocol into IETF. I’m not claiming that this is the case, but it =
remains to
be my impression.

[Santosh] If you look at many of the engineering endeavors =
we
undertake, requirements are based on past experience, security =
vulnerabilities
we have encountered, past systems, etc.  I do not know of many =
successful
efforts where requirements were developed in vacuum. In short, it is =
fair to
say that the requirements and protocol benefited from each other and =
from past
experiences with protocols and =
vulnerabilities.

The question one have to ask is if these =
requirements, in
the form of an RFC, would serve us as a community if we encounter a =
problem
with the proposed protocol. I doubt that it will as it at most will =
strengthen
the argument for those having an interest to adopt the original =
protocol.

[Santosh] Having a requirements document that is a living =
document,
permits us to evaluate various solutions and protocols.  If we do
encounter a security problem, it should be useful to analyze where the
engineering process failed, e.g., did we not articulate some =
requirement, did
we not have sufficient detail for a requirement, did our analysis of =
protocol
meeting a requirement was flawed, etc.

My proposal going forward is to do the =
following:

-
In any case adjust the scope of the requirements
document to reflect the problem space the problem space it is designed =
for.

-
Leave it as a draft, or at least not publish it =
as an
RFC before the scope is in harmony with the requirements.

Stefan Santesson

Senior Program Manager

Windows Security, =
Standards

------_=_NextPart_001_01C95FA1.71A77FB7--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGFwje2009846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 08:58:45 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGFwjED009845; Tue, 16 Dec 2008 08:58:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGFwYZ0009833 for ; Tue, 16 Dec 2008 08:58:45 -0700 (MST) (envelope-from [email-masked])
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: straw poll
Date: Tue, 16 Dec 2008 10:58:20 -0500
Message-ID: <[email-masked]>
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: straw poll
Thread-Index: AclfkM/lPsmO8eQLRsii96PH/Om8VAABjnCw
References:
From: "Kemp, David P."
To:
X-OriginalArrivalTime: 16 Dec 2008 15:55:30.0375 (UTC) FILETIME=[B89C3D70:01C95F96]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

1. yes
2. yes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: Tuesday, December 16, 2008 9:29 AM
To: [email-masked]
Subject: straw poll

At a previous IETF meeting (Dublin) I agreed to conduct a straw poll=20
on adding a new WG item to address OCSP algorithm agility concerns,=20
after PHB sent a message indicating what status he envisioned for the=20
work. This action for both me and PHB fell through the cracks. At the=20
MSP IETF meeting PHB provided a briefing on the problems that he saw=20
re OCSP ambiguities re algorithm agility, and proposed a standards=20
track document to address these issues (see PHB's message of 12/2).

So, we now have a concrete proposal (draft-hallambaker-ocspagility)=20
available for review. PHB would like to publish this and then merge=20
it into the OCSP document when it progresses from PROPOSED to DRAFT=20
(see his message of 12/2).

Please send a message to the list by January 9th (allowing for=20
holiday outages) indicating whether

1. your support PKIX work in this area
2. you support adopting PHB's document as a starting point=20
for such work

Thanks & Happy Hoplidays,

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGFFnDP007171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 08:15:49 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGFFnVb007170; Tue, 16 Dec 2008 08:15:49 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGFFbVn007156 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 16 Dec 2008 08:15:48 -0700 (MST) (envelope-from [email-masked])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 16 Dec 2008 15:15:37 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Tue, 16 Dec 2008 15:15:37 +0000
From: Stefan Santesson
To: Stephen Kent , "[email-masked]"
Date: Tue, 16 Dec 2008 15:15:40 +0000
Subject: RE: straw poll
Thread-Topic: straw poll
Thread-Index: AclfkMbj9Mz4GZIQRs2Bt/jsEmq9dgAABI+A
Message-ID: <[email-masked]>
References:
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

1&2

I support work in the area and I support using PHB's document as starting p=
oint.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: den 16 december 2008 15:29
> To: [email-masked]
> Subject: straw poll
>
>
> At a previous IETF meeting (Dublin) I agreed to conduct a straw poll
> on adding a new WG item to address OCSP algorithm agility concerns,
> after PHB sent a message indicating what status he envisioned for the
> work. This action for both me and PHB fell through the cracks. At the
> MSP IETF meeting PHB provided a briefing on the problems that he saw
> re OCSP ambiguities re algorithm agility, and proposed a standards
> track document to address these issues (see PHB's message of 12/2).
>
> So, we now have a concrete proposal (draft-hallambaker-ocspagility)
> available for review. PHB would like to publish this and then merge
> it into the OCSP document when it progresses from PROPOSED to DRAFT
> (see his message of 12/2).
>
> Please send a message to the list by January 9th (allowing for
> holiday outages) indicating whether
>
> 1. your support PKIX work in this area
> 2. you support adopting PHB's document as a starting point
> for such work
>
> Thanks & Happy Hoplidays,
>
> Steve
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGEw2f3005912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 07:58:02 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGEw2pO005911; Tue, 16 Dec 2008 07:58:02 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGEvotx005898 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 16 Dec 2008 07:58:01 -0700 (MST) (envelope-from [email-masked])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 16 Dec 2008 14:57:49 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Tue, 16 Dec 2008 14:57:49 +0000
From: Stefan Santesson
To: Santosh Chokhani , "[email-masked]"
Date: Tue, 16 Dec 2008 14:57:51 +0000
Subject: RE: TA requirements doc - do we need it?
Thread-Topic: TA requirements doc - do we need it?
Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9AAC9gTrA=
Message-ID: <[email-masked]>
References: <[email-masked]>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0EAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Hi Santosh,

As I expect, I sense that we have a slightly different view of the generali=
ty of the proposed solution, but we seem to agree on the main issue:

The question one have to ask is if these requirements, in the form of an RF=
C, would serve us as a community if we encounter a problem with the propose=
d protocol. I doubt that it will as it at most will strengthen the argument=
for those having an interest to adopt the original protocol.
[Santosh] Having a requirements document that is a living document, permits=
us to evaluate various solutions and protocols. If we do encounter a secu=
rity problem, it should be useful to analyze where the engineering process =
failed, e.g., did we not articulate some requirement, did we not have suffi=
cient detail for a requirement, did our analysis of protocol meeting a requ=
irement was flawed, etc.

I would also prefer to see the requirements document as a living document a=
s you suggest. I think that purpose is best served if the requirements docu=
ment remains in draft form.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On=
Behalf Of Santosh Chokhani
Sent: den 15 december 2008 17:47
To: Stefan Santesson; [email-masked]
Subject: RE: TA requirements doc - do we need it?

Stefan,

See my responses in-line below.

________________________________
From: [email-masked] [mailto:[email-masked]] On=
Behalf Of Stefan Santesson
Sent: Friday, December 12, 2008 7:25 AM
To: [email-masked]
Subject: TA requirements doc - do we need it?

After all discussions in Minneapolis and going back and looking at the curr=
ent situation, I feel less and less convinced that we need to approve any T=
A requirements document as an RFC. At least not in its current form.
I'm fine with having it around as a draft for reference, but I fear it may =
be a lot more harmful than beneficiary to us as an RFC.

I have two major reasons:

First, as I have argued and tried to explain with my slide in Minneapolis, =
there is no general overall approach to TA management in a complex IT envir=
onment.
[Santosh] In a complex distributed environment that needs to scale across E=
nterprises, applying requisite security services to the payload provides a =
scalable, interoperable, extensible, and secure solution.

The requirements are radically different in a device oriented environment w=
ith disconnected units compared with a centrally managed IT environment wit=
h a common network and data sharing infrastructure.
[Santosh] The requirements are generally the same in terms of security serv=
ices. Some Enterprise IT management implementations may have implemented E=
nterprise specific solutions taking advantages of existing infrastructure a=
nd security services provided by the Enterprise network. But, that solutio=
n may not be as scalable or open.

Secondly, the requirements didn't come first. These requirements were writt=
en with an existing protocol in mind. The lasting impression is therefore t=
hat the requirements document was written to match and support the original=
protocol, making it a tool to grandfather the original protocol into IETF.=
I'm not claiming that this is the case, but it remains to be my impression=
.
[Santosh] If you look at many of the engineering endeavors we undertake, re=
quirements are based on past experience, security vulnerabilities we have e=
ncountered, past systems, etc. I do not know of many successful efforts wh=
ere requirements were developed in vacuum. In short, it is fair to say that=
the requirements and protocol benefited from each other and from past expe=
riences with protocols and vulnerabilities.

The question one have to ask is if these requirements, in the form of an RF=
C, would serve us as a community if we encounter a problem with the propose=
d protocol. I doubt that it will as it at most will strengthen the argument=
for those having an interest to adopt the original protocol.
[Santosh] Having a requirements document that is a living document, permits=
us to evaluate various solutions and protocols. If we do encounter a secu=
rity problem, it should be useful to analyze where the engineering process =
failed, e.g., did we not articulate some requirement, did we not have suffi=
cient detail for a requirement, did our analysis of protocol meeting a requ=
irement was flawed, etc.

My proposal going forward is to do the following:

- In any case adjust the scope of the requirements document to ref=
lect the problem space the problem space it is designed for.

- Leave it as a draft, or at least not publish it as an RFC before=
the scope is in harmony with the requirements.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

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

Hi
Santosh,

=

As I expect=
, I sense
that we have a slightly different view of the generality of the proposed so=
lution,
but we seem to agree on the main issue:

=

The question one have to ask is if =
these
requirements, in the form of an RFC, would serve us as a community if we
encounter a problem with the proposed protocol. I doubt that it will as it =
at
most will strengthen the argument for those having an interest to adopt the
original protocol.

[Santosh] Having a requirements document t=
hat
is a living document, permits us to evaluate various solutions and protocol=
s.
If we do encounter a security problem, it should be useful to analyze
where the engineering process failed, e.g., did we not articulate some
requirement, did we not have sufficient detail for a requirement, did our
analysis of protocol meeting a requirement was flawed, etc.<=
span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:navy'>

=

I would als=
o prefer
to see the requirements document as a living document as you suggest. I thi=
nk
that purpose is best served if the requirements document remains in draft f=
orm.

=

=

=

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<=
span
lang=3DEN-US style=3D'color:#1F497D'>

=

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Santosh Chokhani<=
br>
Sent: den 15 december 2008 17:47

To: Stefan Santesson; [email-masked]

Subject: RE: TA requirements doc - do we need it?<=
/p>

Stefan,

See my responses in-line below.

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson<=
br>
Sent: Friday, December 12, 2008 7:25 AM

To: [email-masked]

Subject: TA requirements doc - do we need it?

After all discussions in Minneapoli=
s and
going back and looking at the current situation, I feel less and less convi=
nced
that we need to approve any TA requirements document as an RFC. At least no=
t in
its current form.

I’m fine with having it aroun=
d as a
draft for reference, but I fear it may be a lot more harmful than beneficia=
ry
to us as an RFC.

I have two major reasons:

First, as I have argued and tried t=
o
explain with my slide in Minneapolis, there is no general overall approach =
to
TA management in a complex IT environment.

[Santosh] In a complex distributed environ=
ment
that needs to scale across Enterprises, applying requisite security service=
s to
the payload provides a scalable, interoperable, extensible, and secure
solution.

The requirements are radically diff=
erent in
a device oriented environment with disconnected units compared with a centr=
ally
managed IT environment with a common network and data sharing infrastructur=
e.

[Santosh] The requirements are generally t=
he
same in terms of security services.  Some Enterprise IT management
implementations may have implemented Enterprise specific solutions taking
advantages of existing infrastructure and security services provided by the
Enterprise network.  But, that solution may not be as scalable or open=
.

Secondly, the requirements didnR=
17;t
come first. These requirements were written with an existing protocol in mi=
nd.
The lasting impression is therefore that the requirements document was writ=
ten
to match and support the original protocol, making it a tool to grandfather=
the
original protocol into IETF. I’m not claiming that this is the case, =
but
it remains to be my impression.

[Santosh] If you look at many of the
engineering endeavors we undertake, requirements are based on past experien=
ce,
security vulnerabilities we have encountered, past systems, etc.  I do=
not
know of many successful efforts where requirements were developed in vacuum=
. In
short, it is fair to say that the requirements and protocol benefited from =
each
other and from past experiences with protocols and vulnerabilities.<=
/i>

The question one have to ask is if =
these
requirements, in the form of an RFC, would serve us as a community if we
encounter a problem with the proposed protocol. I doubt that it will as it =
at
most will strengthen the argument for those having an interest to adopt the
original protocol.

[Santosh] Having a requirements document t=
hat
is a living document, permits us to evaluate various solutions and protocol=
s.
If we do encounter a security problem, it should be useful to analyze
where the engineering process failed, e.g., did we not articulate some
requirement, did we not have sufficient detail for a requirement, did our
analysis of protocol meeting a requirement was flawed, etc.<=
span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:navy'>

My proposal going forward is to do =
the
following:

-
In any case adjust the sc=
ope of
the requirements document to reflect the problem space the problem space it=
is
designed for.

-
Leave it as a draft, or a=
t
least not publish it as an RFC before the scope is in harmony with the
requirements.

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<=
span
lang=3DEN-US style=3D'color:#1F497D'>

--_000_9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0EAEXMSGC332eu_--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGETCIo004324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 07:29:12 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGETCjO004323; Tue, 16 Dec 2008 07:29:12 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGET2Yc004313 for ; Tue, 16 Dec 2008 07:29:12 -0700 (MST) (envelope-from [email-masked])
Received: from ros-dhcp233-050-110.bbn.com ([192.233.50.110]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LCauz-0007p7-Cz for [email-masked]; Tue, 16 Dec 2008 09:29:01 -0500
Mime-Version: 1.0
Message-Id:
Date: Tue, 16 Dec 2008 09:29:06 -0500
To: [email-masked]
From: Stephen Kent
Subject: straw poll
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At a previous IETF meeting (Dublin) I agreed to conduct a straw poll
on adding a new WG item to address OCSP algorithm agility concerns,
after PHB sent a message indicating what status he envisioned for the
work. This action for both me and PHB fell through the cracks. At the
MSP IETF meeting PHB provided a briefing on the problems that he saw
re OCSP ambiguities re algorithm agility, and proposed a standards
track document to address these issues (see PHB's message of 12/2).

So, we now have a concrete proposal (draft-hallambaker-ocspagility)
available for review. PHB would like to publish this and then merge
it into the OCSP document when it progresses from PROPOSED to DRAFT
(see his message of 12/2).

Please send a message to the list by January 9th (allowing for
holiday outages) indicating whether

1. your support PKIX work in this area
2. you support adopting PHB's document as a starting point
for such work

Thanks & Happy Hoplidays,

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFGl5Xw038899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 09:47:05 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFGl5tc038898; Mon, 15 Dec 2008 09:47:05 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBFGksmg038886 for ; Mon, 15 Dec 2008 09:47:04 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 5374 invoked from network); 15 Dec 2008 16:46:12 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;15 Dec 2008 16:46:12 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 15 Dec 2008 16:46:11 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95ED4.BB20D3C0"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: TA requirements doc - do we need it?
Date: Mon, 15 Dec 2008 11:46:51 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: TA requirements doc - do we need it?
thread-index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9A
References: <[email-masked]>
From: "Santosh Chokhani"
To: "Stefan Santesson" ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

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

Stefan,

=20

See my responses in-line below.=20

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Friday, December 12, 2008 7:25 AM
To: [email-masked]
Subject: TA requirements doc - do we need it?

=20

After all discussions in Minneapolis and going back and looking at the
current situation, I feel less and less convinced that we need to
approve any TA requirements document as an RFC. At least not in its
current form.

I'm fine with having it around as a draft for reference, but I fear it
may be a lot more harmful than beneficiary to us as an RFC.

=20

I have two major reasons:

=20

First, as I have argued and tried to explain with my slide in
Minneapolis, there is no general overall approach to TA management in a
complex IT environment.

[Santosh] In a complex distributed environment that needs to scale
across Enterprises, applying requisite security services to the payload
provides a scalable, interoperable, extensible, and secure solution.

=20

The requirements are radically different in a device oriented
environment with disconnected units compared with a centrally managed IT
environment with a common network and data sharing infrastructure.

[Santosh] The requirements are generally the same in terms of security
services. Some Enterprise IT management implementations may have
implemented Enterprise specific solutions taking advantages of existing
infrastructure and security services provided by the Enterprise network.
But, that solution may not be as scalable or open.

=20

Secondly, the requirements didn't come first. These requirements were
written with an existing protocol in mind. The lasting impression is
therefore that the requirements document was written to match and
support the original protocol, making it a tool to grandfather the
original protocol into IETF. I'm not claiming that this is the case, but
it remains to be my impression.

[Santosh] If you look at many of the engineering endeavors we undertake,
requirements are based on past experience, security vulnerabilities we
have encountered, past systems, etc. I do not know of many successful
efforts where requirements were developed in vacuum. In short, it is
fair to say that the requirements and protocol benefited from each other
and from past experiences with protocols and vulnerabilities.

=20

The question one have to ask is if these requirements, in the form of an
RFC, would serve us as a community if we encounter a problem with the
proposed protocol. I doubt that it will as it at most will strengthen
the argument for those having an interest to adopt the original
protocol.

[Santosh] Having a requirements document that is a living document,
permits us to evaluate various solutions and protocols. If we do
encounter a security problem, it should be useful to analyze where the
engineering process failed, e.g., did we not articulate some
requirement, did we not have sufficient detail for a requirement, did
our analysis of protocol meeting a requirement was flawed, etc.

=20

My proposal going forward is to do the following:

- In any case adjust the scope of the requirements document to
reflect the problem space the problem space it is designed for.

- Leave it as a draft, or at least not publish it as an RFC
before the scope is in harmony with the requirements.

=20

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

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

Stefan,
=

See my responses in-line below. =

From: =
[email-masked]
[mailto:[email-masked]] On
Behalf Of Stefan Santesson

Sent: Friday, December =
12, 2008
7:25 AM

To: [email-masked]

Subject: TA requirements =
doc - do
we need it?

After
all discussions in Minneapolis
and going back and looking at the current situation, I feel less and =
less
convinced that we need to approve any TA requirements document as an =
RFC. At
least not in its current form.

I’m
fine with having it around as a draft for reference, but I fear it may =
be a lot
more harmful than beneficiary to us as an =
RFC.

I
have two major reasons:

First,
as I have argued and tried to explain with my slide in Minneapolis, there is no general =
overall
approach to TA management in a complex IT =
environment.

[Santosh] In a complex distributed environment that =
needs to
scale across Enterprises, applying requisite security services to the =
payload provides
a scalable, interoperable, extensible, and secure =
solution.

The
requirements are radically different in a device oriented environment =
with
disconnected units compared with a centrally managed IT environment with =
a
common network and data sharing =
infrastructure.

[Santosh] The requirements are generally the same in =
terms
of security services.  Some Enterprise IT
management implementations may have implemented Enterprise
specific solutions taking advantages of existing infrastructure and =
security
services provided by the Enterprise
network.  But, that solution may not be as scalable or =
open.

Secondly,
the requirements didn’t come first. These requirements were =
written with
an existing protocol in mind. The lasting impression is therefore that =
the
requirements document was written to match and support the original =
protocol,
making it a tool to grandfather the original protocol into IETF. =
I’m not
claiming that this is the case, but it remains to be my =
impression.

[Santosh] If you look at many of the engineering =
endeavors
we undertake, requirements are based on past experience, security =
vulnerabilities
we have encountered, past systems, etc.  I do not know of many =
successful efforts
where requirements were developed in vacuum. In short, it is fair to say =
that the
requirements and protocol benefited from each other and from past =
experiences with
protocols and vulnerabilities.

The
question one have to ask is if these requirements, in the form of an =
RFC, would
serve us as a community if we encounter a problem with the proposed =
protocol. I
doubt that it will as it at most will strengthen the argument for those =
having
an interest to adopt the original protocol.

[Santosh] Having a requirements document that is a =
living document,
permits us to evaluate various solutions and protocols.  If we do =
encounter
a security problem, it should be useful to analyze where the engineering =
process
failed, e.g., did we not articulate some requirement, did we not have =
sufficient
detail for a requirement, did our analysis of protocol meeting a =
requirement
was flawed, etc.

My
proposal going forward is to do the =
following:

-
In any case adjust the =
scope of
the requirements document to reflect the problem space the problem space =
it is
designed for.

-
Leave it as a draft, or at =
least
not publish it as an RFC before the scope is in harmony with the =
requirements.

Stefan
Santesson

Senior =
Program Manager

Windows
Security, Standards

------_=_NextPart_001_01C95ED4.BB20D3C0--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFEhAra032870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 07:43:10 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFEhAxQ032869; Mon, 15 Dec 2008 07:43:10 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from zombie2.ncsc.mil (zombie2.ncsc.mil [144.51.88.133]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFEgwxJ032858 for ; Mon, 15 Dec 2008 07:43:09 -0700 (MST) (envelope-from [email-masked])
Received: from smtp.ncsc.mil (jazzdrum.ncsc.mil [144.51.5.7]) by zombie2.ncsc.mil (8.12.10/8.12.10) with ESMTP id mBFEedEN025511; Mon, 15 Dec 2008 14:40:39 GMT
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95EC3.6BA2BC69"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: NSA SuiteB Certificate and CRL Profile
Date: Mon, 15 Dec 2008 09:42:57 -0500
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: NSA SuiteB Certificate and CRL Profile
Thread-Index: Aclew2qfI4gj78GSRAWOB65GfvTcUw==
From: "Zieglar, Lydia L."
To:
Cc: "Wallner, Debbie M" ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

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

We have recently submitted the National Security Agency's Suite B
Certificate and CRL Profile to the IETF as an Internet-Draft.=20
=20
Even though this is an individual submission, we believe that you may be
interested and we encourage you to review the document. Please send your
comments to [email-masked]
=20
You may reach the document at:
=20
http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cert-profile-00
.txt
=20
Thanks,
Lydia Zieglar
=20
Lydia Zieglar
301-688-1028
[email-masked]
=20

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

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

Even =
though this is=20
an individual submission, we believe that you may be interested and we =
encourage=20
you to review the document. Please send your comments to [email-masked]<=
/FONT>

You =
may reach the=20
document at:

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

Thanks,

Lydia=20
Zieglar

Lydia Zieglar

301-688-1028

[email-masked]

------_=_NextPart_001_01C95EC3.6BA2BC69--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCIiuaj099003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 11:44:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBCIiuFR099001; Fri, 12 Dec 2008 11:44:56 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCIiuN1098989 for ; Fri, 12 Dec 2008 11:44:56 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id CAA8528C131; Fri, 12 Dec 2008 10:45:01 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-3281update-02.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Fri, 12 Dec 2008 10:45:01 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

Title : An Internet Attribute Certificate Profile for Authorization
Author(s) : R. Housley, S. Farrell, S. Turner
Filename : draft-ietf-pkix-3281update-02.txt
Pages : 45
Date : 2008-12-12

This specification defines a profile for the use of X.509 Attribute
Certificates in Internet Protocols. Attribute certificates may be
used in a wide range of applications and environments covering a
broad spectrum of interoperability goals and a broader spectrum of
operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring
broad interoperability as well as limited special purpose
requirements. The profile places emphasis on attribute certificate
support for Internet electronic mail, IPSec, and WWW security
applications. This document obsoletes RFC 3281.

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

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

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

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

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

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCITu4H098430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 11:29:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBCITuqF098429; Fri, 12 Dec 2008 11:29:56 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCITt4d098423 for ; Fri, 12 Dec 2008 11:29:55 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id 45BA03A6870; Fri, 12 Dec 2008 10:30:00 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-11.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Fri, 12 Dec 2008 10:30:01 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

Title : Elliptic Curve Cryptography Subject Public Key Information
Author(s) : S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk
Filename : draft-ietf-pkix-ecc-subpubkeyinfo-11.txt
Pages : 22
Date : 2008-12-12

This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 3279.

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

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

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

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

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

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCCPf7a078467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 05:25:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBCCPf5X078466; Fri, 12 Dec 2008 05:25:41 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCCPTae078452 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 12 Dec 2008 05:25:40 -0700 (MST) (envelope-from [email-masked])
Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 12 Dec 2008 12:25:28 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Fri, 12 Dec 2008 12:25:28 +0000
From: Stefan Santesson
To: "[email-masked]"
Date: Fri, 12 Dec 2008 12:25:25 +0000
Subject: TA requirements doc - do we need it?
Thread-Topic: TA requirements doc - do we need it?
Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rg==
Message-ID: <[email-masked]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AB5CB52E5EAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

After all discussions in Minneapolis and going back and looking at the curr=
ent situation, I feel less and less convinced that we need to approve any T=
A requirements document as an RFC. At least not in its current form.
I'm fine with having it around as a draft for reference, but I fear it may =
be a lot more harmful than beneficiary to us as an RFC.

I have two major reasons:

First, as I have argued and tried to explain with my slide in Minneapolis, =
there is no general overall approach to TA management in a complex IT envir=
onment.
The requirements are radically different in a device oriented environment w=
ith disconnected units compared with a centrally managed IT environment wit=
h a common network and data sharing infrastructure.

Secondly, the requirements didn't come first. These requirements were writt=
en with an existing protocol in mind. The lasting impression is therefore t=
hat the requirements document was written to match and support the original=
protocol, making it a tool to grandfather the original protocol into IETF.=
I'm not claiming that this is the case, but it remains to be my impression=
.

The question one have to ask is if these requirements, in the form of an RF=
C, would serve us as a community if we encounter a problem with the propose=
d protocol. I doubt that it will as it at most will strengthen the argument=
for those having an interest to adopt the original protocol.

My proposal going forward is to do the following:

- In any case adjust the scope of the requirements document to ref=
lect the problem space the problem space it is designed for.

- Leave it as a draft, or at least not publish it as an RFC before=
the scope is in harmony with the requirements.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

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

After all discussions in Minneapoli=
s and
going back and looking at the current situation, I feel less and less convi=
nced
that we need to approve any TA requirements document as an RFC. At least no=
t in
its current form.

I’m fine with having it aroun=
d as a
draft for reference, but I fear it may be a lot more harmful than beneficia=
ry
to us as an RFC.

I have two major reasons:

First, as I have argued and tried t=
o
explain with my slide in Minneapolis, there is no general overall approach =
to
TA management in a complex IT environment.

The requirements are radically diff=
erent in
a device oriented environment with disconnected units compared with a centr=
ally
managed IT environment with a common network and data sharing infrastructur=
e.

Secondly, the requirements didnR=
17;t
come first. These requirements were written with an existing protocol in mi=
nd.
The lasting impression is therefore that the requirements document was writ=
ten
to match and support the original protocol, making it a tool to grandfather=
the
original protocol into IETF. I’m not claiming that this is the case, =
but
it remains to be my impression.

The question one have to ask is if =
these
requirements, in the form of an RFC, would serve us as a community if we
encounter a problem with the proposed protocol. I doubt that it will as it =
at
most will strengthen the argument for those having an interest to adopt the
original protocol.

My proposal going forward is to do =
the
following:

-
In any case adjust the sc=
ope of
the requirements document to reflect the problem space the problem space it=
is
designed for.

-
Leave it as a draft, or a=
t
least not publish it as an RFC before the scope is in harmony with the requ=
irements.

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<=
span
lang=3DEN-US style=3D'color:#1F497D'>

--_000_9F11911AED01D24BAA1C2355723C3D321AB5CB52E5EAEXMSGC332eu_--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBISU2N026781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 11:28:30 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBBISUwb026779; Thu, 11 Dec 2008 11:28:30 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.noorhome.net (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBISJmV026763 for ; Thu, 11 Dec 2008 11:28:30 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.noorhome.net (Postfix) with ESMTP id 198DF3AF1C7 for ; Thu, 11 Dec 2008 13:28:19 -0500 (EST)
X-Spam-Score: -4.376
X-Spam-Level:
X-Spam-Status: No, score=-4.376 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.023, BAYES_00=-2.599]
Received: from mailhost.noorhome.net ([127.0.0.1]) by localhost (mailhost.noorhome.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8qBjhb6hNNk for ; Thu, 11 Dec 2008 13:28:18 -0500 (EST)
Received: from mailhost.noorhome.net (mailhost.noorhome.net [63.194.79.229]) by mailhost.noorhome.net (Postfix) with ESMTP id 31E413AF1A2 for ; Thu, 11 Dec 2008 13:28:18 -0500 (EST)
Date: Thu, 11 Dec 2008 13:28:18 -0500 (EST)
From: Arshad Noor
To: ietf-pkix
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: Fwd: [members] Public Review of SKSML v1.0 - 15 day review
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [72.18.244.116]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

FYI.

Arshad Noor
StrongAuth, Inc.

----- Forwarded Message -----
From: "Mary McRae"
To: [email-masked], [email-masked]
Sent: Thursday, December 11, 2008 8:29:35 AM (GMT-0800) America/Los_Angeles
Subject: [members] Public Review of SKSML v1.0 - 15 day review

To OASIS members, Public Announce Lists:

The OASIS Enterprise Key Management Infrastructure (EKMI) TC has recently approved the following specification as a Committee Draft and approved the package for public review:

Symmetric Key Services Markup Language (SKSML) Version 1.0

The public review starts today , 11 December 2008 , and ends 26 December 2008 . This specification was previously submitted for a 60-day public review on 24 Jul 08 - 23 Sep 08 [1]; this 15-day review is limited in scope to changes made from the previous review. All changes are noted below[2].

This is an open invitation to comment. We strongly encourage feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of OASIS work.

More non-normative information about the specification and the technical committee may be found at the public home page of the TC at

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi ]. Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button marked "Send A Comment" at the top of that page, or directly at

http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ekmi ].

Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at

http://lists.oasis-open.org/archives/ekmi-comment/ . All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members.

The specification document and related files are available here:

Editable Source:

http://docs.oasis-open.org/ekmi/sksml/v1.0/pr02/SKSML-1.0-Specification.odt

PDF:

http://docs.oasis-open.org/ekmi/sksml/v1.0/pr02/SKSML-1.0-Specification.pdf

HTML:

http://docs.oasis-open.org/ekmi/sksml/v1.0/pr02/SKSML-1.0-Specification.html

The schema files are available at:

Schema:

http://docs.oasis-open.org/ekmi/sksml/v1.0/pr02/schema/

OASIS and the EKMI TC welcome your comments.

---------------------------------------------------

Mary P McRae

Director, Technical Committee Administration

OASIS: Advancing open standards for the information society

email: [email-masked]

web: www.oasis-open.org

phone: 1. 603.232.9090

[1] http://lists.oasis-open.org/archives/tc-announce/200807/msg00011.html

[2] changes since last Public Review:

1) Section 3.9 - added an example of a Request for a symmetric key with an Encryption Certificate

2) Section 3.12 - added an example of a Response with a pending Request ID

3) Section 3.13 - added an example of a Request with an update of a pending Request ID

4) Section 4.4 - added definition for element

5) Section 4.5 - added definition for element

6) Section 4.6 - modified definition of to now also return a element

7) Section 4.8 - added definition for element

8) Section 4.9 - modified definition of to now also return errors related to elements

9) Section 4.30 - added definition for Use of SKMS Error Codes and Messages

10) Appendix C - added Standard Error Codes and Messages

11) Appendix D - added process definition for Vendors to apply for a reserved block of codes

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBBpELE005778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 04:51:14 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBBBpEC8005777; Thu, 11 Dec 2008 04:51:14 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBBp2Bq005761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 11 Dec 2008 04:51:13 -0700 (MST) (envelope-from [email-masked])
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id mBBBp1pW001257; Thu, 11 Dec 2008 03:51:01 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 03:51:01 -0800
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_01C95B86.BC04481B"
Subject: RE: New Version Notification for draft-hallambaker-ocspagility-02
Date: Thu, 11 Dec 2008 03:50:59 -0800
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: New Version Notification for draft-hallambaker-ocspagility-02
Thread-Index: AclUrVTMVGC0OUj3RuOSZcazd8skDgAAWWYUAbAkkKAABZs5tw==
References: <[email-masked]> <[email-masked]> <[email-masked]>
From: "Hallam-Baker, Phillip"
To: "Stefan Santesson" ,
X-OriginalArrivalTime: 11 Dec 2008 11:51:01.0435 (UTC) FILETIME=[BD2CE0B0:01C95B86]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C95B86.BC04481B
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On the first issue, it depends on your implementation. If two signature =
algorithms are used and clients accept either then the result is to =
weaken the protection. If two algorithms are required and either clients =
are required to check both or there is a mechanism to disable use of a =
compromised algorithm the net result is stronger.

In the case of checking a cert chain and an OCSP validation chain the =
second considerations apply.

On the 5019 issue, happy to extend the draft, just preferred to get =
something in ASAP and need to get my head around the concerns first.

-----Original Message-----
From: [email-masked] on behalf of Stefan Santesson
Sent: Thu 12/11/2008 4:21 AM
To: Hallam-Baker, Phillip; [email-masked]
Subject: RE: New Version Notification for =
draft-hallambaker-ocspagility-02=20
=20
Phil,

=20

I have a few comments on the draft:

=20

This is more a nit, but I don't think the following is a compelling =
argument, strong enough to be mentioned:

o An implementation may intentionally wish to guard against the

possibility of a compromise resulting from a signature algorithm

compromise by employing two separate encryption algorithms.

=20

If an implementation is securing two co-dependent messages with two =
different algorithms, where breaking one of them successfully =
compromises the system, then you have increased your risk of compromise =
rather than reducing it.

=20

Further, I would like to see some explicit text, explaining that this =
approach is not applicable, or at least should not be used in =
combination with implementations of 5019.

Section 4.2. do state that the server can pre-produce several responses =
to the same request signed with different algorithms, but what I'm most =
concerned with is that clients including the extension in the request, =
in combination with RFC 5019 implementations may mess up http caching. =
Http caching is an important aspect of achieving scalability for LW =
OCSP.=20

=20

I would prefer to entirely discourage the use of this client extension =
with RFC 5019, but at least discuss the issue in the draft to make =
implementers aware of the problem.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Hallam-Baker, Phillip
Sent: den 2 december 2008 20:01
To: [email-masked]
Subject: FW: New Version Notification for =
draft-hallambaker-ocspagility-02=20

=20

=20

As promised at the meeting, here is an update to the OCSP agility draft.

With the WG and chair's permission I will resubmit as a WG draft.

The basic history here is that we tried to deploy an OCSP resolver that =
meets a pretty simple set of requirements for multiple algorithm support =
and found that the base specification does not actually say anything =
about how a response signature algorithm should be chosen, except that =
SHA-1 can be implemented.

So a perfectly legal OCSP responder could report the status of a public =
key certificate for an RSA signature key, signed with an RSA signature =
key with ECC.

And it gets worse, if you have an ocsp responder that is managing certs =
signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, =
etc. etc.) and a status request comes in for an unknown cert, there is =
no data for the responder to choose a reasonble response alg. You are =
forced to choose a lowest common denominator alg which is a problem if =
you moved to ECC because RSA 4096 does not cut it.

So this is a pretty simple fix to sort it out. I suggest that this goes =
on standards track and if we progress OCSP from PROPOSED to DRAFT we =
dump the explanatory part and merge the normative text in.

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Tue 12/2/2008 1:39 PM
To: Hallam-Baker, Phillip
Subject: New Version Notification for draft-hallambaker-ocspagility-02

A new version of I-D, draft-hallambaker-ocspagility-02.txt has been =
successfuly submitted by Phillip Hallam-Baker and posted to the IETF =
repository.

Filename: draft-hallambaker-ocspagility
Revision: 02
Title: OCSP Algorithm Agility
Creation_date: 2008-12-02
WG ID: Independent Submission
Number_of_pages: 8

Abstract:
The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.
=
=20

The IETF Secretariat.

------_=_NextPart_001_01C95B86.BC04481B
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: New Version Notification for draft-hallambaker-ocspagility-02 =

On the first issue, it depends on your implementation. =
If two signature algorithms are used and clients accept either then the =
result is to weaken the protection. If two algorithms are required and =
either clients are required to check both or there is a mechanism to =
disable use of a compromised algorithm the net result is stronger.

In the case of checking a cert chain and an OCSP validation chain the =
second considerations apply.

On the 5019 issue, happy to extend the draft, just preferred to get =
something in ASAP and need to get my head around the concerns first.

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

From: [email-masked] on behalf of Stefan Santesson

Sent: Thu 12/11/2008 4:21 AM

To: Hallam-Baker, Phillip; [email-masked]

Subject: RE: New Version Notification for =
draft-hallambaker-ocspagility-02

Phil,

I have a few comments on the draft:

This is more a nit, but I don't think the following is a compelling =
argument, strong enough to be mentioned:

o  An implementation may intentionally wish to guard =
against the

possibility of a compromise resulting =
from a signature algorithm

compromise by employing two separate =
encryption algorithms.

If an implementation is securing two co-dependent messages with two =
different algorithms, where breaking one of them successfully =
compromises the system, then you have increased your risk of compromise =
rather than reducing it.

Further, I would like to see some explicit text, explaining that this =
approach is not applicable, or at least should not be used in =
combination with implementations of 5019.

Section 4.2. do state that the server can pre-produce several responses =
to the same request signed with different algorithms, but what I'm most =
concerned with is that clients including the extension in the request, =
in combination with RFC 5019 implementations may mess up http caching. =
Http caching is an important aspect of achieving scalability for LW =
OCSP.

I would prefer to entirely discourage the use of this client extension =
with RFC 5019, but at least discuss the issue in the draft to make =
implementers aware of the problem.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: [email-masked] [mailto:owner-ietf-pkix@mail.=
imc.org] On Behalf Of Hallam-Baker, Phillip

Sent: den 2 december 2008 20:01

To: [email-masked]

Subject: FW: New Version Notification for =
draft-hallambaker-ocspagility-02

As promised at the meeting, here is an update to the OCSP agility =
draft.

With the WG and chair's permission I will resubmit as a WG draft.

The basic history here is that we tried to deploy an OCSP resolver that =
meets a pretty simple set of requirements for multiple algorithm support =
and found that the base specification does not actually say anything =
about how a response signature algorithm should be chosen, except that =
SHA-1 can be implemented.

So a perfectly legal OCSP responder could report the status of a public =
key certificate for an RSA signature key, signed with an RSA signature =
key with ECC.

And it gets worse, if you have an ocsp responder that is managing certs =
signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, =
etc. etc.) and a status request comes in for an unknown cert, there is =
no data for the responder to choose a reasonble response alg. You are =
forced to choose a lowest common denominator alg which is a problem if =
you moved to ECC because RSA 4096 does not cut it.

So this is a pretty simple fix to sort it out. I suggest that this goes =
on standards track and if we progress OCSP from PROPOSED to DRAFT we =
dump the explanatory part and merge the normative text in.

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

From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Tue 12/2/2008 1:39 PM

To: Hallam-Baker, Phillip

Subject: New Version Notification for =
draft-hallambaker-ocspagility-02

A new version of I-D, draft-hallambaker-ocspagility-02.txt has been =
successfuly submitted by Phillip Hallam-Baker and posted to the IETF =
repository.

Filename:        =
draft-hallambaker-ocspagility

Revision:        02

Title:           OCSP =
Algorithm Agility

Creation_date:   2008-12-02

WG ID:           =
Independent Submission

Number_of_pages: 8

Abstract:

The OSCP specification defined in RFC 2560 requires server responses

to be signed but does not specify a mechanism for selecting the

signature algorithm to be used leading to possible interoperability

failures in contexts where multiple signature algorithms are in use.

This document specifies an algorithm for server signature algorithm

selection and an extension that allows a client to advise a server

that specific signature algorithms are supported.

&=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;            =
;            =

The IETF Secretariat.

------_=_NextPart_001_01C95B86.BC04481B--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBAAxti001017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 03:10:59 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBBAAxqP001016; Thu, 11 Dec 2008 03:10:59 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBAAlNX000989 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 11 Dec 2008 03:10:58 -0700 (MST) (envelope-from [email-masked])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 11 Dec 2008 10:10:46 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 11 Dec 2008 10:10:35 +0000
From: Stefan Santesson
To: "Kemp, David P." , "[email-masked]"
Date: Thu, 11 Dec 2008 10:10:12 +0000
Subject: RE: Signing and Encrypting with the same key?
Thread-Topic: Signing and Encrypting with the same key?
Thread-Index: AclHM5GhiwsKjI5xQ6qgVyHzIVGcwwBiHg0QBK8KrkA=
Message-ID: <[email-masked]>
References: <[email-masked]> <51604CB892B44C39BAF60D61875EB21E@AndersPC> <[email-masked]>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

R3V5cywNCg0KSSBqdXN0IHJlYWxpemVkIHRoYXQgd2UgYWN0dWFsbHkgbWlnaHQgaGF2ZSBldm9s
dmVkIGFzIGEgY29tbXVuaXR5Lg0KDQpTb21lb25lIGFza2VkIGZvciB0aGUgdHJ1ZSBtZWFuaW5n
IG9mIG5vbi1yZXB1ZGlhdGlvbi4uLi4uLiBhbmQgdGhpcyBlLW1haWwgbGlzdCBkaWRuJ3QgZXhw
bG9kZS4NCg0KDQpTdGVmYW4gU2FudGVzc29uDQpTZW5pb3IgUHJvZ3JhbSBNYW5hZ2VyDQpXaW5k
b3dzIFNlY3VyaXR5LCBTdGFuZGFyZHMNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+IEZyb206IG93bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmcgW21haWx0bzpvd25lci1pZXRm
LQ0KPiBwa2l4QG1haWwuaW1jLm9yZ10gT24gQmVoYWxmIE9mIEtlbXAsIERhdmlkIFAuDQo+IFNl
bnQ6IGRlbiAxNyBub3ZlbWJlciAyMDA4IDE1OjA3DQo+IFRvOiBpZXRmLXBraXhAaW1jLm9yZw0K
PiBTdWJqZWN0OiBSRTogU2lnbmluZyBhbmQgRW5jcnlwdGluZyB3aXRoIHRoZSBzYW1lIGtleT8N
Cj4NCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBTdGVwaGVu
IFdpbHNvbg0KPiA+DQo+ID4gSSdkIGxpa2UgdG8ga25vdyB0aGUgcHJlY2lzZQ0KPiA+IGhpc3Rv
cnkgb2YgdGhlIE5SIGJpdCBpbiBYLjUwOS4gIFdobyBhY3R1YWxseSB0aG91Z2h0IG9mIGl0LCB3
ZXJlDQo+IHRoZXkNCj4gPiBhbiBlbmdpbmVlciBvciBhIGxhd3llciwgYW5kIHdoYXQgaWYgYW55
IGRlYmF0ZSB3ZW50IG9uIGF0IHRoZSB0aW1lPw0KPg0KPiBUcnVzdCBtZSwgeW91IHJlYWxseSwg
UkVBTExZIGRvbid0IHdhbnQgdG8ga25vdyA6LSkuDQo+DQo+IFRob3NlIG9uIG9uZSBzaWRlIG9m
IHRoZSBhcmd1bWVudCB0aG91Z2h0IHRoYXQgdGhlIE5SIGJpdCBzZXQgc2hvdWxkIGJlDQo+IHVz
ZWQgZm9yIHNpZ25hdHVyZXMgdGhhdCBjb3VsZCBiZSB2YWxpZGF0ZWQgaW5kZWZpbml0ZWx5IChp
LmUuIGZvciB3aGF0DQo+IG9uZSBub3JtYWxseSB0aGlua3Mgb2YgYXMgInNpZ25pbmciKSwgYW5k
IHNpZ25hdHVyZXMgd2l0aCB0aGUgTlIgYml0DQo+IGNsZWFyIGNvdWxkIGJlIHVzZWQgb25seSBm
b3Igc2Vzc2lvbiBhdXRoZW50aWNhdGlvbi4gIFRoYXQgd2F5IGEgc2lnbmVkDQo+IG9iamVjdCBj
cmVhdGVkIGFzIHBhcnQgb2YgYSBsb2dpbiBzZXNzaW9uIGNvdWxkIG5vdCBiZSBtaXNyZXByZXNl
bnRlZA0KPiBhcyBhIHNpZ25lZCBkb2N1bWVudC4NCj4NCj4gVGhvc2Ugb24gdGhlIG90aGVyIHNp
ZGUgdGhvdWdodCB0aGF0IHRoZSBOUiBiaXQgYWN0dWFsbHkgaGFkIHNvbWV0aGluZw0KPiB0byBk
byB3aXRoICJyZXB1ZGlhdGluZyIgc2lnbmF0dXJlcywgd2hpY2ggSU1ITyBpcyBhIHJpZGljdWxv
dXMgaWRlYQ0KPiBmb3IgdGhlIHJlYXNvbnMgeW91IHN1Z2dlc3QuICBUaG9zZSB3aG8gYmVsaWV2
ZSBpbiB0aGUgY3VycmVudCBYLjUwOQ0KPiBpbnRlcnByZXRhdGlvbiBtYXkgZGVmZW5kIGl0IGlm
IHRoZXkgd2lzaCwgb3Igc3BhcmUgdXMgdGhlIGRpc2N1c3Npb24uDQo+DQo+IERhdmUNCg==

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBB9MEBn097238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 02:22:14 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBB9MEFo097237; Thu, 11 Dec 2008 02:22:14 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBB9M2QQ097213 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 11 Dec 2008 02:22:13 -0700 (MST) (envelope-from [email-masked])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 11 Dec 2008 09:22:01 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 11 Dec 2008 09:22:01 +0000
From: Stefan Santesson
To: "Hallam-Baker, Phillip" , "[email-masked]"
Date: Thu, 11 Dec 2008 09:21:37 +0000
Subject: RE: New Version Notification for draft-hallambaker-ocspagility-02
Thread-Topic: New Version Notification for draft-hallambaker-ocspagility-02
Thread-Index: AclUrVTMVGC0OUj3RuOSZcazd8skDgAAWWYUAbAkkKA=
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AB5BBBECDEAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Phil,

I have a few comments on the draft:

This is more a nit, but I don't think the following is a compelling argumen=
t, strong enough to be mentioned:
o An implementation may intentionally wish to guard against the
possibility of a compromise resulting from a signature algorithm
compromise by employing two separate encryption algorithms.

If an implementation is securing two co-dependent messages with two differe=
nt algorithms, where breaking one of them successfully compromises the syst=
em, then you have increased your risk of compromise rather than reducing it=
.

Further, I would like to see some explicit text, explaining that this appro=
ach is not applicable, or at least should not be used in combination with i=
mplementations of 5019.
Section 4.2. do state that the server can pre-produce several responses to =
the same request signed with different algorithms, but what I'm most concer=
ned with is that clients including the extension in the request, in combina=
tion with RFC 5019 implementations may mess up http caching. Http caching i=
s an important aspect of achieving scalability for LW OCSP.

I would prefer to entirely discourage the use of this client extension with=
RFC 5019, but at least discuss the issue in the draft to make implementers=
aware of the problem.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On=
Behalf Of Hallam-Baker, Phillip
Sent: den 2 december 2008 20:01
To: [email-masked]
Subject: FW: New Version Notification for draft-hallambaker-ocspagility-02

As promised at the meeting, here is an update to the OCSP agility draft.

With the WG and chair's permission I will resubmit as a WG draft.

The basic history here is that we tried to deploy an OCSP resolver that mee=
ts a pretty simple set of requirements for multiple algorithm support and f=
ound that the base specification does not actually say anything about how a=
response signature algorithm should be chosen, except that SHA-1 can be im=
plemented.

So a perfectly legal OCSP responder could report the status of a public key=
certificate for an RSA signature key, signed with an RSA signature key wit=
h ECC.

And it gets worse, if you have an ocsp responder that is managing certs sig=
ned with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, etc. e=
tc.) and a status request comes in for an unknown cert, there is no data fo=
r the responder to choose a reasonble response alg. You are forced to choos=
e a lowest common denominator alg which is a problem if you moved to ECC be=
cause RSA 4096 does not cut it.

So this is a pretty simple fix to sort it out. I suggest that this goes on =
standards track and if we progress OCSP from PROPOSED to DRAFT we dump the =
explanatory part and merge the normative text in.

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Tue 12/2/2008 1:39 PM
To: Hallam-Baker, Phillip
Subject: New Version Notification for draft-hallambaker-ocspagility-02

A new version of I-D, draft-hallambaker-ocspagility-02.txt has been success=
fuly submitted by Phillip Hallam-Baker and posted to the IETF repository.

Filename: draft-hallambaker-ocspagility
Revision: 02
Title: OCSP Algorithm Agility
Creation_date: 2008-12-02
WG ID: Independent Submission
Number_of_pages: 8

Abstract:
The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.

The IETF Secretariat.

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

FW: New Version Notification for draft-hallambaker-ocspagility-02 </=
title>
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:690883177;
mso-list-type:hybrid;
mso-list-template-ids:902045572 69009409 69009411 69009413 69009409 690094=
11 69009413 69009409 69009411 69009413;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:38.25pt;
text-indent:-18.0pt;
font-family:Symbol;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US style=
=3D'font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Phil,<o:p></o:p></=
span></a></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>I have a few comments on the draft:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>This is more a nit, but I don’t think the following is=
a
compelling argument, strong enough to be mentioned:<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'page-break-before:always'><span lang=3DEN
style=3D'font-family:"Courier New"'>   o  An implementation =
may
intentionally wish to guard against the<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'page-break-before:always'><span lang=3DEN
style=3D'font-family:"Courier New"'>      possibil=
ity of
a compromise resulting from a signature algorithm<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'page-break-before:always'><span lang=3DEN
style=3D'font-family:"Courier New"'>      compromi=
se by
employing two separate encryption algorithms.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'page-break-before:always'><span lang=3DEN
style=3D'font-family:"Courier New"'><o:p> </o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:=
"Calibri","sans-serif";
color:#1F497D'>If an implementation is securing two co-dependent messages w=
ith
two different algorithms, where breaking one of them successfully compromis=
es
the system, then you have increased your risk of compromise rather than
reducing it.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:=
"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:=
"Calibri","sans-serif";
color:#1F497D'>Further, I would like to see some explicit text, explaining =
that
this approach is not applicable, or at least should not be used in combinat=
ion with
implementations of 5019.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:=
"Calibri","sans-serif";
color:#1F497D'>Section 4.2. do state that the server can pre-produce severa=
l
responses to the same request signed with different algorithms, but what I&=
#8217;m
most concerned with is that clients including the extension in the request,=
in
combination with RFC 5019 implementations may mess up http caching. Http
caching is an important aspect of achieving scalability for LW OCSP. <o:p><=
/o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:=
"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:=
"Calibri","sans-serif";
color:#1F497D'>I would prefer to entirely discourage the use of this client=
extension
with RFC 5019, but at least discuss the issue in the draft to make implemen=
ters
aware of the problem.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:=
"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:=
"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'col=
or:navy'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Hallam-Baker, Phi=
llip<br>
<b>Sent:</b> den 2 december 2008 20:01<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> FW: New Version Notification for
draft-hallambaker-ocspagility-02 <o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p> </o:p></p>

<p class=3DMsoNormal><o:p> </o:p></p>

<p style=3D'margin-bottom:12.0pt'><span style=3D'font-size:10.0pt'>As promi=
sed at
the meeting, here is an update to the OCSP agility draft.<br>
<br>
With the WG and chair's permission I will resubmit as a WG draft.<br>
<br>
<br>
The basic history here is that we tried to deploy an OCSP resolver that mee=
ts a
pretty simple set of requirements for multiple algorithm support and found =
that
the base specification does not actually say anything about how a response
signature algorithm should be chosen, except that SHA-1 can be implemented.=
<br>
<br>
<br>
So a perfectly legal OCSP responder could report the status of a public key
certificate for an RSA signature key, signed with an RSA signature key with=
ECC.<br>
<br>
And it gets worse, if you have an ocsp responder that is managing certs sig=
ned
with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, etc. etc.)=
and
a status request comes in for an unknown cert, there is no data for the
responder to choose a reasonble response alg. You are forced to choose a lo=
west
common denominator alg which is a problem if you moved to ECC because RSA 4=
096
does not cut it.<br>
<br>
<br>
So this is a pretty simple fix to sort it out. I suggest that this goes on
standards track and if we progress OCSP from PROPOSED to DRAFT we dump the
explanatory part and merge the normative text in.<br>
<br>
<br>
-----Original Message-----<br>
From: IETF I-D Submission Tool [<a href=3D"mailto:[email-masked]">ma=
ilto:[email-masked]</a>]<br>
Sent: Tue 12/2/2008 1:39 PM<br>
To: Hallam-Baker, Phillip<br>
Subject: New Version Notification for draft-hallambaker-ocspagility-02<br>
<br>
<br>
A new version of I-D, draft-hallambaker-ocspagility-02.txt has been success=
fuly
submitted by Phillip Hallam-Baker and posted to the IETF repository.<br>
<br>
Filename:
draft-hallambaker-ocspagility<br>
Revision:        02<br>
Title:           OCSP Algorith=
m
Agility<br>
Creation_date:   2008-12-02<br>
WG ID:           Independent
Submission<br>
Number_of_pages: 8<br>
<br>
Abstract:<br>
The OSCP specification defined in RFC 2560 requires server responses<br>
to be signed but does not specify a mechanism for selecting the<br>
signature algorithm to be used leading to possible interoperability<br>
failures in contexts where multiple signature algorithms are in use.<br>
This document specifies an algorithm for server signature algorithm<br>
selection and an extension that allows a client to advise a server<br>
that specific signature algorithms are supported.<br>
&nb=
sp;            =
&nb=
sp;            =
&nb=
sp;            =
<br>
<br>
<br>
The IETF Secretariat.<br>
<br>
<br>
<br>
<br>
<br>
</span><o:p></o:p></p>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D321AB5BBBECDEAEXMSGC332eu_--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBACsh4k030003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 05:54:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBACshSo030002; Wed, 10 Dec 2008 05:54:43 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBACsW73029992 for <[email-masked]>; Wed, 10 Dec 2008 05:54:43 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[198.18.173.171]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[email-masked]>) id 1LAOaF-000750-Fc for [email-masked]; Wed, 10 Dec 2008 07:54:32 -0500
Mime-Version: 1.0
Message-Id: <p06240803c5656bd359f2@[198.18.173.171]>
Date: Wed, 10 Dec 2008 07:52:22 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: minutes posted
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>

I have received comments from 2 sources, and made the requested
changes. Since over two weeks have elapsed, I am posting final
meeting minutes.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB8MOXVL005036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 15:24:33 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB8MOX0k005035; Mon, 8 Dec 2008 15:24:33 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB8MOLGd005027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[email-masked]>; Mon, 8 Dec 2008 15:24:32 -0700 (MST) (envelope-from [email-masked])
Received: from newblitzen.Dartmouth.EDU (newblitzen.dartmouth.edu [129.170.208.36]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id mB8MC1pr019217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[email-masked]>; Mon, 8 Dec 2008 17:24:11 -0500
X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system.
Received: from dhcp-212-179.cs.dartmouth.edu [129.170.212.179] by newblitzen.Dartmouth.EDU (Mac) via SMTP for [email-masked] id <138037849>; 08 Dec 2008 17:24:10 -0500
Message-ID: <[email-masked]>
Date: Mon, 08 Dec 2008 17:24:10 -0500
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-prqp-02.txt
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090101050805030202040209"
X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU
X-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

Hi all,

I just published the new version of the draft. The main difference is the DHCP
section where we now have the definition for DHCPv4 *and* DHCPv6 options. I am
waiting on the input from the DHC WG.

Please let me know if any of you have further comments on this version of the
I-D.

Cheers,
Max

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
[...]
> Title : PKI Resource Query Protocol (PRQP)
> Author(s) : M. Pala
> Filename : draft-ietf-pkix-prqp-02.txt
> Pages : 35
> Date : 2008-12-08
>
> One of the most strategic problems still open in PKIX is locating
> public data and services associated with a Certification Authority
> (CA). This issue impacts interoperability and usability in PKIX.
>
> This draft describes the PKI Resource Query Protocol (PRQP), its
> design, definition, and its impact in already deployed PKIX
> protocols.

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

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

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB8LTux6002072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 14:29:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB8LTuaN002071; Mon, 8 Dec 2008 14:29:56 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB8LTuCg002064 for <[email-masked]>; Mon, 8 Dec 2008 14:29:56 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id 3A2713A6823; Mon, 8 Dec 2008 13:30:00 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-prqp-02.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Mon, 8 Dec 2008 13:30:01 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

Title : PKI Resource Query Protocol (PRQP)
Author(s) : M. Pala
Filename : draft-ietf-pkix-prqp-02.txt
Pages : 35
Date : 2008-12-08

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

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

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

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

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

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

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

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB3F079A067746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2008 08:00:07 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB3F07W1067745; Wed, 3 Dec 2008 08:00:07 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB3ExtLa067684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[email-masked]>; Wed, 3 Dec 2008 08:00:06 -0700 (MST) (envelope-from [email-masked])
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id mB3EcgxD021587; Wed, 3 Dec 2008 06:38:55 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 06:59:46 -0800
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_01C95557.C80AEC9A"
Subject: RE: OCSP Responder Status
Date: Wed, 3 Dec 2008 06:59:46 -0800
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: OCSP Responder Status
Thread-Index: AclPKVyaoEzDsqQFQU2YNjZS85ShHgGLJezN
References: <[email-masked]> <[email-masked]> <BBE6D91086994FFD98961A6911B831BC@ASCUK001> <[email-masked]>
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Timothy J. Miller" <[email-masked]>, "Liaquat Khan" <[email-masked]>
Cc: "Johannes Merkle" <[email-masked]>, "Mauricio Balassiano" <[email-masked]>, <[email-masked]>
X-OriginalArrivalTime: 03 Dec 2008 14:59:46.0856 (UTC) FILETIME=[C858FA80:01C95557]
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C95557.C80AEC9A
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The trusted responder model makes no sense to me unless you are =
delegating the complete trust decision to an external resource as in =
SCVP. Which is of course why some of us suggested SCVP be an OCSP =
extension.
=20
If we were going to do anything more in this area (and I don't think we =
should), we should implement the only trusted responder delegation that =
makes any sense to me at all and that is where the trusted responder is =
responsible for verifying the key in its entirety.
=20
If you are doing delegated trust with a PKI capable endpoint device the =
computational task of path math is a diminishing concer. The problem of =
management of the trusted certificate base and security policy is the =
bigger and increasing part of the problem.
=20
So if we were to address this point I would suggest doing it through a =
profile on SCVP, and SCVP-Lite profile, in which the client provides no =
input into the request other than describing what it wants to DO. That =
means no talk of trust roots and paths and such. Just 'X wants to do Y =
with Z, give me the key and the algorithm context to use'
=20
=20
In other words, SCVP-Lite is XKMS but fixing the mistake we made by =
making XKMS specific to public key.=20
=20
If XKMS could deliver either a symmetric key OR a public key, then you =
can have a mode of communication where the XKMS server is also operating =
as a kerberos key server.=20
=20
Now that I am interested in devices that cannot support ethernet, cannot =
support IP and certainly cannot support public key (no not even ECC =
variants), I am starting to see interesting advantages you can achieve =
by using a blend of symmetric and public key techniques rather than the =
traditional approach of letting PKI do al the glamorous trusty stuff and =
then confining symmetric key to just a bunch of session key stuff.
=20
=20

________________________________

From: [email-masked] on behalf of Timothy J. Miller
Sent: Tue 11/25/2008 12:17 PM
To: Liaquat Khan
Cc: 'Johannes Merkle'; 'Mauricio Balassiano'; [email-masked]
Subject: Re: OCSP Responder Status

Liaquat Khan wrote:
> The problem with your option 3 is that RFC2560 doesn't explain how a =
client
> can check that the second responder is acting on behalf of the first =
CA.
> I.e. it may chain to a trust anchor, allowing you to verify the =
signature on
> the OCSP response, but how do you know that the original CA actually
> authorised this second responder to provide status information on the =
first
> responder's certificate?

That's what client configuration control is for. :) That's the whole
point of the trusted responder model--trust in that responder is
established out-of-band (i.e., not part of the OCSP protocol).

> If you are happy to live without this check then this can work, =
however I
> have not really seen this method actual used (probably because it =
introduces
> more complexity than the benefit it offers).=20

The DoD OCSP service uses the trusted responder model. It's a real PITA
to manage; you have to make sure all the RPs are properly configured.
Key changing under this model is even worse; the hoops we had to jump
through were seriously sick.

We're now migrating to the CA designated model. The CA-issued OCSP
signing certs will be short-lived certs with longer-lived keys (IIRC, 30
day cert life with renewal allowed for some period of time).

-- Tim

------_=_NextPart_001_01C95557.C80AEC9A
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>Re: OCSP Responder Status
=0A=
=0A=
=0A=
=0A=

=0A=

The trusted =
responder model makes no sense to me unless you are delegating the =
complete trust decision to an external resource as in SCVP. Which is of =
course why some of us suggested SCVP be an OCSP extension.
=0A=

=0A=

If we were going to do =
anything more in this area (and I don't think we should), we should =
implement the only trusted responder delegation that makes any sense to =
me at all and that is where the trusted responder is responsible for =
verifying the key in its entirety.
=0A=

=0A=

If you are doing delegated =
trust with a PKI capable endpoint device the computational task of path =
math is a diminishing concer. The problem of management of the trusted =
certificate base and security policy is the bigger and increasing part =
of the problem.
=0A=

=0A=

So if we were to address this =
point I would suggest doing it through a profile on SCVP, and SCVP-Lite =
profile, in which the client provides no input into the request other =
than describing what it wants to DO. That means no talk of trust roots =
and paths and such. Just 'X wants to do Y with Z, give me the key and =
the algorithm context to use'
=0A=

=0A=

=0A=

In other words, SCVP-Lite is =
XKMS but fixing the mistake we made by making XKMS specific to public =
key.
=0A=

=0A=

If XKMS could deliver either =
a symmetric key OR a public key, then you can have a mode of =
communication where the XKMS server is also operating as a kerberos key =
server.
=0A=

=0A=

Now that I am interested in =
devices that cannot support ethernet, cannot support IP and certainly =
cannot support public key (no not even ECC variants), I am starting to =
see interesting advantages you can achieve by using a blend of symmetric =
and public key techniques rather than the traditional approach of =
letting PKI do al the glamorous trusty stuff and then confining =
symmetric key to just a bunch of session key stuff.

=0A=

=0A=

=0A=

=0A=
=0A=
From: [email-masked] =
on behalf of Timothy J. Miller
Sent: Tue 11/25/2008 12:17 =
PM
To: Liaquat Khan
Cc: 'Johannes Merkle'; 'Mauricio =
Balassiano'; [email-masked]
Subject: Re: OCSP Responder =
Status

=0A=

=0A=

Liaquat Khan wrote:
> The problem with your =
option 3 is that RFC2560 doesn't explain how a client
> can check =
that the second responder is acting on behalf of the first CA.
> =
I.e. it may chain to a trust anchor, allowing you to verify the =
signature on
> the OCSP response, but how do you know that the =
original CA actually
> authorised this second responder to provide =
status information on the first
> responder's =
certificate?

That's what client configuration control is =
for.  :)  That's the whole
point of the trusted responder =
model--trust in that responder is
established out-of-band (i.e., not =
part of the OCSP protocol).

> If you are happy to live without =
this check then this can work, however I
> have not really seen =
this method actual used (probably because it introduces
> more =
complexity than the benefit it offers).

The DoD OCSP =
service uses the trusted responder model.  It's a real PITA
to =
manage; you have to make sure all the RPs are properly =
configured.
Key changing under this model is even worse; the hoops we =
had to jump
through were seriously sick.

We're now migrating =
to the CA designated model.  The CA-issued OCSP
signing certs =
will be short-lived certs with longer-lived keys (IIRC, 30
day cert =
life with renewal allowed for some period of time).

-- =
Tim

------_=_NextPart_001_01C95557.C80AEC9A--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB33Qfcq031238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 20:26:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB33Qfbj031237; Tue, 2 Dec 2008 20:26:41 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB33QTbu031226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Dec 2008 20:26:40 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.1.102] (dslstat-77-ppp-125.fastq.com [65.39.77.125] (may be forged)) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id mB33T2Hj010327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Dec 2008 20:29:03 -0700
Cc:
Message-Id:
From: Michael Myers
To: "Hallam-Baker, Phillip"
In-Reply-To: <[email-masked]>
Content-Type: multipart/alternative; boundary=Apple-Mail-4-859484553
Mime-Version: 1.0 (Apple Message framework v912)
Subject: Re: New Version Notification for draft-hallambaker-ocspagility-02
Date: Tue, 2 Dec 2008 20:26:27 -0700
References: <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.912)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--Apple-Mail-4-859484553
Content-Type: text/plain;
charset=US-ASCII;
format=flowed;
delsp=yes
Content-Transfer-Encoding: 7bit

Phil,

I will give it a read and comment accordingly.

Mike

On Dec 2, 2008, at 12:01 PM, Hallam-Baker, Phillip wrote:

>
> As promised at the meeting, here is an update to the OCSP agility
> draft.
>
> With the WG and chair's permission I will resubmit as a WG draft.
>
>
> The basic history here is that we tried to deploy an OCSP resolver
> that meets a pretty simple set of requirements for multiple
> algorithm support and found that the base specification does not
> actually say anything about how a response signature algorithm
> should be chosen, except that SHA-1 can be implemented.
>
>
> So a perfectly legal OCSP responder could report the status of a
> public key certificate for an RSA signature key, signed with an RSA
> signature key with ECC.
>
> And it gets worse, if you have an ocsp responder that is managing
> certs signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-
> ECC, DSA, etc. etc.) and a status request comes in for an unknown
> cert, there is no data for the responder to choose a reasonble
> response alg. You are forced to choose a lowest common denominator
> alg which is a problem if you moved to ECC because RSA 4096 does not
> cut it.
>
>
> So this is a pretty simple fix to sort it out. I suggest that this
> goes on standards track and if we progress OCSP from PROPOSED to
> DRAFT we dump the explanatory part and merge the normative text in.
>

--Apple-Mail-4-859484553
Content-Type: text/html;
charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Phil,

I will give it a read and =
comment accordingly.

Mike

On Dec 2, 2008, =
at 12:01 PM, Hallam-Baker, Phillip wrote:

=

As =
promised at the meeting, here is an update to the OCSP agility =
draft.

With the WG and chair's permission I will resubmit as a =
WG draft.

The basic history here is that we tried to =
deploy an OCSP resolver that meets a pretty simple set of requirements =
for multiple algorithm support and found that the base specification =
does not actually say anything about how a response signature algorithm =
should be chosen, except that SHA-1 can be implemented.

So =
a perfectly legal OCSP responder could report the status of a public key =
certificate for an RSA signature key, signed with an RSA signature key =
with ECC.

And it gets worse, if you have an ocsp responder that =
is managing certs signed with umpteen different algs (RSA-SHA1, =
RSA-SHA256, RSA-ECC, DSA, etc. etc.) and a status request comes in for =
an unknown cert, there is no data for the responder to choose a =
reasonble response alg. You are forced to choose a lowest common =
denominator alg which is a problem if you moved to ECC because RSA 4096 =
does not cut it.

So this is a pretty simple fix to sort it =
out. I suggest that this goes on standards track and if we progress OCSP =
from PROPOSED to DRAFT we dump the explanatory part and merge the =
normative text in.

=

=

--Apple-Mail-4-859484553--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2J1ZgE002491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 12:01:35 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB2J1Zhr002490; Tue, 2 Dec 2008 12:01:35 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2J1Ohh002466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 2 Dec 2008 12:01:34 -0700 (MST) (envelope-from [email-masked])
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id mB2IeXUW018946 for ; Tue, 2 Dec 2008 10:40:33 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 11:01:23 -0800
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_01C954B0.5E07FC46"
Subject: FW: New Version Notification for draft-hallambaker-ocspagility-02
Date: Tue, 2 Dec 2008 11:01:22 -0800
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: New Version Notification for draft-hallambaker-ocspagility-02
Thread-Index: AclUrVTMVGC0OUj3RuOSZcazd8skDgAAWWYU
References: <[email-masked]>
From: "Hallam-Baker, Phillip"
To:
X-OriginalArrivalTime: 02 Dec 2008 19:01:23.0247 (UTC) FILETIME=[5E74F3F0:01C954B0]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C954B0.5E07FC46
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

As promised at the meeting, here is an update to the OCSP agility draft.

With the WG and chair's permission I will resubmit as a WG draft.

The basic history here is that we tried to deploy an OCSP resolver that =
meets a pretty simple set of requirements for multiple algorithm support =
and found that the base specification does not actually say anything =
about how a response signature algorithm should be chosen, except that =
SHA-1 can be implemented.

So a perfectly legal OCSP responder could report the status of a public =
key certificate for an RSA signature key, signed with an RSA signature =
key with ECC.=20

And it gets worse, if you have an ocsp responder that is managing certs =
signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, =
etc. etc.) and a status request comes in for an unknown cert, there is =
no data for the responder to choose a reasonble response alg. You are =
forced to choose a lowest common denominator alg which is a problem if =
you moved to ECC because RSA 4096 does not cut it.

So this is a pretty simple fix to sort it out. I suggest that this goes =
on standards track and if we progress OCSP from PROPOSED to DRAFT we =
dump the explanatory part and merge the normative text in.

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Tue 12/2/2008 1:39 PM
To: Hallam-Baker, Phillip
Subject: New Version Notification for draft-hallambaker-ocspagility-02=20
=20

A new version of I-D, draft-hallambaker-ocspagility-02.txt has been =
successfuly submitted by Phillip Hallam-Baker and posted to the IETF =
repository.

Filename: draft-hallambaker-ocspagility
Revision: 02
Title: OCSP Algorithm Agility
Creation_date: 2008-12-02
WG ID: Independent Submission
Number_of_pages: 8

Abstract:
The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.
=
=20

The IETF Secretariat.

------_=_NextPart_001_01C954B0.5E07FC46
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

FW: New Version Notification for draft-hallambaker-ocspagility-02 =

As promised at the meeting, here is an update to the =
OCSP agility draft.

With the WG and chair's permission I will resubmit as a WG draft.

The basic history here is that we tried to deploy an OCSP resolver that =
meets a pretty simple set of requirements for multiple algorithm support =
and found that the base specification does not actually say anything =
about how a response signature algorithm should be chosen, except that =
SHA-1 can be implemented.

So a perfectly legal OCSP responder could report the status of a public =
key certificate for an RSA signature key, signed with an RSA signature =
key with ECC.

And it gets worse, if you have an ocsp responder that is managing certs =
signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, =
etc. etc.) and a status request comes in for an unknown cert, there is =
no data for the responder to choose a reasonble response alg. You are =
forced to choose a lowest common denominator alg which is a problem if =
you moved to ECC because RSA 4096 does not cut it.

So this is a pretty simple fix to sort it out. I suggest that this goes =
on standards track and if we progress OCSP from PROPOSED to DRAFT we =
dump the explanatory part and merge the normative text in.

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

From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Tue 12/2/2008 1:39 PM

To: Hallam-Baker, Phillip

Subject: New Version Notification for =
draft-hallambaker-ocspagility-02

A new version of I-D, draft-hallambaker-ocspagility-02.txt has been =
successfuly submitted by Phillip Hallam-Baker and posted to the IETF =
repository.

Filename:        =
draft-hallambaker-ocspagility

Revision:        02

Title:           OCSP =
Algorithm Agility

Creation_date:   2008-12-02

WG ID:           =
Independent Submission

Number_of_pages: 8

Abstract:

The OSCP specification defined in RFC 2560 requires server responses

to be signed but does not specify a mechanism for selecting the

signature algorithm to be used leading to possible interoperability

failures in contexts where multiple signature algorithms are in use.

This document specifies an algorithm for server signature algorithm

selection and an extension that allows a client to advise a server

that specific signature algorithms are supported.

&=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;            =
;            =

The IETF Secretariat.

------_=_NextPart_001_01C954B0.5E07FC46--