Subject: NEw Defect report and DTC on Name Constraints

From: Hoyt L Kesterson II <[email-masked]>
Date: Fri, 30 Sep 2005 12:12:05 -0700

A new defect report, DR 214, has been posted to the server
at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/AllDefectReports/DR_314.pdf

Two DTCs have been sent to the Secretariat for balloting. The one
for the 4th edition is at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/Closing%20January%202006/X.509DTC-10(4th).pdf

The one for the 5th edition (scheduled for publishing at the end
of 2005) is at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/Closing%20January%202006/X.509DTC-1(5th).pdf

I will let you know what the ballot close date is when it is set
by the SC6 Secretariat

hoyt

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9167X78050378; Fri, 30 Sep 2005 23:07:34 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9167XSJ050377; Fri, 30 Sep 2005 23:07:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from smtpauth06.mail.atl.earthlink.net (smtpauth06.mail.atl.earthlink.net [209.86.89.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9167XWo050371 for ; Fri, 30 Sep 2005 23:07:33 -0700 (PDT) (envelope-from [email-masked])
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=MIhRhf8bFbM8JQeMrx1Akh4h/aNz2xNwisvIDtLSpOL2fGI52+pfQuZA641Bmh/m; h=Received:Mime-Version:Message-Id:Date:To:From:Subject:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [130.13.80.76] (helo=[192.168.0.3]) by smtpauth06.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1ELaWj-00031Z-Fo; Sat, 01 Oct 2005 02:07:17 -0400
Mime-Version: 1.0
Message-Id:
Date: Fri, 30 Sep 2005 23:07:06 -0700
To: "X.509":;
From: Hoyt L Kesterson II
Subject: DR 314 - New Defect report and DTC on Name Constraints
Content-Type: text/html; charset="us-ascii"
X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47808daa5b3e7ca120f7254c95654298909e5231b431cb7c002350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 130.13.80.76
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

DR 314 - New Defect report and DTC on Name
Constraints

I meant DR 314. The referenced files were correct; the error
occurred only in the body of the email.

A new defect report, DR 214, has been posted to the server
at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/AllDefectReports/DR_314.pdf

Two DTCs have been sent to the Secretariat for balloting. The one
for the 4th edition is at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/Closing%20January%202006/X.509DTC-10(4th).pdf

The one for the 5th edition (scheduled for publishing at the end
of 2005) is at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/Closing%20January%202006/X.509DTC-1(5th).pdf

I will let you know what the ballot close date is when it is set
by the SC6 Secretariat

hoyt

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UJHeCg009687; Fri, 30 Sep 2005 12:17:40 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8UJHeq1009686; Fri, 30 Sep 2005 12:17:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from smtpauth01.mail.atl.earthlink.net (smtpauth01.mail.atl.earthlink.net [209.86.89.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UJHe96009680 for ; Fri, 30 Sep 2005 12:17:40 -0700 (PDT) (envelope-from [email-masked])
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=LorJmQQJABM9R6MtcGH24H7+vOIyHDXLLHXjogXE63xenNXcUpx5FkbLtsDx2Vfo; h=Received:Mime-Version:Message-Id:Date:To:From:Subject:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [130.13.80.76] (helo=[192.168.0.3]) by smtpauth01.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1ELQO3-0002uV-D0; Fri, 30 Sep 2005 15:17:39 -0400
Mime-Version: 1.0
Message-Id:
Date: Fri, 30 Sep 2005 12:12:05 -0700
To: "X.509":;
From: Hoyt L Kesterson II
Subject: NEw Defect report and DTC on Name Constraints
Content-Type: text/html; charset="us-ascii"
X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47808daa5b3e7ca120fb4e11c6ca0281361c500519213926dd2350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 130.13.80.76
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

NEw Defect report and DTC on Name
Constraints

A new defect report, DR 214, has been posted to the server
at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/AllDefectReports/DR_314.pdf

Two DTCs have been sent to the Secretariat for balloting. The one
for the 4th edition is at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/Closing%20January%202006/X.509DTC-10(4th).pdf

The one for the 5th edition (scheduled for publishing at the end
of 2005) is at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/Closing%20January%202006/X.509DTC-1(5th).pdf

I will let you know what the ballot close date is when it is set
by the SC6 Secretariat

hoyt

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UIl1Gl006632; Fri, 30 Sep 2005 11:47:01 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8UIl1iH006631; Fri, 30 Sep 2005 11:47:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from sfdmzmailmx02.bankofamerica.com (sfmx02.bankofamerica.com [171.159.64.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UIl1Rk006625 for ; Fri, 30 Sep 2005 11:47:01 -0700 (PDT) (envelope-from [email-masked])
Received: from sfdmzmailmx03.bankofamerica.com ([171.182.72.79]) by sfdmzmailmx02.bankofamerica.com (8.12.11/8.12.11) with ESMTP id j8UIiQfZ032042; Fri, 30 Sep 2005 18:44:31 GMT
Received: from memscmpl3. (casfodc07s889.bankofamerica.com [165.48.14.226]) by sfdmzmailmx03.bankofamerica.com (8.12.11/8.12.11) with SMTP id j8UIiPFR014974; Fri, 30 Sep 2005 18:44:25 GMT
Received: from memmta0202 (171.186.107.205) by memscmpl3. (Sigaba Gateway v3.6.1) with ESMTP id 248477104; Fri, 30 Sep 2005 11:44:25 -0700
Date: Fri, 30 Sep 2005 11:44:16 -0700
From: "Hicks, Mack"
Subject: Mack Hicks retires f/ Bank of America becomes CTO of Identrus
To: [email-masked]
Message-id:
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-type: multipart/alternative; boundary="Boundary_(ID_dU64IhXapem2+Zn5dNuS9w)"
Content-class: urn:content-classes:message
Thread-topic: Mack Hicks retires f/ Bank of America becomes CTO of Identrus
Thread-index: AcXF7vW3Cla/8WnsSTCuIOC28BXczQ==
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-OriginalArrivalTime: 30 Sep 2005 18:44:25.0284 (UTC) FILETIME=[FAEFE040:01C5C5EE]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

--Boundary_(ID_dU64IhXapem2+Zn5dNuS9w)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

Friends,

Today Friday 30 Sept 2005, is my last day at Bank of America. I am
retiring as Senior Vice President in Corporate Information Security. I
have had great fun here since 24 Sept 1979 (my birthday). It was all of
you (on the bcc) that made it possible. Thank you for letting me be
part of your life

I have moved on as well. I still live in Palm Springs, and I really do
enjoy the desert. But an opportunity came up that I could not pass up.
I worked with Identrus in the late 1990's; actually, the idea, creation,
and design of Identrus as a large part of my life during the 1990's.

I am the Chief Technology Officer of Identrus. There is so much that
they can offer, and I think, that I make a serious contribution there.
So keep in touch about Identrus.

Personally, I will be spending a great deal of time in San Francisco
(Identrus HQ) as well as at my home in Palm Springs. I expect to become
active in several identity management forums and look forward to seeing
you all in the future.

My office/home phone in Palm Springs is: 760-318-9345
My new cell phone is: 760-799-9815
My new work email address is: [email-masked]
My snail mail: Mack Hicks, 1717 E Vista Chino Ste 7 PMB 221, Palm
Springs, CA 92262 USA

Mack Hicks, SVP 760-318-9345
Bank of America Corporate Information Security

PS: I will not get any reply at this email address - last day ya know -
and I got trapped by password changes and a brief illness (serious food
poisoning "campyflobacter bacteria" - so that this note is a bit late -
sorry. I am recovering how, but for a moment - it was close. On to
life!

--Boundary_(ID_dU64IhXapem2+Zn5dNuS9w)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: quoted-printable

Mack Hicks retires f/ Bank of America becomes CTO of =
Identrus

Friends,

Today Friday =
30 =
Sept 2005, is =
my last day at Bank of America.  I am retiring as Senior Vice =
President in Corporate Information Security.  =
I have had great fun here =
since 24 Sept =
1979 (my birthday).  It was =
all of you (on the bcc) that made it possible.  Thank you for =
letting me be part of your life

I have moved on as well.  =
I still =
live in Palm Springs, =
and I really do enjoy the desert.  But an opportunity came up that =
I could not pass up.  I worked with Identrus in the late =
1990’s; actually, the idea, creation, and =
design of Identrus as a large part of my life during =
the 1990’s.

I =
am =
the Chief Technology Officer of Identrus.  There is so much that they can offer, and I think, that I =
make a serious contribution there.  So keep in touch =
about Identrus.

Personally, I will be spending a great deal =
of time in San Francisco (Identrus HQ) as =
well as at =
my home in Palm =
Springs.  I expect to become active in several identity management =
forums and look forward to seeing you all in the =
future.

My office/home phone in Palm Springs =
is:  760-318-9345

My new cell phone is:  =
760-799-9815

My new work email address =
is:  [email-masked]

My snail mail:   Mack Hicks, 1717 E =
Vista Chino Ste 7 PMB 221, Palm Springs, CA 92262 USA

Mack =
Hicks, SVP   760-318-9345

Bank of America Corporate Information =
Security

PS:  =
I will not get any =
reply at this email address =
– last day ya know – and I got trapped by password changes =
and a brief illness (serious food poisoning =
“campyflobacter bacteria” – so that this note is a bit late =
– sorry.  I am =
recovering how, but =
for a moment – it was close.  On to life!

=

--Boundary_(ID_dU64IhXapem2+Zn5dNuS9w)--

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UAZ1bn064712; Fri, 30 Sep 2005 03:35:01 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8UAZ1kb064711; Fri, 30 Sep 2005 03:35:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8UAYx7O064700 for ; Fri, 30 Sep 2005 03:35:00 -0700 (PDT) (envelope-from [email-masked])
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j8UAYwi00722; Fri, 30 Sep 2005 12:34:58 +0200 (MEST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Fri, 30 Sep 2005 12:34:58 +0200 (MET DST)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id MAA09903; Fri, 30 Sep 2005 12:34:57 +0200 (MET DST)
Message-ID: <[email-masked]>
Date: Fri, 30 Sep 2005 12:34:57 +0200
From: Peter Sylvester
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman
CC: [email-masked]
Subject: Re: draft-ietf-pkix-srvsan-00
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020704050602050600080500"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a cryptographically signed message in MIME format.

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

>>
>> Could you give an example of such a null terminated label.
>
>
> DNS names are binary blobs. Most of them have the semantics of ASCII
> characters, but not all of them. 'Twas ever thus. This rule is for all
> DNS records, not just SRV records.

DNS names are not binary blobs, they are null terminated labels for
which at least a subset
of 7bit ascii is defined as characters AND in practice, you cannot have
labels that have
dots in it etc. and you have ACE for domain names etc.

It is indeed true that the specification allows for 8 bits (255 combination)
without saying what they mean.

But I have aked you to give an example of an actual documented and
specified use
that uses 8 bits where the data are not en encoding of some string.

>
>> The text of this RFC is ASCII, there is no indication whether the
>> example
>> in the text is in another character set.
>
>
> The character set of the RFC is irrelevant.

That's what I say, since it uses only ASCII, and nothing else
about the examples and specs, in particular nothing that
would allow to use iso-latin1 or utf8 in the examples,

RFC 3490 says:

If a signaling system which makes negotiation possible between old
and new DNS clients and servers is standardized in the future, the
encoding of the query in the DNS protocol itself can be changed from
ACE to something else, such as UTF-8. The question whether or not
this should be used is, however, a separate problem and is not
discussed in this memo.

This means IMO that the labels are not binary blobs but encoded
characters depending on a possibly negotiatable encoding
rule. Thus the raw encoding in the request cannot be interpreted
without knowledge of the encoding types. "This octet string contains
an ACE encoded domain name / it encodes an UTF8 encoded name."

IMO this gives sufficient arguments not to use an uninterpretable
OCTET STRING encoding, but rather to use a string type.

UTF8 vs IA5text. I don't care too much because contrary to the
content in the DNS we have a tag indicating the type

If compatiblity with the dNSName subjectAltname is an issue then
I think IA5 may be simpler.

We probably will see ACE encoded names inside UTF8.

Peter

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

--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

--------------ms020704050602050600080500
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwOTMwMTAzNDU3WjAjBgkqhkiG9w0B
CQQxFgQUZpL6IqtbhCMCcPBXjG3z714zRJAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAQ+JamjVIfUof6gH5
fOzRXT+etXbctWVRLRoMXS6lXmj7fK33wnVXwhbBrh2u6qlJSMRoxIdVrGkoTG2cqTycsouF
6EOu5KoEw7FlOJwbflpP94PLIgRNd2krnQ57liyI8Z/LmDNYBs+dDBCSfX6/m+h6nGgLpdEi
b1tKncSYH30AAAAAAAA=
--------------ms020704050602050600080500--

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8U4Id21028948; Thu, 29 Sep 2005 21:18:39 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8U4IdLV028947; Thu, 29 Sep 2005 21:18:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8U4IcQ2028924 for ; Thu, 29 Sep 2005 21:18:38 -0700 (PDT) (envelope-from [email-masked])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8U4IRgV022108 for ; Fri, 30 Sep 2005 00:18:27 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8U4IR2V103850 for ; Fri, 30 Sep 2005 00:18:27 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j8U4IQKC018385 for ; Fri, 30 Sep 2005 00:18:26 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j8U4IQdK018382; Fri, 30 Sep 2005 00:18:26 -0400
In-Reply-To:
To: Paul Hoffman
Cc: [email-masked], Peter Sylvester
MIME-Version: 1.0
Subject: Re: draft-ietf-pkix-srvsan-00
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin
Message-ID:
Date: Fri, 30 Sep 2005 00:18:24 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 09/30/2005 00:18:25, Serialize complete at 09/30/2005 00:18:25
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8U4IcQ2028933
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul:

The character set of the RFC is irrelevant, but the character set
of DNS, RFC 822, and URI name constraints is not irrelevant. These fields
do contain DNS names, they are formatted as character strings, and their
primary use is to be compared to certificate fields which are then
compared to DNS names. If one cannot compare the dNSName member of
GeneralName (currently an IA5String) to a DNS name, what good is that
member?

Tom Gindin

Paul Hoffman
Sent by: [email-masked]
09/29/2005 10:11 AM

To: Peter Sylvester
cc: [email-masked]
Subject: Re: draft-ietf-pkix-srvsan-00

At 1:52 PM +0200 9/29/05, Peter Sylvester wrote:
>Paul Hoffman wrote:
>
>>
>>At 11:23 AM +0200 9/25/05, Michael Ströder wrote:
>>
>>>But the DNS name is a character string!
>>
>>
>>In most uses, that's true; it's not true for all DNS names. Notice
>>that RFC 2782 (the definition of SRV records) never uses the word
>>"character". That is on purpose.
>
>Could you give an example of such a null terminated label.

DNS names are binary blobs. Most of them have the semantics of ASCII
characters, but not all of them. 'Twas ever thus. This rule is for
all DNS records, not just SRV records.

>The text of this RFC is ASCII, there is no indication whether the example
>in the text is in another character set.

The character set of the RFC is irrelevant.

--Paul Hoffman, Director
--VPN Consortium

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8U47EPC027434; Thu, 29 Sep 2005 21:07:14 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8U47EWS027433; Thu, 29 Sep 2005 21:07:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from [165.227.249.220] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8U47AsZ027422; Thu, 29 Sep 2005 21:07:10 -0700 (PDT) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked] u>
References: <[email-masked] u>
Date: Thu, 29 Sep 2005 21:07:09 -0700
To: "Manger, James H" ,
From: Paul Hoffman
Subject: RE: draft-ietf-pkix-srvsan-00
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 11:24 AM +1000 9/30/05, Manger, James H wrote:
> > DNS names are binary blobs. Most of them have the semantics of ASCII
>> characters, but not all of them. 'Twas ever thus. This rule is for
>> all DNS records, not just SRV records.
>
>Every (internet) protocol is a "binary blob" -- computers only
>exchange bits & bytes. When the semantics are characters a charset
>needs to be selected.

Note that you are saying that the SRV records we care about have the
semantics of characters. The SRV spec does not say that, but the PKIX
WG can (I believe) say that we are limiting our focus to just
character-based labels.

>Today, everyone knows there are lots of different charsets (eg Java
>1.5 supports 148 charsets) and (hopefully) we are careful to
>explicitly state the charset when required. Historically, there are
>various situations were the charset is undefined. Names in DNS seem
>to fit this last category [it was 1987, an obvious candidate like
>UTF-8 didn't exist].

...but US-ASCII did. The DNS community explicitly chose to not make
DNS labels characters, but instead binary. That is a mostly-forgotten
decision, because nearly everyone thinks of DNS labels as characters.

>The DNS spec explicitly says storing domain names in 7-bit ASCII
>"should be avoided"

...because they are not characters.

>My vote: UTF8String (without any punycode encoding)

If you restrict the SRV labels we are interested in to character
strings, that is a reasonable choice, but so is the on-the-wire
encoding, namely punycode. Using UTF-8 makes the string more readable
and editable in cert handling, using punycode means no conversion
between DNS queries and responses and the cert. Both have merits and
problems.

--Paul Hoffman, Director
--VPN Consortium

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8U1SjLt012125; Thu, 29 Sep 2005 18:28:45 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8U1Sjqt012124; Thu, 29 Sep 2005 18:28:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mailao.ntcif.telstra.com.au (mailao.ntcif.telstra.com.au [202.12.233.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8U1Shbr012118 for ; Thu, 29 Sep 2005 18:28:44 -0700 (PDT) (envelope-from [email-masked])
Received: from mailai.ntcif.telstra.com.au (mailai.ntcif.telstra.com.au [202.12.162.17]) by mailao.ntcif.telstra.com.au (Postfix) with ESMTP id A19A212A8B for ; Fri, 30 Sep 2005 11:28:41 +1000 (EST)
Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 439DBFF81 for ; Fri, 30 Sep 2005 11:28:41 +1000 (EST)
Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 0443841EF8 for ; Fri, 30 Sep 2005 11:28:41 +1000 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: draft-ietf-pkix-srvsan-00
Date: Fri, 30 Sep 2005 11:24:17 +1000
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-pkix-srvsan-00
Thread-Index: AcXFDfTgS/XuWRdnQHGj1HP7u6u1wgAQvaiQ
From: "Manger, James H"
To:
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j8U1Sibr012119
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> DNS names are binary blobs. Most of them have the semantics of ASCII
> characters, but not all of them. 'Twas ever thus. This rule is for
> all DNS records, not just SRV records.

Every (internet) protocol is a "binary blob" -- computers only exchange bits & bytes. When the semantics are characters a charset needs to be selected. Today, everyone knows there are lots of different charsets (eg Java 1.5 supports 148 charsets) and (hopefully) we are careful to explicitly state the charset when required. Historically, there are various situations were the charset is undefined. Names in DNS seem to fit this last category [it was 1987, an obvious candidate like UTF-8 didn't exist].

SRV names (& DNS names) are obviously character strings: they are meant to be human-readable; the specification only uses characters (never hex digits, for instance) in its examples; comparisons are case-insensitive (bytes don't have a case); "." is the separator; the DNS spec says "...character strings (e.g., labels, domain names, etc.)" [RFC 1035, section 2.3.3] etc.

The charset for character strings in DNS is not explicitly defined. It is implied that bytes values 0x00 to 0x7F map to characters as in the US-ASCII charset. The DNS spec [RFC1035] recognizes that "future additions" may need more than this -- "to use the full binary octet capabilities in names". Paul Hoffman & Russ Housley seem to assume this means (in future) an arbitrary byte array might be a valid SRV name. I assume it means (in future) characters outside US-ASCII might be valid in an SRV name, which might require bytes values outside 0x00-0x7F to encode. Under my assumption an SRV name is always a character string so a string type (eg UTF8String) is appropriate.

The DNS spec explicitly says storing domain names in 7-bit ASCII "should be avoided" so IA5String should be avoided (and should not have been used for rfc822Name, dnsName or uri alternative names).

Russ Housley's argument in favour of OCTET STRING said "first, you query the DNS for the service you want". This is actually the second step. First, you (the human user) state the service name you want (either typing it into a GUI or setting it in a configuration file). This first human step should use human-friendly characters, not computer-friendly bytes. The second step is forming a binary DNS query. The crucial security step is comparing the service name in the certificate to the service name the user wanted: a character string comparison.

My vote: UTF8String (without any punycode encoding)

--
Charset = rules for encoding characters as bytes and vice versa

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8TMHTvH083084; Thu, 29 Sep 2005 15:17:29 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8TMHTdK083083; Thu, 29 Sep 2005 15:17:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8TMHTHQ083017 for ; Thu, 29 Sep 2005 15:17:29 -0700 (PDT) (envelope-from [email-masked])
Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8TMG2L09180; Thu, 29 Sep 2005 15:16:02 -0700 (PDT)
Message-Id: <[email-masked]>
To: [email-masked]
Subject: RFC 4211 on the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
Cc: [email-masked], [email-masked]
From: [email-masked]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 29 Sep 2005 15:16:02 -0700
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

A new Request for Comments is now available in online RFC libraries.

RFC 4211

Title: Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)
Author(s): J. Schaad
Status: Standards Track
Date: September 2005
Mailbox: [email-masked]
Pages: 40
Characters: 86136
Obsoletes: 2511

I-D Tag: draft-ietf-pkix-rfc2511bis-08.txt

URL: ftp://ftp.rfc-editor.org/in-notes/rfc4211.txt

This document describes the Certificate Request Message Format (CRMF)
syntax and semantics. This syntax is used to convey a request for a
certificate to a Certification Authority (CA), possibly via a
Registration Authority (RA), for the purposes of X.509 certificate
production. The request will typically include a public key and the
associated registration information. This document does not define a
certificate request protocol.

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

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol. Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked]. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body
help: ways_to_get_rfcs. For example:

To: [email-masked]
Subject: getting rfcs

help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked]. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked]. Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="[email-masked]"

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

RETRIEVE: rfc
DOC-ID: rfc4211

--OtherAccess
Content-Type: Message/External-body;
name="rfc4211.txt";
site="ftp.isi.edu";
access-type="anon-ftp";
directory="in-notes"

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

--OtherAccess--
--NextPart--

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8TMG2vq082331; Thu, 29 Sep 2005 15:16:02 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8TMG2KE082330; Thu, 29 Sep 2005 15:16:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8TMG2gh082320 for ; Thu, 29 Sep 2005 15:16:02 -0700 (PDT) (envelope-from [email-masked])
Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8TMEWL08950; Thu, 29 Sep 2005 15:14:32 -0700 (PDT)
Message-Id: <[email-masked]>
To: [email-masked]
Subject: RFC 4210 on the Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
Cc: [email-masked], [email-masked]
From: [email-masked]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 29 Sep 2005 15:14:32 -0700
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

A new Request for Comments is now available in online RFC libraries.

RFC 4210

Title: Internet X.509 Public Key Infrastructure
Certificate Management Protocol (CMP)
Author(s): C. Adams, S. Farrell, T. Kause, T. Mononen
Status: Standards Track
Date: September 2005
Mailbox: [email-masked], [email-masked],
[email-masked], [email-masked]
Pages: 95
Characters: 212013
Obsoletes: 2510

I-D Tag: draft-ietf-pkix-rfc2510bis-09.txt

URL: ftp://ftp.rfc-editor.org/in-notes/rfc4210.txt

This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocol (CMP). Protocol messages are
defined for X.509v3 certificate creation and management. CMP
provides on-line interactions between PKI components, including an
exchange between a Certification Authority (CA) and a client system.

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

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol. Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked]. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body
help: ways_to_get_rfcs. For example:

To: [email-masked]
Subject: getting rfcs

help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked]. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked]. Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="[email-masked]"

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

RETRIEVE: rfc
DOC-ID: rfc4210

--OtherAccess
Content-Type: Message/External-body;
name="rfc4210.txt";
site="ftp.isi.edu";
access-type="anon-ftp";
directory="in-notes"

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

--OtherAccess--
--NextPart--

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8TEGjHb039725; Thu, 29 Sep 2005 07:16:45 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8TEGjB0039724; Thu, 29 Sep 2005 07:16:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from [165.227.249.220] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8TEGgUC039716; Thu, 29 Sep 2005 07:16:42 -0700 (PDT) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 29 Sep 2005 07:11:07 -0700
To: Peter Sylvester
From: Paul Hoffman
Subject: Re: draft-ietf-pkix-srvsan-00
Cc: [email-masked]
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 1:52 PM +0200 9/29/05, Peter Sylvester wrote:
>Paul Hoffman wrote:
>
>>
>>At 11:23 AM +0200 9/25/05, Michael Ströder wrote:
>>
>>>But the DNS name is a character string!
>>
>>
>>In most uses, that's true; it's not true for all DNS names. Notice
>>that RFC 2782 (the definition of SRV records) never uses the word
>>"character". That is on purpose.
>
>Could you give an example of such a null terminated label.

DNS names are binary blobs. Most of them have the semantics of ASCII
characters, but not all of them. 'Twas ever thus. This rule is for
all DNS records, not just SRV records.

>The text of this RFC is ASCII, there is no indication whether the example
>in the text is in another character set.

The character set of the RFC is irrelevant.

--Paul Hoffman, Director
--VPN Consortium

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8TBqESX028053; Thu, 29 Sep 2005 04:52:14 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8TBqExU028052; Thu, 29 Sep 2005 04:52:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8TBqD6G028046 for ; Thu, 29 Sep 2005 04:52:14 -0700 (PDT) (envelope-from [email-masked])
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j8TBqBi13442; Thu, 29 Sep 2005 13:52:11 +0200 (MEST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Thu, 29 Sep 2005 13:52:11 +0200 (MET DST)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA09041; Thu, 29 Sep 2005 13:52:05 +0200 (MET DST)
Message-ID: <[email-masked]>
Date: Thu, 29 Sep 2005 13:52:05 +0200
From: Peter Sylvester
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman
CC: [email-masked]
Subject: Re: draft-ietf-pkix-srvsan-00
References: <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080004080501070206030806"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a cryptographically signed message in MIME format.

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

Paul Hoffman wrote:

>
> At 11:23 AM +0200 9/25/05, Michael Ströder wrote:
>
>> But the DNS name is a character string!
>
>
> In most uses, that's true; it's not true for all DNS names. Notice
> that RFC 2782 (the definition of SRV records) never uses the word
> "character". That is on purpose.

Could you give an example of such a null terminated label.

The RFC is composed of characters. Without any other interpretation
the statement below means to me that _lpad._tcp.example.com
are characters

If a SRV-cognizant LDAP client wants to discover a LDAP server that
supports TCP protocol and provides LDAP service for the domain
example.com., it does a lookup of

_ldap._tcp.example.com

as described in [ARM].

Ooups a reference to "work in progress".

Everything in this text is character based except for example this
paragraph and its wonderful last sentence.

Priority
The priority of this target host. A client MUST attempt to
contact the target host with the lowest-numbered priority it can
reach; target hosts with the same priority SHOULD be tried in an
order defined by the weight field. The range is 0-65535. This
is a 16 bit unsigned integer in network byte order.

Anyway there are dots as separators, and not nuls, etc.

>
> If the PKIX WG says that the subjectAltName for SRV records can only
> be used for SRV records that are characters, then you can say that
> subjectAltName has a character type. You can also assume that
> implementers will probably screw up and try to write subjectAltName
> for non-character SRV records and it will fail in inexplicable ways.

I can assume that such an SRV record sepc would need to define a textual representation
following the spec

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

and this textual representation needs to be done in such a way that it
doesn't collide with the ASCII subset etc etc.

IMO he question is whether the textual representation "Name" is ASCII,
UTF8 or ISO-latin1, or.

The text of this RFC is ASCII, there is no indication whether the example
in the text is in another character set.

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

--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

--------------ms080004080501070206030806
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwOTI5MTE1MjA1WjAjBgkqhkiG9w0B
CQQxFgQUVXpT/642aGLxL8ue+Q9IgmRSF+gwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGATmt8GAwLNpFztMl2
4tdrfU/OXDsi5tCeYChTPx8ShLTn6+jEZD2BWXQcMh8SWXdd6kdoNv2uqVUHc4txHbcS5tfL
90SFqwEyD4+wQ/e7iXBHYNRnLCMe8Xoc81M7B97v8vmpV3EAjk5WRVHWZsjbkS1MNeIv/BB7
aAqAKA0k8BsAAAAAAAA=
--------------ms080004080501070206030806--

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RJo3Sm021352; Tue, 27 Sep 2005 12:50:03 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8RJo31K021351; Tue, 27 Sep 2005 12:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8RJo21U021345 for ; Tue, 27 Sep 2005 12:50:02 -0700 (PDT) (envelope-from [email-masked])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EKLSk-0004SK-5j; Tue, 27 Sep 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-acpolicies-extn-06.txt
Message-Id:
Date: Tue, 27 Sep 2005 15:50:02 -0400
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 : Attribute Certificate Policies extension
Author(s) : C. Francis, D. Pinkas
Filename : draft-ietf-pkix-acpolicies-extn-06.txt
Pages : 10
Date : 2005-9-27

This document describes one certificate extension to explicitly
state the Attribute Certificate Policies (ACPs) that apply to a
given Attribute Certificate (AC). The goal of this document is to
allow relying parties to perform an additional test when validating
an AC, i.e. to assess whether a given AC carrying some attributes
can be accepted on the basis of references to one or more specific
ACPs.

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-acpolicies-extn-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-acpolicies-extn-06.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-acpolicies-extn-06.txt

--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-acpolicies-extn-06.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8QLNV4Z082357; Mon, 26 Sep 2005 14:23:31 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8QLNVHZ082356; Mon, 26 Sep 2005 14:23:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8QLNUaQ082346 for ; Mon, 26 Sep 2005 14:23:30 -0700 (PDT) (envelope-from [email-masked])
Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8QLM2Y02681; Mon, 26 Sep 2005 14:22:02 -0700 (PDT)
Message-Id: <[email-masked]>
To: [email-masked]
Subject: RFC 4158 on Internet X.509 Public Key Infrastructure: Certification Path Building
Cc: [email-masked], [email-masked]
From: [email-masked]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 26 Sep 2005 14:22:03 -0700
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

A new Request for Comments is now available in online RFC libraries.

RFC 4158

Title: Internet X.509 Public Key Infrastructure:
Certification Path Building
Author(s): M. Cooper, Y. Dzambasow, P. Hesse, S. Joseph,
R. Nicholas
Status: Informational
Date: September 2005
Mailbox: [email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked]
Pages: 81
Characters: 199297
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-pkix-certpathbuild-05.txt

URL: ftp://ftp.rfc-editor.org/in-notes/rfc4158.txt

This document provides guidance and recommendations to developers
building X.509 public-key certification paths within their
applications. By following the guidance and recommendations defined
in this document, an application developer is more likely to develop
a robust X.509 certificate-enabled application that can build valid
certification paths across a wide range of PKI environments.

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

This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked]. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body
help: ways_to_get_rfcs. For example:

To: [email-masked]
Subject: getting rfcs

help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked]. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked]. Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="[email-masked]"

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

RETRIEVE: rfc
DOC-ID: rfc4158

--OtherAccess
Content-Type: Message/External-body;
name="rfc4158.txt";
site="ftp.isi.edu";
access-type="anon-ftp";
directory="in-notes"

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

--OtherAccess--
--NextPart--

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8Q0Fjiw068629; Sun, 25 Sep 2005 17:15:45 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8Q0FjPP068628; Sun, 25 Sep 2005 17:15:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8Q0FhnE068552 for ; Sun, 25 Sep 2005 17:15:44 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Sep 2005 01:15:38 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-srvsan-00
Date: Mon, 26 Sep 2005 01:15:43 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-pkix-srvsan-00
Thread-Index: AcXB4x9v0ZyC6vHUTZagE/auP9viEAAS3aEg
From: "Stefan Santesson"
To: "Tom Gindin" ,
Cc: "Russ Housley" , , "Paul Hoffman"
X-OriginalArrivalTime: 26 Sep 2005 00:15:38.0225 (UTC) FILETIME=[6C114610:01C5C22F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8Q0FinE068602
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Tom,

I share your concern regarding processing name constraints on an OCTET
STRING encoded name form. And I do believe that name constraining might
be very useful for this name and as such this draft should define name
constraints matching rules for it.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: den 25 september 2005 17:09
> To: Stefan Santesson; [email-masked]
> Cc: Russ Housley; [email-masked]; Paul Hoffman
> Subject: RE: draft-ietf-pkix-srvsan-00
>
> Kurt:
>
> Stefan's point about name constraints argues relatively
strongly
> in favor of a string-based matching rule, which suggests a string
> encoding. In particular, the existing URI or DNS name constraint
rules
> could appropriately be applied to this OTHER-NAME form - if a CA may
only
> certify URI's within a given set of domains, I can't see why it should
be
> allowed to certify a user with this name form outside those domains.
> Either of those matches are obviously character string matches, and
they
> don't make sense as pure binary ones given the distinction between
periods
> and all other characters - although you could implement a pure binary
> trailing substring match if the constraint string started with a
period.
>
> Tom Gindin
>
>
>
>
>
> "Kurt D. Zeilenga"
> Sent by: [email-masked]
> 09/24/2005 11:18 AM
>
> To: Russ Housley
> cc: "Stefan Santesson" , Paul
Hoffman
> , [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
>
>
>
> My point is that each DNS name is a sequence of DNS
> labels, each label being an octet string.
>
> Kurt
>
> At 11:15 AM 9/23/2005, Russ Housley wrote:
>
> >Kurt:
> >
> >Yes, if you want to allow the other name to represent more than one
SRV
> record. No, if you want to include a separate other name instance for
> each SRV record, which is more consistent with the way that tow URLs
would
> be represented.
> >
> >Russ
> >
> >At 02:00 PM 9/23/2005, Kurt D. Zeilenga wrote:
> >>At 09:24 AM 9/23/2005, Paul Hoffman wrote:
> >>>>Therefore, it seems to me that the OCTET STRING is the form that
> matches the sequence of octets that will actually be provided by a DNS
> query. Then, the ToUnicode routine is used to convert for display to
a
> human.
> >>>
> >>>Russ is completely correct: don't convert if you don't have to, DNS
is
> a binary transport, so OCTET STRING is the correct way to not lose
data.
> >>
> >>wouldn't SEQUENCE OF OCTET STRING be more appropriate?
> >>
> >>Kurt
>
>

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8Q08u1v068160; Sun, 25 Sep 2005 17:08:56 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8Q08uXK068159; Sun, 25 Sep 2005 17:08:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8Q08tI9068136 for ; Sun, 25 Sep 2005 17:08:55 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Sep 2005 01:08:49 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: draft-ietf-pkix-srvsan-00
Date: Mon, 26 Sep 2005 01:08:53 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-pkix-srvsan-00
Thread-Index: AcXBEFUMecaT/pycTzWSMEKUaB6yJwBFeYww
From: "Stefan Santesson"
To: "Peter Sylvester" , "Paul Hoffman"
Cc: "Russ Housley" ,
X-OriginalArrivalTime: 26 Sep 2005 00:08:49.0365 (UTC) FILETIME=[785E3050:01C5C22E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8Q08tI9068147
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Peter,

Thanks for this input.

As I understand it (correct me if I'm wrong), one of the issues with punycode is that it efficiently translates an I18n domain name (IDNA) into a valid ASCII encoded domain name. Looking only at the punycode encoded domain name it might be hard to know whether the ASCII characters represents the domain name in the form it was intended to be displayed or if it is a punycoded IDNA.

This is why UTF8String provide better functionality for UI design, because if you have the domain name in UTF8, you know if this is an IDNA and thus can easily display it correctly in certificate management UIs.

If, as you say, the binary data sent to the DNS contains 7-bit ASCII encoded characters, I think this is yet another reason why OCTET STRING for this new name form seems like a less attractive solution.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: den 24 september 2005 16:00
> To: Paul Hoffman
> Cc: Russ Housley; Stefan Santesson; [email-masked]
> Subject: Re: draft-ietf-pkix-srvsan-00
>
>
>
> >
> > Russ is completely correct: don't convert if you don't have to, DNS is
> > a binary transport, so OCTET STRING is the correct way to not lose data.
>
> BER, DER, PER are binary encoding rules, but you still carry textual data.
> The DNS doesn't carry uninterpreted OCTETS, it carry labels and encoded
> form
> of labels. And currently we only have ASCII labels.
>
> (I think Karl had in mind to code each label in an octet string).
>
> 2.3.3. Character Case
>
> For all parts of the DNS that are part of the official protocol, all
> comparisons between character strings (e.g., labels, domain names, etc.)
> are done in a case-insensitive manner. At present, this rule is in
> force throughout the domain system without exception. However, future
> additions beyond current usage may need to use the full binary octet
> capabilities in names, so attempts to store domain names in 7-bit ASCII
> or use of special bytes to terminate labels, etc., should be avoided.
>
>
> I "like" the 'however", in particular the relation between
> case sensitivity.
> After 18 years, I still haven't seen future additions. Even
> I18n avoided UTF8. Of course, one could ask that the binary
> capabilities are reserved for non textual application?
> The quote above does not indicate whether it is intended
> to encode non textual labels like pictograms using 8 bits
> or whether the DNS is reserved for text.
>
> I don't buy the need for 8bits for the proposed rfc.
> The service names are textual labels as any other.
>
> Since the dNSAltname has IA5ext, I don't see why one
> needs anything different. where is the urgent need.
> If there is more need for 8 bits, one can make the
> dNSAltName a choice of IA5Text and whatever else
> would be a useful way to encode a sequence of
> pictures to use flags as an alternate non textual
> representation of some top level domains.
> (com=the logo of the "world company") :-)
>
> I'd like to the certification software developpers to make
> code for octet strings: You need at least modes, in one you
> code the full octet string with double 0 at the end etc, and
> in another way, you code just text.
> Explain to someone that a subjectAltname dNSName has a textual
> interface (which may or may not be I18N capable), and
> in the serviceName you need some other things because
> it is an octet strings,
>
> >
> > --Paul Hoffman, Director
> > --VPN Consortium
> >
> >
> >
>
>
> --
> To verify the signature, see http://edelpki.edelweb.fr/
> Cela vous permet de charger le certificat de l'autorité;
> die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8PFhjtu025556; Sun, 25 Sep 2005 08:43:45 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8PFhj57025555; Sun, 25 Sep 2005 08:43:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8PFhiKl025547 for ; Sun, 25 Sep 2005 08:43:45 -0700 (PDT) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Sun, 25 Sep 2005 08:43:44 -0700
To: [email-masked]
From: Paul Hoffman
Subject: Re: draft-ietf-pkix-srvsan-00
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 11:23 AM +0200 9/25/05, Michael Ströder wrote:
>But the DNS name is a character string!

In most uses, that's true; it's not true for all DNS names. Notice
that RFC 2782 (the definition of SRV records) never uses the word
"character". That is on purpose.

If the PKIX WG says that the subjectAltName for SRV records can only
be used for SRV records that are characters, then you can say that
subjectAltName has a character type. You can also assume that
implementers will probably screw up and try to write subjectAltName
for non-character SRV records and it will fail in inexplicable ways.

--Paul Hoffman, Director
--VPN Consortium

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8PF9SbX021840; Sun, 25 Sep 2005 08:09:28 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8PF9SFt021839; Sun, 25 Sep 2005 08:09:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8PF9QBZ021812 for ; Sun, 25 Sep 2005 08:09:27 -0700 (PDT) (envelope-from [email-masked])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8PF9LCL004604 for ; Sun, 25 Sep 2005 11:09:21 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8PF9K2l096610 for ; Sun, 25 Sep 2005 11:09:21 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j8PF9Kvb022645 for ; Sun, 25 Sep 2005 11:09:20 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j8PF9KjF022642; Sun, 25 Sep 2005 11:09:20 -0400
In-Reply-To: <[email-masked]>
To: "Stefan Santesson" , [email-masked]
Cc: Russ Housley , [email-masked], Paul Hoffman
MIME-Version: 1.0
Subject: RE: draft-ietf-pkix-srvsan-00
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin
Message-ID:
Date: Sun, 25 Sep 2005 11:09:18 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 09/25/2005 11:09:19, Serialize complete at 09/25/2005 11:09:19
Content-Type: text/plain; charset="US-ASCII"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Kurt:

Stefan's point about name constraints argues relatively strongly
in favor of a string-based matching rule, which suggests a string
encoding. In particular, the existing URI or DNS name constraint rules
could appropriately be applied to this OTHER-NAME form - if a CA may only
certify URI's within a given set of domains, I can't see why it should be
allowed to certify a user with this name form outside those domains.
Either of those matches are obviously character string matches, and they
don't make sense as pure binary ones given the distinction between periods
and all other characters - although you could implement a pure binary
trailing substring match if the constraint string started with a period.

Tom Gindin

"Kurt D. Zeilenga"
Sent by: [email-masked]
09/24/2005 11:18 AM

To: Russ Housley
cc: "Stefan Santesson" , Paul Hoffman
, [email-masked]
Subject: RE: draft-ietf-pkix-srvsan-00

My point is that each DNS name is a sequence of DNS
labels, each label being an octet string.

Kurt

At 11:15 AM 9/23/2005, Russ Housley wrote:

>Kurt:
>
>Yes, if you want to allow the other name to represent more than one SRV
record. No, if you want to include a separate other name instance for
each SRV record, which is more consistent with the way that tow URLs would
be represented.
>
>Russ
>
>At 02:00 PM 9/23/2005, Kurt D. Zeilenga wrote:
>>At 09:24 AM 9/23/2005, Paul Hoffman wrote:
>>>>Therefore, it seems to me that the OCTET STRING is the form that
matches the sequence of octets that will actually be provided by a DNS
query. Then, the ToUnicode routine is used to convert for display to a
human.
>>>
>>>Russ is completely correct: don't convert if you don't have to, DNS is
a binary transport, so OCTET STRING is the correct way to not lose data.
>>
>>wouldn't SEQUENCE OF OCTET STRING be more appropriate?
>>
>>Kurt

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8P9OJ5t089508; Sun, 25 Sep 2005 02:24:19 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8P9OJEO089507; Sun, 25 Sep 2005 02:24:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from srv1.int.stroeder.com (1-22-124-83.dsl.3u.net [83.124.22.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8P9OHeq089488 for ; Sun, 25 Sep 2005 02:24:18 -0700 (PDT) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by srv1.int.stroeder.com (Postfix) with ESMTP id 1F18F57F; Sun, 25 Sep 2005 11:24:10 +0200 (CEST)
Received: from srv1.int.stroeder.com ([127.0.0.1]) by localhost (srv1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26055-06; Sun, 25 Sep 2005 11:24:02 +0200 (CEST)
Received: from [10.1.1.5] (unknown [10.1.1.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Michael Stroeder", Issuer "Thawte Personal Freemail Issuing CA" (not verified)) by srv1.int.stroeder.com (Postfix) with ESMTP id 3691D57A; Sun, 25 Sep 2005 11:24:01 +0200 (CEST)
Message-ID: <[email-masked]>
Date: Sun, 25 Sep 2005 11:23:59 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?=
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Paul Hoffman
CC: [email-masked]
Subject: Re: draft-ietf-pkix-srvsan-00
References: <[email-masked]>
In-Reply-To:
X-Enigmail-Version: 0.92.1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: amavisd-new at int.stroeder.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul Hoffman wrote:
>
>> Therefore, it seems to me that the OCTET STRING is the form that
>> matches the sequence of octets that will actually be provided by a DNS
>> query. Then, the ToUnicode routine is used to convert for display to
>> a human.
>
> Russ is completely correct: don't convert if you don't have to, DNS is a
> binary transport, so OCTET STRING is the correct way to not lose data.

But the DNS name is a character string! So best is to either stuff
Punycode in IA5String etc. or use UTF8String. Otherwise implementors
will store into it whichever character set / code page they like.

Ciao, Michael.

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8OFMjkJ000226; Sat, 24 Sep 2005 08:22:45 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8OFMjMe000225; Sat, 24 Sep 2005 08:22:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8OFMhgB000204 for ; Sat, 24 Sep 2005 08:22:44 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Sep 2005 16:22:38 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-srvsan-00
Date: Sat, 24 Sep 2005 16:22:36 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-pkix-srvsan-00
Thread-Index: AcXBGz79APoizUFWT2urf6ow3GMsvgAABoQg
From: "Stefan Santesson"
To: "Kurt D. Zeilenga" , "Russ Housley"
Cc: "Paul Hoffman" ,
X-OriginalArrivalTime: 24 Sep 2005 15:22:38.0127 (UTC) FILETIME=[CC07D3F0:01C5C11B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8OFMigB000210
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Kurt,

This new name form does not contain a DNS record. It is a name to
express a service name relative to a domain in the form of a single
string.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: den 24 september 2005 17:18
> To: Russ Housley
> Cc: Stefan Santesson; Paul Hoffman; [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
>
> My point is that each DNS name is a sequence of DNS
> labels, each label being an octet string.
>
> Kurt
>
> At 11:15 AM 9/23/2005, Russ Housley wrote:
>
> >Kurt:
> >
> >Yes, if you want to allow the other name to represent more than one
SRV
> record. No, if you want to include a separate other name instance for
> each SRV record, which is more consistent with the way that tow URLs
would
> be represented.
> >
> >Russ
> >
> >At 02:00 PM 9/23/2005, Kurt D. Zeilenga wrote:
> >>At 09:24 AM 9/23/2005, Paul Hoffman wrote:
> >>>>Therefore, it seems to me that the OCTET STRING is the form that
> matches the sequence of octets that will actually be provided by a DNS
> query. Then, the ToUnicode routine is used to convert for display to
a
> human.
> >>>
> >>>Russ is completely correct: don't convert if you don't have to, DNS
is
> a binary transport, so OCTET STRING is the correct way to not lose
data.
> >>
> >>wouldn't SEQUENCE OF OCTET STRING be more appropriate?
> >>
> >>Kurt

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8OFIdBb099772; Sat, 24 Sep 2005 08:18:39 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8OFIdLs099771; Sat, 24 Sep 2005 08:18:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from boole.openldap.org ([email-masked] [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8OFIcKN099765 for ; Sat, 24 Sep 2005 08:18:38 -0700 (PDT) (envelope-from [email-masked])
Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j8OFIbHh044683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Sep 2005 15:18:38 GMT (envelope-from [email-masked])
Message-Id: <[email-masked]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Sat, 24 Sep 2005 08:18:00 -0700
To: Russ Housley
From: "Kurt D. Zeilenga"
Subject: RE: draft-ietf-pkix-srvsan-00
Cc: "Stefan Santesson" , Paul Hoffman , [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

My point is that each DNS name is a sequence of DNS
labels, each label being an octet string.

Kurt

At 11:15 AM 9/23/2005, Russ Housley wrote:

>Kurt:
>
>Yes, if you want to allow the other name to represent more than one SRV record. No, if you want to include a separate other name instance for each SRV record, which is more consistent with the way that tow URLs would be represented.
>
>Russ
>
>At 02:00 PM 9/23/2005, Kurt D. Zeilenga wrote:
>>At 09:24 AM 9/23/2005, Paul Hoffman wrote:
>>>>Therefore, it seems to me that the OCTET STRING is the form that matches the sequence of octets that will actually be provided by a DNS query. Then, the ToUnicode routine is used to convert for display to a human.
>>>
>>>Russ is completely correct: don't convert if you don't have to, DNS is a binary transport, so OCTET STRING is the correct way to not lose data.
>>
>>wouldn't SEQUENCE OF OCTET STRING be more appropriate?
>>
>>Kurt

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8OE0UWZ092448; Sat, 24 Sep 2005 07:00:30 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8OE0U2E092447; Sat, 24 Sep 2005 07:00:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8OE0SXM092440 for ; Sat, 24 Sep 2005 07:00:29 -0700 (PDT) (envelope-from [email-masked])
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j8OE0Qi24986; Sat, 24 Sep 2005 16:00:26 +0200 (MEST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Sat, 24 Sep 2005 16:00:26 +0200 (MET DST)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA04697; Sat, 24 Sep 2005 16:00:20 +0200 (MET DST)
Message-ID: <[email-masked]>
Date: Sat, 24 Sep 2005 16:00:19 +0200
From: Peter Sylvester
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman
CC: Russ Housley , Stefan Santesson , [email-masked]
Subject: Re: draft-ietf-pkix-srvsan-00
References: <[email-masked]>
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070800020805010108070903"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a cryptographically signed message in MIME format.

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

>
> Russ is completely correct: don't convert if you don't have to, DNS is
> a binary transport, so OCTET STRING is the correct way to not lose data.

BER, DER, PER are binary encoding rules, but you still carry textual data.
The DNS doesn't carry uninterpreted OCTETS, it carry labels and encoded form
of labels. And currently we only have ASCII labels.

(I think Karl had in mind to code each label in an octet string).

2.3.3. Character Case

For all parts of the DNS that are part of the official protocol, all
comparisons between character strings (e.g., labels, domain names, etc.)
are done in a case-insensitive manner. At present, this rule is in
force throughout the domain system without exception. However, future
additions beyond current usage may need to use the full binary octet
capabilities in names, so attempts to store domain names in 7-bit ASCII
or use of special bytes to terminate labels, etc., should be avoided.

I "like" the 'however", in particular the relation between
case sensitivity.
After 18 years, I still haven't seen future additions. Even
I18n avoided UTF8. Of course, one could ask that the binary
capabilities are reserved for non textual application?
The quote above does not indicate whether it is intended
to encode non textual labels like pictograms using 8 bits
or whether the DNS is reserved for text.

I don't buy the need for 8bits for the proposed rfc.
The service names are textual labels as any other.

Since the dNSAltname has IA5ext, I don't see why one
needs anything different. where is the urgent need.
If there is more need for 8 bits, one can make the
dNSAltName a choice of IA5Text and whatever else
would be a useful way to encode a sequence of
pictures to use flags as an alternate non textual
representation of some top level domains.
(com=the logo of the "world company") :-)

I'd like to the certification software developpers to make
code for octet strings: You need at least modes, in one you
code the full octet string with double 0 at the end etc, and
in another way, you code just text.
Explain to someone that a subjectAltname dNSName has a textual
interface (which may or may not be I18N capable), and
in the serviceName you need some other things because
it is an octet strings,

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

--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

--------------ms070800020805010108070903
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwOTI0MTQwMDE5WjAjBgkqhkiG9w0B
CQQxFgQUjqxkpA48Yyiq5ZTc5yr//Gbs3iowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAUnjI2Mc+tiFZkvj6
SeH2rtkr0sZC9wulAKyAMMMc/548A4p4CNucSyWMiwF584QoltVHibovVz4bSRu8QuC55BIR
E+nbS+u99gi8eJi8Vu10XgMZmK2yulWii+QmEYbQgnurd5cK+M8RB8zLq5xWyKkhzdO4RNXJ
55GSMliM/j8AAAAAAAA=
--------------ms070800020805010108070903--

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NMaulT005590; Fri, 23 Sep 2005 15:36:56 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NMauiU005589; Fri, 23 Sep 2005 15:36:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NMatAs005561 for ; Fri, 23 Sep 2005 15:36:55 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Sep 2005 23:36:49 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-srvsan-00
Date: Fri, 23 Sep 2005 23:36:48 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-pkix-srvsan-00
Thread-Index: AcXAasZuOnMcC144TiGjBO/rSMLEhQAI/i3A
From: "Stefan Santesson"
To: "Russ Housley" , "Kurt D. Zeilenga"
Cc: "Paul Hoffman" ,
X-OriginalArrivalTime: 23 Sep 2005 22:36:49.0618 (UTC) FILETIME=[49842320:01C5C08F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8NMauAs005571
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Agree with Russ. The correct way is to include multiple instances of the
same otherName. Eventual name constraints definitions would be awful if
the name form would be defined as a sequence.

Talking about that we might just as well define the name constraints
matching rule for this name form. It would be rather easy. Taking the
dNSName rules from RFC 3280bis and add the service parameter to the
rules.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 23 september 2005 20:15
> To: Kurt D. Zeilenga
> Cc: Stefan Santesson; Paul Hoffman; [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
>
> Kurt:
>
> Yes, if you want to allow the other name to represent more than one
SRV
> record. No, if you want to include a separate other name instance for
> each
> SRV record, which is more consistent with the way that tow URLs would
be
> represented.
>
> Russ
>
> At 02:00 PM 9/23/2005, Kurt D. Zeilenga wrote:
> >At 09:24 AM 9/23/2005, Paul Hoffman wrote:
> > >>Therefore, it seems to me that the OCTET STRING is the form that
> > matches the sequence of octets that will actually be provided by a
DNS
> > query. Then, the ToUnicode routine is used to convert for display
to a
> human.
> > >
> > >Russ is completely correct: don't convert if you don't have to, DNS
is
> a
> > binary transport, so OCTET STRING is the correct way to not lose
data.
> >
> >wouldn't SEQUENCE OF OCTET STRING be more appropriate?
> >
> >Kurt

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NMWk18005221; Fri, 23 Sep 2005 15:32:46 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NMWk5P005220; Fri, 23 Sep 2005 15:32:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NMWjFt005188 for ; Fri, 23 Sep 2005 15:32:45 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Sep 2005 23:32:39 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-srvsan-00
Date: Fri, 23 Sep 2005 23:32:38 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-pkix-srvsan-00
Thread-Index: AcXAahQdaRk2HLFfTNu6X701Hsi0IAAIoU6w
From: "Stefan Santesson"
To: "Russ Housley"
Cc: ,
X-OriginalArrivalTime: 23 Sep 2005 22:32:39.0486 (UTC) FILETIME=[B46D05E0:01C5C08E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8NMWkFt005206
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Yes, your scenario is valid. But I think there are other valid scenarios
as well where no OCTET STRING may be created.

The system start with the client knowing which service in which domain
it wants to connect. This is the initial knowledge and it is probably
stored in a string format at the client (not as binary data).

Then it MAY contact a DNS to lookup the host name in that domain. But it
may also have done it recently and cached the host name (skipping the
query - It will authenticate the host anyway), it may obtain the host
name by some other means (directory, database, mapping table, protocol
exchange using protocol X...) (just speculating but one of the points
with the changed structure is that use of DNS RR is optional and only
happens when appropriate)

When authenticating the server in the final step, it maps the
certificate service information to its initial knowledge which I assumed
was stored in string format.

It may sound that I'm dead locked on UTF8, but I'm not. I'm totally
open. I just think this is worth viewing from all angles before making
the call.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 23 september 2005 20:04
> To: Stefan Santesson
> Cc: [email-masked]; [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
>
> Stefan:
>
> Let's look at the whole system. First, you query the DNS for the
service
> that you want, and then you contact that service, which provides its
> certificate. The otherName is compared to the service that you want,
> which
> better match the string that was sent to the DNS in the beginning
(without
> the protocol part). So, ultimately, you are comparing it to a string
that
> you also send to the DNS.
>
> Russ
>
>
> At 01:33 PM 9/23/2005, Stefan Santesson wrote:
> >I actually understood :)
> >
> >I feel that I have not managed to explain myself.
> >
> >I don't compare the name in the cert with the content of any DNS RR
and
> >I don't include it into a DNS query.
> >
> >What I do is that I compare the service name in the certificate with
the
> >parameters that was preconfigured in my client.
> >
> >Does this change anything or do you still think OCTET STRING is
better.
> >
> >It seems that the string to binary conversion must be specified in
any
> >case.
> >
> >If you and WG consensus still think OCTET STRING is the best choice
for
> >this name form, then I'll change it.
> >
> >
> >Stefan Santesson
> >Program Manager, Standards Liaison
> >Windows Security
> >
> >
> > > -----Original Message-----
> > > From: Paul Hoffman [mailto:[email-masked]]
> > > Sent: den 23 september 2005 18:25
> > > To: Russ Housley; Stefan Santesson
> > > Cc: [email-masked]
> > > Subject: RE: draft-ietf-pkix-srvsan-00
> > >
> > > At 12:09 PM -0400 9/23/05, Russ Housley wrote:
> > > >Somehow, I have been unable to make my point. I'll try one more
> >time...
> > > >
> > > >The use of UTF8String introduces the need for conversion. OCTET
> > > >STRING does not have the same need.
> > > >
> > > >DNS is a binary protocol. It delivers a sequence of octets. By
> > > >convention, that sequence of octets have historically been ASCII
> > > >characters. And, the recent work on internationalization have
> > > >maintained this convention. The ToASCII and ToUnicode routines
> > > >defined in RFC 3490 are used to make the conversions for IDNs
> > > >(Internationalized Domain Names).
> > > >
> > > >Therefore, it seems to me that the OCTET STRING is the form that
> > > >matches the sequence of octets that will actually be provided by
a
> > > >DNS query. Then, the ToUnicode routine is used to convert for
> > > >display to a human.
> > >
> > > Russ is completely correct: don't convert if you don't have to,
DNS
> > > is a binary transport, so OCTET STRING is the correct way to not
lose
> > > data.
> > > --Paul Hoffman, Director
> > > --VPN Consortium

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NJo64o091516; Fri, 23 Sep 2005 12:50:06 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NJo6Dh091515; Fri, 23 Sep 2005 12:50:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NJo5j3091508 for ; Fri, 23 Sep 2005 12:50:06 -0700 (PDT) (envelope-from [email-masked])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EItYX-0002hr-QM; Fri, 23 Sep 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-srvsan-00.txt
Message-Id:
Date: Fri, 23 Sep 2005 15:50:01 -0400
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

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

Title : Internet X.509 Public Key Infrastructure
Subject Alternative Name for expression of service name
Author(s) : S. Santesson
Filename : draft-ietf-pkix-srvsan-00.txt
Pages : 6
Date : 2005-9-23

This document defines a new name form for inclusion in the otherName
filed of an X.509 Subject Alternative Name extension which allows a
certificate subject to be associated with the service name and domain
name components of a DNS Service Resource Record.

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-srvsan-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-srvsan-00.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-srvsan-00.txt

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

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

--OtherAccess--

--NextPart--

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NIFIx3084297; Fri, 23 Sep 2005 11:15:18 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NIFI7g084293; Fri, 23 Sep 2005 11:15:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8NIFHHB084282 for ; Fri, 23 Sep 2005 11:15:17 -0700 (PDT) (envelope-from [email-masked])
Received: (qmail 14700 invoked by uid 0); 23 Sep 2005 18:15:12 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.246.84) by woodstock.binhost.com with SMTP; 23 Sep 2005 18:15:12 -0000
Message-Id: <[email-masked]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 23 Sep 2005 14:15:14 -0400
To: "Kurt D. Zeilenga"
From: Russ Housley
Subject: RE: draft-ietf-pkix-srvsan-00
Cc: "Stefan Santesson" , Paul Hoffman , [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:

Kurt:

Yes, if you want to allow the other name to represent more than one SRV
record. No, if you want to include a separate other name instance for each
SRV record, which is more consistent with the way that tow URLs would be
represented.

Russ

At 02:00 PM 9/23/2005, Kurt D. Zeilenga wrote:
>At 09:24 AM 9/23/2005, Paul Hoffman wrote:
> >>Therefore, it seems to me that the OCTET STRING is the form that
> matches the sequence of octets that will actually be provided by a DNS
> query. Then, the ToUnicode routine is used to convert for display to a human.
> >
> >Russ is completely correct: don't convert if you don't have to, DNS is a
> binary transport, so OCTET STRING is the correct way to not lose data.
>
>wouldn't SEQUENCE OF OCTET STRING be more appropriate?
>
>Kurt

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NIANXB083939; Fri, 23 Sep 2005 11:10:23 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NIANMf083935; Fri, 23 Sep 2005 11:10:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8NIAMlH083923 for ; Fri, 23 Sep 2005 11:10:23 -0700 (PDT) (envelope-from [email-masked])
Received: (qmail 11328 invoked by uid 0); 23 Sep 2005 18:10:17 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.246.84) by woodstock.binhost.com with SMTP; 23 Sep 2005 18:10:17 -0000
Message-Id: <[email-masked]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 23 Sep 2005 14:03:52 -0400
To: "Stefan Santesson"
From: Russ Housley
Subject: RE: draft-ietf-pkix-srvsan-00
Cc: [email-masked], [email-masked]
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stefan:

Let's look at the whole system. First, you query the DNS for the service
that you want, and then you contact that service, which provides its
certificate. The otherName is compared to the service that you want, which
better match the string that was sent to the DNS in the beginning (without
the protocol part). So, ultimately, you are comparing it to a string that
you also send to the DNS.

Russ

At 01:33 PM 9/23/2005, Stefan Santesson wrote:
>I actually understood :)
>
>I feel that I have not managed to explain myself.
>
>I don't compare the name in the cert with the content of any DNS RR and
>I don't include it into a DNS query.
>
>What I do is that I compare the service name in the certificate with the
>parameters that was preconfigured in my client.
>
>Does this change anything or do you still think OCTET STRING is better.
>
>It seems that the string to binary conversion must be specified in any
>case.
>
>If you and WG consensus still think OCTET STRING is the best choice for
>this name form, then I'll change it.
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
>
>
> > -----Original Message-----
> > From: Paul Hoffman [mailto:[email-masked]]
> > Sent: den 23 september 2005 18:25
> > To: Russ Housley; Stefan Santesson
> > Cc: [email-masked]
> > Subject: RE: draft-ietf-pkix-srvsan-00
> >
> > At 12:09 PM -0400 9/23/05, Russ Housley wrote:
> > >Somehow, I have been unable to make my point. I'll try one more
>time...
> > >
> > >The use of UTF8String introduces the need for conversion. OCTET
> > >STRING does not have the same need.
> > >
> > >DNS is a binary protocol. It delivers a sequence of octets. By
> > >convention, that sequence of octets have historically been ASCII
> > >characters. And, the recent work on internationalization have
> > >maintained this convention. The ToASCII and ToUnicode routines
> > >defined in RFC 3490 are used to make the conversions for IDNs
> > >(Internationalized Domain Names).
> > >
> > >Therefore, it seems to me that the OCTET STRING is the form that
> > >matches the sequence of octets that will actually be provided by a
> > >DNS query. Then, the ToUnicode routine is used to convert for
> > >display to a human.
> >
> > Russ is completely correct: don't convert if you don't have to, DNS
> > is a binary transport, so OCTET STRING is the correct way to not lose
> > data.
> >
> > --Paul Hoffman, Director
> > --VPN Consortium

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NI1hT4083361; Fri, 23 Sep 2005 11:01:43 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NI1hZB083360; Fri, 23 Sep 2005 11:01:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from boole.openldap.org ([email-masked] [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NI1hpn083345 for ; Fri, 23 Sep 2005 11:01:43 -0700 (PDT) (envelope-from [email-masked])
Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j8NI1S9v012702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2005 18:01:32 GMT (envelope-from [email-masked])
Message-Id: <[email-masked]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 23 Sep 2005 11:00:47 -0700
To: Paul Hoffman
From: "Kurt D. Zeilenga"
Subject: RE: draft-ietf-pkix-srvsan-00
Cc: Russ Housley , "Stefan Santesson" ,
In-Reply-To:
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 09:24 AM 9/23/2005, Paul Hoffman wrote:
>>Therefore, it seems to me that the OCTET STRING is the form that matches the sequence of octets that will actually be provided by a DNS query. Then, the ToUnicode routine is used to convert for display to a human.
>
>Russ is completely correct: don't convert if you don't have to, DNS is a binary transport, so OCTET STRING is the correct way to not lose data.

wouldn't SEQUENCE OF OCTET STRING be more appropriate?

Kurt

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NHXE8A080424; Fri, 23 Sep 2005 10:33:14 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NHXEUl080423; Fri, 23 Sep 2005 10:33:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NHXDek080396 for ; Fri, 23 Sep 2005 10:33:13 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Sep 2005 18:33:07 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-srvsan-00
Date: Fri, 23 Sep 2005 18:33:09 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-pkix-srvsan-00
Thread-Index: AcXAW1krM//G5tsGRBikAAATaxRBXgABMMiA
From: "Stefan Santesson"
To: "Paul Hoffman" , "Russ Housley"
Cc:
X-OriginalArrivalTime: 23 Sep 2005 17:33:07.0717 (UTC) FILETIME=[DC6AB350:01C5C064]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8NHXEek080409
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I actually understood :)

I feel that I have not managed to explain myself.

I don't compare the name in the cert with the content of any DNS RR and
I don't include it into a DNS query.

What I do is that I compare the service name in the certificate with the
parameters that was preconfigured in my client.

Does this change anything or do you still think OCTET STRING is better.

It seems that the string to binary conversion must be specified in any
case.

If you and WG consensus still think OCTET STRING is the best choice for
this name form, then I'll change it.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]
> Sent: den 23 september 2005 18:25
> To: Russ Housley; Stefan Santesson
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
>
> At 12:09 PM -0400 9/23/05, Russ Housley wrote:
> >Somehow, I have been unable to make my point. I'll try one more
time...
> >
> >The use of UTF8String introduces the need for conversion. OCTET
> >STRING does not have the same need.
> >
> >DNS is a binary protocol. It delivers a sequence of octets. By
> >convention, that sequence of octets have historically been ASCII
> >characters. And, the recent work on internationalization have
> >maintained this convention. The ToASCII and ToUnicode routines
> >defined in RFC 3490 are used to make the conversions for IDNs
> >(Internationalized Domain Names).
> >
> >Therefore, it seems to me that the OCTET STRING is the form that
> >matches the sequence of octets that will actually be provided by a
> >DNS query. Then, the ToUnicode routine is used to convert for
> >display to a human.
>
> Russ is completely correct: don't convert if you don't have to, DNS
> is a binary transport, so OCTET STRING is the correct way to not lose
> data.
>
> --Paul Hoffman, Director
> --VPN Consortium

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NGOxdX073468; Fri, 23 Sep 2005 09:24:59 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NGOxKi073467; Fri, 23 Sep 2005 09:24:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NGOunW073456; Fri, 23 Sep 2005 09:24:57 -0700 (PDT) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Fri, 23 Sep 2005 09:24:56 -0700
To: Russ Housley , "Stefan Santesson"
From: Paul Hoffman
Subject: RE: draft-ietf-pkix-srvsan-00
Cc:
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 12:09 PM -0400 9/23/05, Russ Housley wrote:
>Somehow, I have been unable to make my point. I'll try one more time...
>
>The use of UTF8String introduces the need for conversion. OCTET
>STRING does not have the same need.
>
>DNS is a binary protocol. It delivers a sequence of octets. By
>convention, that sequence of octets have historically been ASCII
>characters. And, the recent work on internationalization have
>maintained this convention. The ToASCII and ToUnicode routines
>defined in RFC 3490 are used to make the conversions for IDNs
>(Internationalized Domain Names).
>
>Therefore, it seems to me that the OCTET STRING is the form that
>matches the sequence of octets that will actually be provided by a
>DNS query. Then, the ToUnicode routine is used to convert for
>display to a human.

Russ is completely correct: don't convert if you don't have to, DNS
is a binary transport, so OCTET STRING is the correct way to not lose
data.

--Paul Hoffman, Director
--VPN Consortium

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NG9Qik072051; Fri, 23 Sep 2005 09:09:26 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NG9QVA072050; Fri, 23 Sep 2005 09:09:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8NG9PQw072037 for ; Fri, 23 Sep 2005 09:09:26 -0700 (PDT) (envelope-from [email-masked])
Received: (qmail 25892 invoked by uid 0); 23 Sep 2005 16:09:21 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.139.106) by woodstock.binhost.com with SMTP; 23 Sep 2005 16:09:21 -0000
Message-Id: <[email-masked]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 23 Sep 2005 12:09:22 -0400
To: "Stefan Santesson"
From: Russ Housley
Subject: RE: draft-ietf-pkix-srvsan-00
Cc: , [email-masked]
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Somehow, I have been unable to make my point. I'll try one more time...

The use of UTF8String introduces the need for conversion. OCTET STRING
does not have the same need.

DNS is a binary protocol. It delivers a sequence of octets. By
convention, that sequence of octets have historically been ASCII
characters. And, the recent work on internationalization have maintained
this convention. The ToASCII and ToUnicode routines defined in RFC 3490
are used to make the conversions for IDNs (Internationalized Domain Names).

Therefore, it seems to me that the OCTET STRING is the form that matches
the sequence of octets that will actually be provided by a DNS
query. Then, the ToUnicode routine is used to convert for display to a human.

Russ

At 11:25 AM 9/23/2005, Stefan Santesson wrote:
>For this to work there has to be some coding conventions defined within
>the DNS standards (how to code and decode the characters into and from
>OCTET STRING) which would need to be applied to this draft.
>
>I see many places where conversion would have to take place related to
>UIs if the OCTET STRING format is selected, such as in the CA
>administration UI and in any cert viewer UI.
>
>My gut feeling is that it is a bit less painful to include code
>conversion in all UI events than do the code conversion during the
>authentication process. And in fact, there might not even be a code
>conversion required during authentication.
>
>I assume the client before doing the DNS RR query, knows/stores
>knowledge of the service name and domain name as strings and not as
>binary OCTET STRING, and the client would then convert anyway in its DNS
>query and response process.
>
>During authentication, the client could use its already stored string
>knowledge about service and domain to compare with the content of the
>certificate.
>
>I admit that I'm speculating, but UTF8String sure feels as the preferred
>solution.
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
>
>
> > -----Original Message-----
> > From: Russ Housley [mailto:[email-masked]]
> > Sent: den 23 september 2005 15:56
> > To: Stefan Santesson
> > Cc: [email-masked]
> > Subject: RE: draft-ietf-pkix-srvsan-00
> >
> > Stefan:
> >
> > The point that I wanted to discuss was the use of OCTET STRING to
>carry
> > exactly the sequence of octets that would appear in the DNS (without
>the
> > protocol portion).
> >
> > The display issue is exactly the same as displaying information that
>is
> > retrieved from the DNS. No better, and no worse.
> >
> > Russ
> >
> > At 09:35 PM 9/22/2005, Stefan Santesson wrote:
> > >In the choice between UTF8String and OCTET STRING I definitely prefer
> > >UTF8String since it makes the information displayable. IF we choose
> > >OCTET STRING we need to specify which encoding we carry inside the
>OCTET
> > >STRING anyway.

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NFPMou067576; Fri, 23 Sep 2005 08:25:22 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NFPM8O067575; Fri, 23 Sep 2005 08:25:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NFPKnf067552 for ; Fri, 23 Sep 2005 08:25:21 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Sep 2005 16:25:15 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-srvsan-00
Date: Fri, 23 Sep 2005 16:25:18 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-pkix-srvsan-00
Thread-Index: AcXARohww5CFbt/SSaGypP7LSrzG8gAAKGMQ
From: "Stefan Santesson"
To: "Russ Housley"
Cc:
X-OriginalArrivalTime: 23 Sep 2005 15:25:15.0063 (UTC) FILETIME=[FF289C70:01C5C052]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8NFPLnf067569
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

For this to work there has to be some coding conventions defined within
the DNS standards (how to code and decode the characters into and from
OCTET STRING) which would need to be applied to this draft.

I see many places where conversion would have to take place related to
UIs if the OCTET STRING format is selected, such as in the CA
administration UI and in any cert viewer UI.

My gut feeling is that it is a bit less painful to include code
conversion in all UI events than do the code conversion during the
authentication process. And in fact, there might not even be a code
conversion required during authentication.

I assume the client before doing the DNS RR query, knows/stores
knowledge of the service name and domain name as strings and not as
binary OCTET STRING, and the client would then convert anyway in its DNS
query and response process.

During authentication, the client could use its already stored string
knowledge about service and domain to compare with the content of the
certificate.

I admit that I'm speculating, but UTF8String sure feels as the preferred
solution.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 23 september 2005 15:56
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
>
> Stefan:
>
> The point that I wanted to discuss was the use of OCTET STRING to
carry
> exactly the sequence of octets that would appear in the DNS (without
the
> protocol portion).
>
> The display issue is exactly the same as displaying information that
is
> retrieved from the DNS. No better, and no worse.
>
> Russ
>
> At 09:35 PM 9/22/2005, Stefan Santesson wrote:
> >In the choice between UTF8String and OCTET STRING I definitely prefer
> >UTF8String since it makes the information displayable. IF we choose
> >OCTET STRING we need to specify which encoding we carry inside the
OCTET
> >STRING anyway.

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NE57Hl059125; Fri, 23 Sep 2005 07:05:07 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NE57e2059123; Fri, 23 Sep 2005 07:05:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from srv1.int.stroeder.com (187-2-124-83.dsl.3u.net [83.124.2.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NE56Fu059111 for ; Fri, 23 Sep 2005 07:05:06 -0700 (PDT) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by srv1.int.stroeder.com (Postfix) with ESMTP id 7EFA111DE; Fri, 23 Sep 2005 16:04:59 +0200 (CEST)
Received: from srv1.int.stroeder.com ([127.0.0.1]) by localhost (srv1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12076-01; Fri, 23 Sep 2005 16:04:52 +0200 (CEST)
Received: from [10.1.1.5] (unknown [10.1.1.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Michael Stroeder", Issuer "Thawte Personal Freemail Issuing CA" (not verified)) by srv1.int.stroeder.com (Postfix) with ESMTP id 190011181; Fri, 23 Sep 2005 16:04:52 +0200 (CEST)
Message-ID: <[email-masked]>
Date: Fri, 23 Sep 2005 16:04:50 +0200
From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050728
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: "Manger, James H"
CC: pkix
Subject: Re: draft-ietf-pkix-srvsan-00
References: <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.92.1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: amavisd-new at int.stroeder.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Manger, James H wrote:
> Russ was suggesting OCTET STRING, not IA5String, in place of
> UTF8String.

Aarrgh! Please not another string with unknown character set where every
implementor stuffs into it what he/she likes!

> I don't know much about the specifics of the DNS protocol, but I
> assume the items of interest are, semantically, either arbitrary byte
> arrays or character strings. For byte arrays use OCTET STRING. For
> characters strings use UTF8String.

Yes! I couldn't agree more.

Ciao, Michael.

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NDti8Y058391; Fri, 23 Sep 2005 06:55:44 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NDtiFN058390; Fri, 23 Sep 2005 06:55:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8NDthxU058384 for ; Fri, 23 Sep 2005 06:55:43 -0700 (PDT) (envelope-from [email-masked])
Received: (qmail 2652 invoked by uid 0); 23 Sep 2005 13:55:40 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.129.41) by woodstock.binhost.com with SMTP; 23 Sep 2005 13:55:40 -0000
Message-Id: <[email-masked]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 23 Sep 2005 09:55:39 -0400
To: "Stefan Santesson"
From: Russ Housley
Subject: RE: draft-ietf-pkix-srvsan-00
Cc: [email-masked]
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stefan:

The point that I wanted to discuss was the use of OCTET STRING to carry
exactly the sequence of octets that would appear in the DNS (without the
protocol portion).

The display issue is exactly the same as displaying information that is
retrieved from the DNS. No better, and no worse.

Russ

At 09:35 PM 9/22/2005, Stefan Santesson wrote:
>In the choice between UTF8String and OCTET STRING I definitely prefer
>UTF8String since it makes the information displayable. IF we choose
>OCTET STRING we need to specify which encoding we carry inside the OCTET
>STRING anyway.

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NBi5S5046988; Fri, 23 Sep 2005 04:44:05 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NBi5E9046987; Fri, 23 Sep 2005 04:44:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NBi3dV046973 for ; Fri, 23 Sep 2005 04:44:04 -0700 (PDT) (envelope-from [email-masked])
Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j8NBi2i09586; Fri, 23 Sep 2005 13:44:02 +0200 (MEST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Fri, 23 Sep 2005 13:44:02 +0200 (MET DST)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA03721; Fri, 23 Sep 2005 13:44:01 +0200 (MET DST)
Message-ID: <[email-masked]>
Date: Fri, 23 Sep 2005 13:44:01 +0200
From: Peter Sylvester
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Manger, James H"
CC: pkix
Subject: Re: draft-ietf-pkix-srvsan-00
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010002080808090109070003"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a cryptographically signed message in MIME format.

--------------ms010002080808090109070003
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Manger, James H wrote:

>Russ was suggesting OCTET STRING, not IA5String, in place of UTF8String.
>
>I don't know much about the specifics of the DNS protocol, but I assume the items of interest are, semantically, either arbitrary byte arrays or character strings. For byte arrays use OCTET STRING. For characters strings use UTF8String.
>
>IA5String doesn't hold all byte values and only holds a subset of characters so I see no value in using it (or any other ASN.1 string types that can only hold a subset of characters). New definitions should use UTF8String wherever they want a string. Any character restrictions should be specified with constraints or comments, not with a different [UNIVERSAL] tag.
>
>--
>IA5String alphabet = 128 characters = values [0, 127]
>
>
>
The subjectAltname has a IA5text since the. DNS has 7-bit ASCII.

Using UTF8String will raise th question for I18N names, i.e. will
we see punicode inside UTF8 or the punicode to UTF8 converted
name? Why is it necessary for a certificate using application to
convert between UTF8 and punicode?

--------------ms010002080808090109070003
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo
VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq
q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U
TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8
1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5
V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9
F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely
LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+
udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr
LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy
MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN
LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy
x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm
T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx
cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2
mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT
g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ
bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4
88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8
oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI
MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m
JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwOTIzMTE0NDAxWjAjBgkqhkiG9w0B
CQQxFgQUNUPQAZlz83HA4Dx8qoSK+Dg71aswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAdj7vmn8TIJhlT7Jk
Tcl/RVg/W5eBvj28mJuTKo/+RZ1s2TqFyrRFpDo9pypOUFYVnGkh4dnHNFlPcykXsixpUalM
thGcATpT9eDZ7SHKrXGdeoM8Qtd1vmbHDkCMKinEmDc9+pQP99M5iReTmrm7wEqNayFsrWF+
bAzmw7WS2DgAAAAAAAA=
--------------ms010002080808090109070003--

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N8OMNU026627; Fri, 23 Sep 2005 01:24:22 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8N8OMCp026626; Fri, 23 Sep 2005 01:24:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N8OLVU026610 for ; Fri, 23 Sep 2005 01:24:21 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Sep 2005 09:24:15 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-srvsan-00
Date: Fri, 23 Sep 2005 09:24:07 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-pkix-srvsan-00
Thread-Index: AcXAEuLrfRuUqzVuTier4Ft1VVq7+AAAnl/g
From: "Stefan Santesson"
To: "Olivier Dubuisson" , "Manger, James H"
Cc: "pkix"
X-OriginalArrivalTime: 23 Sep 2005 08:24:15.0793 (UTC) FILETIME=[2F75E210:01C5C018]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8N8OMVU026620
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

It looks like there are good reasons for picking UTF-8

Since the discussion started before the draft is available, and the text
of the draft is rather short, I'll the body of the draft below in this
mail.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Olivier Dubuisson
> Sent: den 23 september 2005 08:37
> To: Manger, James H
> Cc: pkix
> Subject: Re: draft-ietf-pkix-srvsan-00
>
>
> Manger, James H wrote:
> >
> > For byte arrays use OCTET STRING. For characters strings use
> UTF8String.
>
> Exactly!
>
> > IA5String doesn't hold all byte values and only holds a subset of
> > characters so I see no value in using it (or any other ASN.1
> > string types that can only hold a subset of characters). New
> > definitions should use UTF8String wherever they want a string.
> > Any character restrictions should be specified with constraints or
> > comments, not with a different [UNIVERSAL] tag.
>
> I am in 100% agreement with this.
> --
> Olivier DUBUISSON (ITU-T ASN.1 Project leader)

[Stefan]

Text of the 00 draft:

INTERNET-DRAFT S. Santesson (Microsoft)
Intended Category: Standards Track
Expires March 2006 September 2005

Internet X.509 Public Key Infrastructure
Subject Alternative Name for expression of service name

Status of this Memo

Abstract

This document defines a new name form for inclusion in the otherName
filed of an X.509 Subject Alternative Name extension which allows a
certificate subject to be associated with the service name and domain
name components of a DNS Service Resource Record.

Table of Contents

1 Introduction ................................................ 2
2 Name definitions ............................................ 3
3 Security Considerations ..................................... 3
4 IANA Considerations ......................................... 4
5 References .................................................. 4
Appendix A. ASN.1 definitions .................................. 5
Authors' Addresses ............................................. 5
Disclaimer ..................................................... 6
Copyright Statement ............................................ 6

1. Introduction

RFC 2782 [N3] Defines a DNS RR (Resource Record) for specifying the
location of services (SRV RR) which allows clients to ask for a
specific service/protocol for a specific domain and get back the
names of any available servers.

Server discovery through a DNS query based on service/protocol
relative to a domain is from an authentication perspective
fundamentally different from when a client has prior trusted
knowledge about the name and address of the server it attempts to
connect. While authentication of the name and address of a server
makes sense when the name and address of the server is prior
knowledge, it typically has very little value if the name and address
of the server is obtained from an untrusted source.

Subsequent authentication of a server discovered through DNS RR
lookup based on service name typically requires the client to
authenticate that the connected server is authorized to provide the
requested service rather than authenticating the servers host name.

While DNS servers may have the capacity to provide trusted
information, they may in many other situations not be trusted enough
to do that, in which case the server may be required to provide
verifiable credentials to support its due authorization to provide a
requested service.

One example where expression of such authorization can be very useful
is when locating and authenticating a legitimate Kerberos KDC server.

To support these scenarios, this standard defines a new name form for
expression of service name relative to a domain in X.509
certificates.

Current dNSName GeneralName Subject Alternative name form only
provide for DNS host names to be expressed in "preferred name
syntax," as specified by RFC 1034 [N4]. This definition therefore not
broad enough to allow expression of a service related to that domain.

2. Name definitions

This section defines the SRVName name as a form of otherName from the
GeneralName structure in SubjectAltName defined in RFC 3280 [N2].

id-on-sRVName OBJECT IDENTIFIER ::= { id-on ? }

SRVName ::= UTF8String (SIZE (1..MAX))

The SRVName, if present, MUST contain a service name and a domain
name in the following form:

_Service.Name

The content of the components of this name form MUST be consistent
with the corresponding definition of these components in an SRV RR
according to RFC 2782 [N3].

The content of these components are:

Service
The symbolic name of the desired service, as defined in
Assigned Numbers [N5] or locally. An underscore (_) is
prepended to the service identifier to avoid collisions with
DNS labels that occur in nature. Some widely used services,
notably POP, don't have a single universal name. If Assigned
Numbers names the service indicated, that name is the only name
which is allowed in the service component of this name form.
The Service is case insensitive.

Name
The DNS domain name of the domain where the specified service
is located.

Example: _mail.example.com

Even though this name form is based on the service resource record
(SRV RR) definition in RFC 2782 [N3] and may be used to enhance
subsequent authentication of DNS based service discovery, this
standard does not define any new conditions or requirements regarding
use of SRV RR for service discovery or where and when such use is
appropriate.

3 Security Considerations

Assignment of services to hosts may be subject to change.
Implementers should be aware of the need to revoke old certificates
that no longer reflect the current assignment of services and thus
make sure that all issued certificates are up to date.

When X.509 certificates enhanced with the name form specified in this
standard is used to enhance authentication of service discovery based
on a SRV RR query to a DNS server, all security considerations of RFC
2782 applies.

4 IANA Considerations

This document has no actions for IANA.

5 References

Normative references:

[N1] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[N2] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet
X.509 Public Key Infrastructure: Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.

[N3] A. Gulbrandsen and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2782, February 2000.

[N4] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987

[N5] J. Reynolds, "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N6acwU017599; Thu, 22 Sep 2005 23:36:38 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8N6ab1g017598; Thu, 22 Sep 2005 23:36:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N6aZnB017586 for ; Thu, 22 Sep 2005 23:36:36 -0700 (PDT) (envelope-from [email-masked])
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 08:36:33 +0200
Received: from [10.193.13.38] ([10.193.13.38]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 08:36:32 +0200
Message-ID: <[email-masked]>
Date: Fri, 23 Sep 2005 08:36:32 +0200
From: Olivier Dubuisson
Organization: France Telecom - Research & Development
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Manger, James H"
CC: pkix
Subject: Re: draft-ietf-pkix-srvsan-00
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Sep 2005 06:36:32.0927 (UTC) FILETIME=[234ACAF0:01C5C009]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Manger, James H wrote:
>
> For byte arrays use OCTET STRING. For characters strings use UTF8String.

Exactly!

> IA5String doesn't hold all byte values and only holds a subset of
> characters so I see no value in using it (or any other ASN.1
> string types that can only hold a subset of characters). New
> definitions should use UTF8String wherever they want a string.
> Any character restrictions should be specified with constraints or
> comments, not with a different [UNIVERSAL] tag.

I am in 100% agreement with this.
--
Olivier DUBUISSON (ITU-T ASN.1 Project leader)

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N1ZkCm089372; Thu, 22 Sep 2005 18:35:46 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8N1Zkaw089371; Thu, 22 Sep 2005 18:35:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N1ZinH089353 for ; Thu, 22 Sep 2005 18:35:45 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Sep 2005 02:35:39 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-srvsan-00
Date: Fri, 23 Sep 2005 02:35:37 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-pkix-srvsan-00
Thread-Index: AcW/pxNKKNSOzjoIQyCNSFGYQlwCwwAAKS/QAAjwbPAABKSgIA==
From: "Stefan Santesson"
To: "Manger, James H" , "pkix"
X-OriginalArrivalTime: 23 Sep 2005 01:35:39.0252 (UTC) FILETIME=[1A769B40:01C5BFDF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8N1ZjnH089364
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Oh - I'm sorry

Its getting late here and I missed that last line. Thanks James.

In the choice between UTF8String and OCTET STRING I definitely prefer
UTF8String since it makes the information displayable. IF we choose
OCTET STRING we need to specify which encoding we carry inside the OCTET
STRING anyway.

Then I prefer UTF8String and the cost of a potentially more complex
comparison operation.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Manger, James H
> Sent: den 23 september 2005 02:03
> To: pkix
> Subject: RE: draft-ietf-pkix-srvsan-00
>
>
> Russ was suggesting OCTET STRING, not IA5String, in place of
UTF8String.
>
> I don't know much about the specifics of the DNS protocol, but I
assume
> the items of interest are, semantically, either arbitrary byte arrays
or
> character strings. For byte arrays use OCTET STRING. For characters
> strings use UTF8String.
>
> IA5String doesn't hold all byte values and only holds a subset of
> characters so I see no value in using it (or any other ASN.1 string
types
> that can only hold a subset of characters). New definitions should
use
> UTF8String wherever they want a string. Any character restrictions
should
> be specified with constraints or comments, not with a different
> [UNIVERSAL] tag.
>
> --
> IA5String alphabet = 128 characters = values [0, 127]
>
>
>
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> Sent: Friday, 23 September 2005 5:12 AM
> To: Russ Housley
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
>
>
> Well,
>
> A number of voices were raised suggesting UTF8String to better
> accommodate a future of internationalized domain names.
> I didn't really think it mattered since we generally convert
everything
> to Unicode before comparing, but on the other side I can't really see
> the case where IA5String would not be sufficient. DNS can always be
> expressed in punicode and you are probably right that comparing would
be
> generally easier.
>
> So unless nobody raise their voice against it, I will change back to
> IA5String in next draft.
>
> For those who don't really understand what we are talking about, this
> refers to the new 00 pkix draft for an otherName based on the DNS SRV
RR
> Syntax which I submitted today, but hadn't yet hit the charter page.
It
> will hopefully be available soon.
>
> If you need it right now. Send me an e-mail.
>
>
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>
>
> > -----Original Message-----
> > From: Russ Housley [mailto:[email-masked]]
> > Sent: den 22 september 2005 20:54
> > To: Stefan Santesson
> > Cc: [email-masked]
> > Subject: draft-ietf-pkix-srvsan-00
> >
> > Stefan:
> >
> > I am much happier with this approach that the one originally
> discussed. I
> > just have one question.
> >
> > Why UTF8String? Doesn't this complicate the comparison to the bits
> that
> > come from the DNS. My understanding is that the DNS is a binary
> protocol,
> > so OCTET STRING ought to be easiest.
> >
> > Russ
>
>

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N07Ysl082975; Thu, 22 Sep 2005 17:07:34 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8N07Y9J082974; Thu, 22 Sep 2005 17:07:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mailao.vtcif.telstra.com.au (mailao.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8N07X9r082961 for ; Thu, 22 Sep 2005 17:07:34 -0700 (PDT) (envelope-from [email-masked])
Received: from mailbi.vtcif.telstra.com.au (mailbi.vtcif.telstra.com.au [202.12.142.19]) by mailao.vtcif.telstra.com.au (Postfix) with ESMTP id E06462314A for ; Fri, 23 Sep 2005 10:07:19 +1000 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 920221DA84 for ; Fri, 23 Sep 2005 10:07:19 +1000 (EST)
Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA28573 for ; Fri, 23 Sep 2005 10:07:19 +1000 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: draft-ietf-pkix-srvsan-00
Date: Fri, 23 Sep 2005 10:02:53 +1000
Message-ID: <[email-masked]>
Thread-Topic: draft-ietf-pkix-srvsan-00
Thread-Index: AcW/pxNKKNSOzjoIQyCNSFGYQlwCwwAAKS/QAAjwbPA=
From: "Manger, James H"
To: "pkix"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j8N07Y9r082969
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Russ was suggesting OCTET STRING, not IA5String, in place of UTF8String.

I don't know much about the specifics of the DNS protocol, but I assume the items of interest are, semantically, either arbitrary byte arrays or character strings. For byte arrays use OCTET STRING. For characters strings use UTF8String.

IA5String doesn't hold all byte values and only holds a subset of characters so I see no value in using it (or any other ASN.1 string types that can only hold a subset of characters). New definitions should use UTF8String wherever they want a string. Any character restrictions should be specified with constraints or comments, not with a different [UNIVERSAL] tag.

--
IA5String alphabet = 128 characters = values [0, 127]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, 23 September 2005 5:12 AM
To: Russ Housley
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-srvsan-00

Well,

A number of voices were raised suggesting UTF8String to better
accommodate a future of internationalized domain names.
I didn't really think it mattered since we generally convert everything
to Unicode before comparing, but on the other side I can't really see
the case where IA5String would not be sufficient. DNS can always be
expressed in punicode and you are probably right that comparing would be
generally easier.

So unless nobody raise their voice against it, I will change back to
IA5String in next draft.

For those who don't really understand what we are talking about, this
refers to the new 00 pkix draft for an otherName based on the DNS SRV RR
Syntax which I submitted today, but hadn't yet hit the charter page. It
will hopefully be available soon.

If you need it right now. Send me an e-mail.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 22 september 2005 20:54
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: draft-ietf-pkix-srvsan-00
>
> Stefan:
>
> I am much happier with this approach that the one originally
discussed. I
> just have one question.
>
> Why UTF8String? Doesn't this complicate the comparison to the bits
that
> come from the DNS. My understanding is that the DNS is a binary
protocol,
> so OCTET STRING ought to be easiest.
>
> Russ

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJCY8U058689; Thu, 22 Sep 2005 12:12:34 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MJCYLO058688; Thu, 22 Sep 2005 12:12:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJCWaq058681 for ; Thu, 22 Sep 2005 12:12:33 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Sep 2005 20:12:26 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-srvsan-00
Date: Thu, 22 Sep 2005 20:12:25 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-pkix-srvsan-00
Thread-Index: AcW/pxNKKNSOzjoIQyCNSFGYQlwCwwAAKS/Q
From: "Stefan Santesson"
To: "Russ Housley"
Cc:
X-OriginalArrivalTime: 22 Sep 2005 19:12:26.0717 (UTC) FILETIME=[91D830D0:01C5BFA9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8MJCXaq058682
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Well,

A number of voices were raised suggesting UTF8String to better
accommodate a future of internationalized domain names.
I didn't really think it mattered since we generally convert everything
to Unicode before comparing, but on the other side I can't really see
the case where IA5String would not be sufficient. DNS can always be
expressed in punicode and you are probably right that comparing would be
generally easier.

So unless nobody raise their voice against it, I will change back to
IA5String in next draft.

For those who don't really understand what we are talking about, this
refers to the new 00 pkix draft for an otherName based on the DNS SRV RR
Syntax which I submitted today, but hadn't yet hit the charter page. It
will hopefully be available soon.

If you need it right now. Send me an e-mail.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 22 september 2005 20:54
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: draft-ietf-pkix-srvsan-00
>
> Stefan:
>
> I am much happier with this approach that the one originally
discussed. I
> just have one question.
>
> Why UTF8String? Doesn't this complicate the comparison to the bits
that
> come from the DNS. My understanding is that the DNS is a binary
protocol,
> so OCTET STRING ought to be easiest.
>
> Russ

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MIsOtR057185; Thu, 22 Sep 2005 11:54:24 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MIsOOv057184; Thu, 22 Sep 2005 11:54:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8MIsN75057174 for ; Thu, 22 Sep 2005 11:54:23 -0700 (PDT) (envelope-from [email-masked])
Received: (qmail 17911 invoked by uid 0); 22 Sep 2005 18:54:17 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.33.150) by woodstock.binhost.com with SMTP; 22 Sep 2005 18:54:17 -0000
Message-Id: <[email-masked]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 22 Sep 2005 14:54:19 -0400
To: "Stefan Santesson"
From: Russ Housley
Subject: draft-ietf-pkix-srvsan-00
Cc: [email-masked]
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stefan:

I am much happier with this approach that the one originally discussed. I
just have one question.

Why UTF8String? Doesn't this complicate the comparison to the bits that
come from the DNS. My understanding is that the DNS is a binary protocol,
so OCTET STRING ought to be easiest.

Russ

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MDhRbf025968; Thu, 22 Sep 2005 06:43:27 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MDhRqp025967; Thu, 22 Sep 2005 06:43:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MDhQKG025958 for ; Thu, 22 Sep 2005 06:43:26 -0700 (PDT) (envelope-from [email-masked])
Received: by xproxy.gmail.com with SMTP id h29so477819wxd for ; Thu, 22 Sep 2005 06:43:18 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:from:to:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=PwhaCqVF+rlHR7uoL2//f1oogj6Q3WNskmAkk0vO5oXCfC7ciH7dr2bgcgnrIOOXaqRp/PBw4wjwbVCpvbRRjfqVk/I0kfhj1HMzoWQGgc+uC3tksqsHwVDoYA2ZQ6QjqMF1A6aUObCKAd1wpU3vo6i8Wdwws8ACEhIYRswhz28=
Received: by 10.70.105.17 with SMTP id d17mr274744wxc; Thu, 22 Sep 2005 06:43:18 -0700 (PDT)
Received: from axpvahan ( [83.139.12.226]) by mx.gmail.com with ESMTP id i20sm578271wxd.2005.09.22.06.43.12; Thu, 22 Sep 2005 06:43:18 -0700 (PDT)
Message-ID: <[email-masked]>
From: "Vahan Sardaryan"
To: "Stefan Santesson" , "pgut001" , ,
References:
Subject: Re: ExtendedKeyUsage for TLS Client Authentication
Date: Thu, 22 Sep 2005 18:41:23 +0500
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2670
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

>From my experience with CryptoAPI, it allows signing with key exchange pair,
but not encrypting with signing keys.

Vahan

----- Original Message -----
From: "Stefan Santesson"
To: "pgut001" ; ;

Sent: Thursday, September 22, 2005 5:18 PM
Subject: RE: ExtendedKeyUsage for TLS Client Authentication

>
> Peter,
>
> You may have missed that I made a correction of myself. IE and IIS do
> accept certificates with an absent EKU. It enforces and mandates
> presence of clientAuth when the EKU extension is present.
>
> On the signing with encryption keys or encrypting with signature keys,
> I'll have to come back to you.
>
> I don't think we have any real disagreement on the EKU issue.
>
>
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>
>
>> -----Original Message-----
>> From: pgut001 [mailto:[email-masked]]
>> Sent: den 22 september 2005 14:00
>> To: [email-masked]; [email-masked];
>> [email-masked]; Stefan Santesson
>> Subject: RE: ExtendedKeyUsage for TLS Client Authentication
>>
>> "Stefan Santesson" writes:
>>
>> >I think this is misleading advice. At least Microsoft implementations
> do
>> >enforce both key usage and extended key usage.
>>
>> I thought CryptoAPI explicitly allowed signing with encryption-only
> keys
>> or
>> encryption with signing-only keys (I'd have to look up the details of
>> which
>> one it was)? I've also had reports from users about it ignoring other
>> usage
>> restrictions... some of this dates back a few years, so maybe it's
> gotten
>> better now. OTOH it was only two years ago that CryptoAPI actually
>> started
>> bothering to pay attention to the CA flag, and only then because of
>> widespread
>> bad publicity.
>>
>> (The reason why I made the comment was that cryptlib is very careful
> about
>> enforcing key usage (and any other) constraints, and the probably
> single
>> biggest set of user complaints that I get is from users saying that
> certs
>> they've used for ages can't be used with cryptlib. The result is
>> invariably
>> that they're trying to encrypt with a signature-only cert, or
> something
>> similar. Only about two weeks ago I got mail from a PKI application
>> developer to say that cryptlib was the first PKI code he'd ever run
> into
>> that
>> recognised (and rejected) the use of a CA-cert/CRL-signature-only
> cert
>> for
>> data encryption).
>>
>> Peter.
>

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MCIgKV017268; Thu, 22 Sep 2005 05:18:42 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MCIgCV017267; Thu, 22 Sep 2005 05:18:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MCIeAI017242 for ; Thu, 22 Sep 2005 05:18:41 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Sep 2005 13:18:35 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: ExtendedKeyUsage for TLS Client Authentication
Date: Thu, 22 Sep 2005 13:18:34 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: ExtendedKeyUsage for TLS Client Authentication
Thread-Index: AcW/bR6Wsntdi24RQz6X72uhmVAAYQAAa1qA
From: "Stefan Santesson"
To: "pgut001" , ,
X-OriginalArrivalTime: 22 Sep 2005 12:18:35.0029 (UTC) FILETIME=[C1014C50:01C5BF6F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8MCIfAI017262
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Peter,

You may have missed that I made a correction of myself. IE and IIS do
accept certificates with an absent EKU. It enforces and mandates
presence of clientAuth when the EKU extension is present.

On the signing with encryption keys or encrypting with signature keys,
I'll have to come back to you.

I don't think we have any real disagreement on the EKU issue.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: pgut001 [mailto:[email-masked]]
> Sent: den 22 september 2005 14:00
> To: [email-masked]; [email-masked];
> [email-masked]; Stefan Santesson
> Subject: RE: ExtendedKeyUsage for TLS Client Authentication
>
> "Stefan Santesson" writes:
>
> >I think this is misleading advice. At least Microsoft implementations
do
> >enforce both key usage and extended key usage.
>
> I thought CryptoAPI explicitly allowed signing with encryption-only
keys
> or
> encryption with signing-only keys (I'd have to look up the details of
> which
> one it was)? I've also had reports from users about it ignoring other
> usage
> restrictions... some of this dates back a few years, so maybe it's
gotten
> better now. OTOH it was only two years ago that CryptoAPI actually
> started
> bothering to pay attention to the CA flag, and only then because of
> widespread
> bad publicity.
>
> (The reason why I made the comment was that cryptlib is very careful
about
> enforcing key usage (and any other) constraints, and the probably
single
> biggest set of user complaints that I get is from users saying that
certs
> they've used for ages can't be used with cryptlib. The result is
> invariably
> that they're trying to encrypt with a signature-only cert, or
something
> similar. Only about two weeks ago I got mail from a PKI application
> developer to say that cryptlib was the first PKI code he'd ever run
into
> that
> recognised (and rejected) the use of a CA-cert/CRL-signature-only
cert
> for
> data encryption).
> Peter.

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MBxcm7015558; Thu, 22 Sep 2005 04:59:38 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MBxcZr015557; Thu, 22 Sep 2005 04:59:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MBxbKO015547 for ; Thu, 22 Sep 2005 04:59:37 -0700 (PDT) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id B120B341DC; Thu, 22 Sep 2005 23:59:31 +1200 (NZST)
Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30213-10; Thu, 22 Sep 2005 23:59:31 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id F39EA340F7; Thu, 22 Sep 2005 23:59:30 +1200 (NZST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id EE15637756; Thu, 22 Sep 2005 23:59:30 +1200 (NZST)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EIPjn-0000JH-00; Thu, 22 Sep 2005 23:59:39 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: ExtendedKeyUsage for TLS Client Authentication
In-Reply-To:
Message-Id:
Date: Thu, 22 Sep 2005 23:59:39 +1200
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

"Stefan Santesson" writes:

>I think this is misleading advice. At least Microsoft implementations do
>enforce both key usage and extended key usage.

I thought CryptoAPI explicitly allowed signing with encryption-only keys or
encryption with signing-only keys (I'd have to look up the details of which
one it was)? I've also had reports from users about it ignoring other usage
restrictions... some of this dates back a few years, so maybe it's gotten
better now. OTOH it was only two years ago that CryptoAPI actually started
bothering to pay attention to the CA flag, and only then because of widespread
bad publicity.

(The reason why I made the comment was that cryptlib is very careful about
enforcing key usage (and any other) constraints, and the probably single
biggest set of user complaints that I get is from users saying that certs
they've used for ages can't be used with cryptlib. The result is invariably
that they're trying to encrypt with a signature-only cert, or something
similar. Only about two weeks ago I got mail from a PKI application
developer to say that cryptlib was the first PKI code he'd ever run into that
recognised (and rejected) the use of a CA-cert/CRL-signature-only cert for
data encryption).

Peter.

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8M9gs4R003117; Thu, 22 Sep 2005 02:42:54 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8M9gs6W003114; Thu, 22 Sep 2005 02:42:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8M9gpBF003035 for ; Thu, 22 Sep 2005 02:42:51 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Sep 2005 10:42:45 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: ExtendedKeyUsage for TLS Client Authentication
Date: Thu, 22 Sep 2005 10:42:44 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: ExtendedKeyUsage for TLS Client Authentication
Thread-Index: AcW+sK/ZI9paoeTlSsOJ2rqgNP0oogApnA/Q
From: "Stefan Santesson"
To: "Johannes Merkle" ,
Cc: "Peter Gutmann"
X-OriginalArrivalTime: 22 Sep 2005 09:42:45.0480 (UTC) FILETIME=[FC3D5680:01C5BF59]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8M9gqBF003072
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Johannes,

I have to correct myself slightly.

Microsoft IE and IIS do enforce EKU and the presence of the clientAuth
EKU when the EKU extension is present. When no EKU extension is present
the certificate is good for all usages and will as such also be
accepted.

When or not it is appropriate to include an EKU extension with usage
restrictions is up to the implementation dependent on your need to
distinguish different types of certificates.

I'll reply/comment further in-line;

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Johannes Merkle [mailto:[email-masked]]
> Sent: den 21 september 2005 15:31
> To: [email-masked]
> Cc: Stefan Santesson; Peter Gutmann
> Subject: Re: ExtendedKeyUsage for TLS Client Authentication
>
> Thank you Stefan
>
> > At least Microsoft implementations do enforce both key usage and
> > extended key usage. For TLS client side authentication, the
clientAuth
> > EKU is required.
> So, IE and IIS only accept client certificates having the EKU
> clientAuth?
>

[Stefan] As stated above. clientAuth is enforced if the EKU extension is
present.

>
> > To achieve best possible interoperability, I would suggest always
> > including the clientAuth EKU in these certs.
> The problem is that EKU is restrictive, i.e. the certificate MUST
> only be used for those purposes indicated in the EKU. Now consider a
> case where a class of certifiates should be usable for many purposes
> including TLS, e-mail and document signing. Considering your
> statement I should include the EKUs clientAuth AND
> AnyExtendedKeyUsage, right? (I know that using a certifivcate for
> different application types can be poblematic. However, we only aim
> at a medium security level.)
>

[Stefan] As I said, no EKU extension will work. However, AnyEKU may not
do the job for you since I don't think many implementations make use of
the anyEKU as the special case it is designed for. The current
definition of anyEKU is correct but in my mind a bit unclear. Unlike the
special policy anyPolicy which is a direct mapping against any specific
certificate policy, the anyEKU OID does not provide that type of generic
mapping. It only allows a client at its own discretion to disregard from
the presence of the EKU extension and accept the certificate for all
usages. An application that requires a specific EKU to be present may
not accept anyEKU as substitution. An example of this is how the current
PKINIT draft in Kerberos is formulated, where anyEKU is not accepted as
a substitution in cases where the Kerberos EKU is enforced.

>
> Stefan, does Microsoft Outlook analogously require the EKU
> emailProtection?
>
[Stefan] the emailProtection EKU is required if an EKU extension is
present. An absent EKU extension will also work.

> Stefan,
>
> at which point would a certificate without EKU clientAuth fail? When
> selecting it with IE or when validating it at an IIS?
>

[Stefan] A certificate with a (presumed non empty) EKU extension with
absent clientAuth EKU will fail in both IE and IIS. In IE it will not be
selected and will not be shown in the certificate selection dialogue. If
used by any client anyway, it will not be accepted by IIS.

I hope this clarifies things.

/Stefan

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LG7DGT002254; Wed, 21 Sep 2005 09:07:13 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LG7Dr8002253; Wed, 21 Sep 2005 09:07:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mx2.cryptopro.ru (mx2.cryptopro.ru [213.59.158.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LG76sf002235 for ; Wed, 21 Sep 2005 09:07:10 -0700 (PDT) (envelope-from [email-masked])
Received: from fandra2k ([192.168.68.6]) by mx2.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Sep 2005 20:11:14 +0400
Message-ID: <[email-masked]>
From: "Gregory S. Chudov"
To: "Johannes Merkle" ,
References: <[email-masked]>
Subject: Re: ExtendedKeyUsage for TLS Client Authentication
Date: Wed, 21 Sep 2005 20:11:15 +0400
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.1830
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
X-OriginalArrivalTime: 21 Sep 2005 16:11:14.0906 (UTC) FILETIME=[1753BBA0:01C5BEC7]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Johannes Merkle writes:

> So, IE and IIS only accept client certificates having the EKU
> clientAuth?
_IF_ the client certificate has EKU extension at all.
When this extension is not present, certificate is accepted.
I don't know of any TLS implementations that require its presence.

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LEoPoX092819; Wed, 21 Sep 2005 07:50:25 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LEoPSf092818; Wed, 21 Sep 2005 07:50:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8LEoNM3092806 for ; Wed, 21 Sep 2005 07:50:24 -0700 (PDT) (envelope-from [email-masked])
Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id D318C10125 for ; Wed, 21 Sep 2005 10:50:16 -0400 (EDT)
Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01285-44 for ; Wed, 21 Sep 2005 10:50:16 -0400 (EDT)
Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 02DCB100DB for ; Wed, 21 Sep 2005 10:50:16 -0400 (EDT)
Received: from morg ([10.0.8.144]) by certicom1.certicom.com (Lotus Domino Release 6.5.4) with ESMTP id 2005092110513422-16523 ; Wed, 21 Sep 2005 10:51:34 -0400
Date: Wed, 21 Sep 2005 10:50:14 -0400
From: Sam Roberts
To: [email-masked]
Subject: Re: ExtendedKeyUsage for TLS Client Authentication
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
In-Reply-To:
User-Agent: Mutt/1.5.6+20040907i
X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 09/21/2005 10:51:34 AM, Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 09/21/2005 10:51:35 AM, Serialize complete at 09/21/2005 10:51:35 AM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Wrote Peter Gutmann , on Wed, Sep 21, 2005 at 06:21:23PM +1200:
>
> Johannes Merkle writes:
>
> >RFC 3280 defines the ExtendedKeyUsage clienthAuth for TLS client
> >authentication. However, it is not specified whether this
> >extendedKeyUsage is mandatory for TLS client certificates.
> >
> >Do clients and servers commonly require this extendedKeyUsage for
> >TLS client certificates or can it be omitted?

The SSL/TLS specs (maybe 1.1 is different) say almost nothing about cert
val, they just say "X.509 cert" and reference PKIX, essentially. I guess
you could use an X.509 attribute cert, technically.

The PKIX specs don't specify SHOULDs or MUSTs for particular protocols,
thats up to the protocol group. Though they define an OID to be used for
that protocol I'm not aware of any RFC saying what to use it for. Last
time I looked for more information on this, I found it a bit murky, in
my opinion. Murk is a problem.

Cheers,
Sam

--
http://www.certicom.com

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LDUftn085473; Wed, 21 Sep 2005 06:30:41 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LDUeVt085472; Wed, 21 Sep 2005 06:30:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from b.mx.secunet.com (b.mx.secunet.com [213.68.205.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LDUe3Q085461 for ; Wed, 21 Sep 2005 06:30:40 -0700 (PDT) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by b.mx.secunet.com (Postfix) with ESMTP id 7FDCA809; Wed, 21 Sep 2005 15:28:00 +0200 (CEST)
Received: from snsrv019.secumail.de (unknown [10.53.40.80]) by b.mx.secunet.com (Postfix) with ESMTP id 630B8376; Wed, 21 Sep 2005 15:28:00 +0200 (CEST)
Received: from [10.208.1.212] ([10.208.1.212]) by snsrv019.secumail.de with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Sep 2005 15:31:26 +0200
Message-ID: <[email-masked]>
Date: Wed, 21 Sep 2005 15:30:33 +0200
From: Johannes Merkle
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [email-masked]
CC: Stefan Santesson , Peter Gutmann
Subject: Re: ExtendedKeyUsage for TLS Client Authentication
References:
In-Reply-To:
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Sep 2005 13:31:26.0031 (UTC) FILETIME=[C3E985F0:01C5BEB0]
X-Virus-Scanned: by secunet
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Thank you Stefan

> At least Microsoft implementations do enforce both key usage and
> extended key usage. For TLS client side authentication, the clientAuth
> EKU is required.
So, IE and IIS only accept client certificates having the EKU
clientAuth?

> To achieve best possible interoperability, I would suggest always
> including the clientAuth EKU in these certs.
The problem is that EKU is restrictive, i.e. the certificate MUST
only be used for those purposes indicated in the EKU. Now consider a
case where a class of certifiates should be usable for many purposes
including TLS, e-mail and document signing. Considering your
statement I should include the EKUs clientAuth AND
AnyExtendedKeyUsage, right? (I know that using a certifivcate for
different application types can be poblematic. However, we only aim
at a medium security level.)

Stefan, does Microsoft Outlook analogously require the EKU
emailProtection?

Johannes

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LDHLa0083934; Wed, 21 Sep 2005 06:17:21 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LDHLm4083933; Wed, 21 Sep 2005 06:17:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LDHJgc083918 for ; Wed, 21 Sep 2005 06:17:19 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Sep 2005 14:17:13 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: ExtendedKeyUsage for TLS Client Authentication
Date: Wed, 21 Sep 2005 14:17:07 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: ExtendedKeyUsage for TLS Client Authentication
Thread-Index: AcW+fUm6nLgNj83rSq+BWEwUeTdlXwAMKJsQ
From: "Stefan Santesson"
To: "Peter Gutmann" , ,
X-OriginalArrivalTime: 21 Sep 2005 13:17:13.0674 (UTC) FILETIME=[C7DE2AA0:01C5BEAE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8LDHKgc083926
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Peter,

I think this is misleading advice.
At least Microsoft implementations do enforce both key usage and
extended key usage. For TLS client side authentication, the clientAuth
EKU is required. EKU is a widely deployed solution for certificate
purpose distinction and works pretty well.

To achieve best possible interoperability, I would suggest always
including the clientAuth EKU in these certs.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Peter Gutmann
> Sent: den 21 september 2005 08:21
> To: [email-masked]; [email-masked]
> Subject: Re: ExtendedKeyUsage for TLS Client Authentication
>
>
> Johannes Merkle writes:
>
> >RFC 3280 defines the ExtendedKeyUsage clienthAuth for TLS client
> >authentication. However, it is not specified whether this
> >extendedKeyUsage is mandatory for TLS client certificates.
> >
> >Do clients and servers commonly require this extendedKeyUsage for
> >TLS client certificates or can it be omitted?
>
> I've seen it appear in one or two certs from boutique CAs, but I'm not
> aware
> of anything that cares about it. It's hard enough finding software
> that'll
> pay any attention to keyUsage values, let alone extKeyUsage.
>
> In other words you can include or omit it as it suits you.
>
> Peter.

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8L6LQkr043983; Tue, 20 Sep 2005 23:21:26 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8L6LQOf043982; Tue, 20 Sep 2005 23:21:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8L6LPdO043970 for ; Tue, 20 Sep 2005 23:21:25 -0700 (PDT) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 42B3233ED1; Wed, 21 Sep 2005 18:21:19 +1200 (NZST)
Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11925-01; Wed, 21 Sep 2005 18:21:19 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id D66C33403C; Wed, 21 Sep 2005 18:21:18 +1200 (NZST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 54DBA37742; Wed, 21 Sep 2005 18:21:18 +1200 (NZST)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EHxyt-0002Cw-00; Wed, 21 Sep 2005 18:21:23 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: ExtendedKeyUsage for TLS Client Authentication
In-Reply-To: <[email-masked]>
Message-Id:
Date: Wed, 21 Sep 2005 18:21:23 +1200
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Johannes Merkle writes:

>RFC 3280 defines the ExtendedKeyUsage clienthAuth for TLS client
>authentication. However, it is not specified whether this
>extendedKeyUsage is mandatory for TLS client certificates.
>
>Do clients and servers commonly require this extendedKeyUsage for
>TLS client certificates or can it be omitted?

I've seen it appear in one or two certs from boutique CAs, but I'm not aware
of anything that cares about it. It's hard enough finding software that'll
pay any attention to keyUsage values, let alone extKeyUsage.

In other words you can include or omit it as it suits you.

Peter.

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KJo5St090302; Tue, 20 Sep 2005 12:50:05 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KJo5Kq090301; Tue, 20 Sep 2005 12:50:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KJo5RH090294 for ; Tue, 20 Sep 2005 12:50:05 -0700 (PDT) (envelope-from [email-masked])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EHo7t-000202-Li; Tue, 20 Sep 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-sim-06.txt
Message-Id:
Date: Tue, 20 Sep 2005 15:50:01 -0400
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

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

Title : Internet X.509 Public Key Infrastructure
Subject Identification Method (SIM)
Author(s) : J. Park, et al.
Filename : draft-ietf-pkix-sim-06.txt
Pages : 17
Date : 2005-9-20

This document defines the Subject Identification Method (SIM) for
including a privacy sensitive identifier in the subjectAltName
extension of a certificate.

The SIM is an optional feature that may be used by relying parties to
determine whether the subject of a particular certificate is also the
person corresponding to a particular sensitive identifier.

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-sim-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-sim-06.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-sim-06.txt

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

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

--OtherAccess--

--NextPart--

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KFv0eb067167; Tue, 20 Sep 2005 08:57:00 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KFv0tn067166; Tue, 20 Sep 2005 08:57:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from b.mx.secunet.com (b.mx.secunet.com [213.68.205.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KFv01B067140 for ; Tue, 20 Sep 2005 08:57:00 -0700 (PDT) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by b.mx.secunet.com (Postfix) with ESMTP id 31FAF7B5 for ; Tue, 20 Sep 2005 17:54:22 +0200 (CEST)
Received: from snsrv019.secumail.de (unknown [10.53.40.80]) by b.mx.secunet.com (Postfix) with ESMTP id 6361F9 for ; Tue, 20 Sep 2005 17:54:21 +0200 (CEST)
Received: from [10.208.1.212] ([10.208.1.212]) by snsrv019.secumail.de with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Sep 2005 17:57:43 +0200
Message-ID: <[email-masked]>
Date: Tue, 20 Sep 2005 17:56:51 +0200
From: Johannes Merkle
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [email-masked]
Subject: ExtendedKeyUsage for TLS Client Authentication
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Sep 2005 15:57:43.0890 (UTC) FILETIME=[0982C320:01C5BDFC]
X-Virus-Scanned: by secunet
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi,
RFC 3280 defines the ExtendedKeyUsage clienthAuth for TLS client
authentication. However, it is not specified whether this
extendedKeyUsage is mandatory for TLS client certificates.

Do clients and servers commonly require this extendedKeyUsage for
TLS client certificates or can it be omitted?

regards,
Johannes

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KBYM1T039398; Tue, 20 Sep 2005 04:34:22 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KBYMS6039397; Tue, 20 Sep 2005 04:34:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from b.mx.secunet.com (b.mx.secunet.com [213.68.205.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KBYJ9C039377 for ; Tue, 20 Sep 2005 04:34:22 -0700 (PDT) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by b.mx.secunet.com (Postfix) with ESMTP id D1983719 for ; Tue, 20 Sep 2005 13:31:41 +0200 (CEST)
Received: from snsrv019.secumail.de (unknown [10.53.40.80]) by b.mx.secunet.com (Postfix) with ESMTP id 083E543 for ; Tue, 20 Sep 2005 13:31:41 +0200 (CEST)
Received: from [10.208.1.212] ([10.208.1.212]) by snsrv019.secumail.de with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Sep 2005 13:35:04 +0200
Message-ID: <[email-masked]>
Date: Tue, 20 Sep 2005 13:34:11 +0200
From: Johannes Merkle
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [email-masked]
Subject: Re: Loop in revocation checking
References: <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Sep 2005 11:35:04.0171 (UTC) FILETIME=[57FC7BB0:01C5BDD7]
X-Virus-Scanned: by secunet
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Piyush,

I understand your objections against this setting and my suggestion
for an algoithm behaviour in case of loops. However, I feel that all
other solutions are not optimal.

> This scenario is okay. The only issue is - how to perform revocation
> status check on CRL signer.
> Usually it is solved by the root CA issuing a small long lived CRL and
> having the CRL signer distribution point pointing to this CRL.

Th problem with long lived CRLs (which are updated after
revocations) is that the verifier can't be sure whether he has
obined the latest version. An attacker could have replaced the
current CRL with an old one, which has (according to the nextupdate
date) not yet expired.

> OCSP solution is slightly different. CA's can issue short lived OCSP
> responder certificates with ocspNoCheck extensions. This tells the
> clients that no revocation status check needs to be performed on
> responder's certificate

This is also a compromise betwen security and usability.

> The other alternative is to sign the OCSP responses using CA key.

This means that the CA key is in operation on a publicly accessible
server. This doesn't seem to be a perfect solution either.

> OCSP responder's reply cannot be trusted until CRL signer's status is
> verified.
> CRL signer's CRL cannot be trusted unless OCSP responder's status is
> verified.

Which means that revocation status checking has come to a dead end.
This is a similar situation as with self-signed certificates.
However, for self-signed certificates a standard behavior is defined
for validation algorithms.

My point is that such a standard behaviour definition is missing in
the PKIX documents for revocation checking loops. A postulated
validity in case of such loops would allow more secure and flexible
provision of revocation status.

Regards,
Johannes

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JH8ao0031618; Mon, 19 Sep 2005 10:08:36 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JH8aw3031617; Mon, 19 Sep 2005 10:08:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JH8Zs2031608 for ; Mon, 19 Sep 2005 10:08:35 -0700 (PDT) (envelope-from [email-masked])
Received: from 10.1.5.72 by mms2-dmz.tumbleweed.com with ESMTP ( Tumbleweed MMS SMTP Relay (Email Firewall v6.2.0)); Mon, 19 Sep 2005 10:16:34 -0700
X-Server-Uuid: 2D73907E-7E27-47BF-AAA8-9E1C3BEBCAB2
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Loop in revocation checking
Date: Mon, 19 Sep 2005 10:08:27 -0700
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Loop in revocation checking
Thread-Index: AcW9HJug1VgBdKfXTICEP1je6IQnngAG2+vw
From: "Piyush Jain"
To: "Johannes Merkle" , [email-masked]
X-WSS-ID: 6F302DFB230163800-01-03
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8JH8Zs2031611
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Comments inline.

>>>-----Original Message-----
>>>From: [email-masked]
[mailto:[email-masked]]
>>>On Behalf Of Johannes Merkle
>>>Sent: Monday, September 19, 2005 5:11 AM
>>>To: [email-masked]
>>>Subject: Re: Loop in revocation checking
>>>
>>>
>>>> We are faced with a situation, where a certification service plans
>>>> to use
>>>> the following scenario:
>>>
>>>ok, first of all I would like to "confess" that I am one of the
>>>designers of this "weird" PKI architecture.
>>>
>>>
>>>> - A self-signed root CA, as usual.
>>>> - A CRL issuer, using the indirect CRL mechanism.
>>>> - An OCSP responder.
>>>> - The Certificate for the CRL issuer contains an AIA-extension
pointing
>>>> to the OCSP-responder.
>>>> - The Certificate for the OCSP responder contains a
>>>> CRL-Distribution-Point pointing to the CRL issuer.
>>>> - The certificates for OCSP-Responder and CRL issuer both contain
>>>> an AIA extension pointing to the OCSP responder and the CRL
>>>> distribution point.
>>>> - The self signed certificate contains both an AIA-extension
pointing
>>>> to the OCSP-responder and a CRL distribution point pointing to
the
>>>CRL
>>>> issued by the CRL issuer.
>>>
>>>
>>>In order to focus on the core of the problem , I describe a much
>>>simpler scenario, where the problem is already present:
>>>
>>>- A trusted root-CA, which does not issue CRLs
>>>- A CRL signer that issues indirect CRLs for that CA.
>>>- The certificate of the CRL signer is issued by the Root-CA.
>>>- The certificate of the CRL signer contains a CRL Distribution
>>>point identifying the CRL signr as the issuing authority.
>>>

This scenario is okay. The only issue is - how to perform revocation
status check on CRL signer.
Usually it is solved by the root CA issuing a small long lived CRL and
having the CRL signer distribution point pointing to this CRL.
OCSP solution is slightly different. CA's can issue short lived OCSP
responder certificates with ocspNoCheck extensions. This tells the
clients that no revocation status check needs to be performed on
responder's certificate
>>>
>>>According to RFC 3280 a validation algorithm should check the
>>>revocation status of all certificates in the validation path, i.e.
>>>for all certificates except the trust anchors (in our scenario the
>>>self-signed root certificate). Consequently revocation status is
>>>checked for the CRL signer certificate as well. However, this ends
>>>up in a loop. So I only see two possible solutions:
>>>
>>>1. Avoid such architectures, precisely, (on the top level of the
>>>hierarchy) employ only CRL signers with self-signed certificates,
>>>i.e CRL signers which are trust anchors. The drawback of such an
>>>approach is that either this trust anchor must be permanently in
>>>operation and "online" (i.e. connected to the repository which is
>>>online), or you would have to manually and periodicaly generate and
>>>transfer new CRLs. For high security demands you would certainly
>>>want to lock away your trust anchor's private keys most of the time
>>>and employ relatively short CRL issuing intervals.
>>>
>>>2. The validation algorithm detects the loop assumes that the CRL
>>>signer certificate is valid. This is justified by the fact that -
>>>according to the CRL distribution point information - there is no
>>>superior authority from which revocation status can be obtained. So
>>>the CRL signer must be a "trust anchor for revocation status".

Assuming that a certificate is valid - is incorrect in this case.
I'm not sure why an extension similar to ocspNocheck is not defined for
CRL signers. May be the experts thought that it would be redundant, as
this problem can be solved my making use of a distribution point ( See
above).
>>>
>>>I know that this interpretation is not implied by any of the PKIX
>>>documents but rather by the awareness that indirect CRLs issued by
>>>CRL signers with certificates issued by the root CA will inevitably
>>>cause such validation loops. On the other hand, I have never seen
>>>any requirement or recommendation saying that signers of indirect
>>>CRLs must have self-signed certificates.
>>>
>>>
>>>With OCSP responders the situation is similar. It is not a good idea
>>> to use self-signed certificates for the responder, because then an
>>>attacker could try to redirect the requests to its own responder. On
>>>the other hand, if there is no superior OCSP-Respoder or CRL in the
>>>PKI hierarchy, checking of revocation status of the reponder
>>>certificate does make any sense.
>>>
ocspNoCheck with short lived responder certificates solves this.
The other alternative is to sign the OCSP responses using CA key.

>>>Yes, the extension OCSPNoCheck provides a way to prevent validation
>>>loops, but there is no equivalent extension for CRL.

I'm not sure why there is no equivalent extension for CRLs. In my
opinion it would provide similar benefits as it does for OCSP.

>>>Furthermore, in
>>>the presence of both, OCSP responder AND CRL, the security can be
>>>greatly enhanced if the CRL signer propagates the revocation status
>>>of the OCSP reponder and vice versa: A key compromise of only one
>>>those two can be detected using the status information provided by
>>>the other one.
>
OCSP responder's reply cannot be trusted until CRL signer's status is
verified.
CRL signer's CRL cannot be trusted unless OCSP responder's status is
verified.
You need the root CA to provide the status of at least one of them to
make a decision one way or other.
Alternatively, you can directly trust the CRL signer.

>>>
>>>I think, the standard behavior for validation algorithms detecting
>>>loops while checking status information of CRL signer / OCSP
>>>reponder certificates should be defined in future PKIX documents.
>>>
>>>
>>>Regards,
>>>Johannes

Cheers
Piyush

"Tumbleweed E-mail Firewall " made the following
annotations on 09/19/05 10:16:38
------------------------------------------------------------------------------
This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
==============================================================================

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JCAdST002212; Mon, 19 Sep 2005 05:10:39 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JCAdxX002211; Mon, 19 Sep 2005 05:10:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from b.mx.secunet.com (b.mx.secunet.com [213.68.205.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JCAc4A002200 for ; Mon, 19 Sep 2005 05:10:38 -0700 (PDT) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by b.mx.secunet.com (Postfix) with ESMTP id C0F05719 for ; Mon, 19 Sep 2005 14:08:02 +0200 (CEST)
Received: from snsrv019.secumail.de (unknown [10.53.40.80]) by b.mx.secunet.com (Postfix) with ESMTP id D7BB849 for ; Mon, 19 Sep 2005 14:08:01 +0200 (CEST)
Received: from [10.208.1.212] ([10.208.1.212]) by snsrv019.secumail.de with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Sep 2005 14:11:22 +0200
Message-ID: <[email-masked]>
Date: Mon, 19 Sep 2005 14:10:30 +0200
From: Johannes Merkle
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [email-masked]
Subject: Re: Loop in revocation checking
References: <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Sep 2005 12:11:22.0718 (UTC) FILETIME=[40169FE0:01C5BD13]
X-Virus-Scanned: by secunet
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> We are faced with a situation, where a certification service plans
> to use
> the following scenario:

ok, first of all I would like to "confess" that I am one of the
designers of this "weird" PKI architecture.

> - A self-signed root CA, as usual.
> - A CRL issuer, using the indirect CRL mechanism.
> - An OCSP responder.
> - The Certificate for the CRL issuer contains an AIA-extension pointing
> to the OCSP-responder.
> - The Certificate for the OCSP responder contains a
> CRL-Distribution-Point pointing to the CRL issuer.
> - The certificates for OCSP-Responder and CRL issuer both contain
> an AIA extension pointing to the OCSP responder and the CRL
> distribution point.
> - The self signed certificate contains both an AIA-extension pointing
> to the OCSP-responder and a CRL distribution point pointing to the CRL
> issued by the CRL issuer.

In order to focus on the core of the problem , I describe a much
simpler scenario, where the problem is already present:

- A trusted root-CA, which does not issue CRLs
- A CRL signer that issues indirect CRLs for that CA.
- The certificate of the CRL signer is issued by the Root-CA.
- The certificate of the CRL signer contains a CRL Distribution
point identifying the CRL signr as the issuing authority.

According to RFC 3280 a validation algorithm should check the
revocation status of all certificates in the validation path, i.e.
for all certificates except the trust anchors (in our scenario the
self-signed root certificate). Consequently revocation status is
checked for the CRL signer certificate as well. However, this ends
up in a loop. So I only see two possible solutions:

1. Avoid such architectures, precisely, (on the top level of the
hierarchy) employ only CRL signers with self-signed certificates,
i.e CRL signers which are trust anchors. The drawback of such an
approach is that either this trust anchor must be permanently in
operation and "online" (i.e. connected to the repository which is
online), or you would have to manually and periodicaly generate and
transfer new CRLs. For high security demands you would certainly
want to lock away your trust anchor's private keys most of the time
and employ relatively short CRL issuing intervals.

2. The validation algorithm detects the loop assumes that the CRL
signer certificate is valid. This is justified by the fact that -
according to the CRL distribution point information - there is no
superior authority from which revocation status can be obtained. So
the CRL signer must be a "trust anchor for revocation status".

I know that this interpretation is not implied by any of the PKIX
documents but rather by the awareness that indirect CRLs issued by
CRL signers with certificates issued by the root CA will inevitably
cause such validation loops. On the other hand, I have never seen
any requirement or recommendation saying that signers of indirect
CRLs must have self-signed certificates.

With OCSP responders the situation is similar. It is not a good idea
to use self-signed certificates for the responder, because then an
attacker could try to redirect the requests to its own responder. On
the other hand, if there is no superior OCSP-Respoder or CRL in the
PKI hierarchy, checking of revocation status of the reponder
certificate does make any sense.

Yes, the extension OCSPNoCheck provides a way to prevent validation
loops, but there is no equivalent extension for CRL. Furthermore, in
the presence of both, OCSP responder AND CRL, the security can be
greatly enhanced if the CRL signer propagates the revocation status
of the OCSP reponder and vice versa: A key compromise of only one
those two can be detected using the status information provided by
the other one.

I think, the standard behaviour for validation algorithms detecting
loops while checking status information of CRL signer / OCSP
reponder certificates should be defined in future PKIX documents.

Regards,
Johannes

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JBtWZE001374; Mon, 19 Sep 2005 04:55:32 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JBtWG5001373; Mon, 19 Sep 2005 04:55:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JBtVN8001367 for ; Mon, 19 Sep 2005 04:55:32 -0700 (PDT) (envelope-from [email-masked])
Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j8JBtNvU009423; Mon, 19 Sep 2005 07:55:27 -0400
From: "Santosh Chokhani"
To: "'pkix'" , "'Sam Hartman'"
Subject: RE: IESG last call changes to the CRL AIA draft
Date: Mon, 19 Sep 2005 07:55:12 -0400
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To:
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8JBtWN8001368
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stefan,

I fully agree with you.

I was try to point out to Denis that there is more than one circumstance for
the certificate not being a "CA certificate".

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Monday, September 19, 2005 5:16 AM
To: Santosh Chokhani; pkix; Sam Hartman
Subject: RE: IESG last call changes to the CRL AIA draft

Process wise this document is approved by IESG and is currently in the RFC
editors queue.

On the fact I don't see any reason to change the current text. The current
text is correct and expresses the relevant conclusion, that is, one must be
prepared to look in all the 3 listed attributes when using the directoryName
form of accessLocation.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 18 september 2005 17:53
> To: 'pkix'; 'Sam Hartman'
> Subject: RE: IESG last call changes to the CRL AIA draft
>
>
> This statement is incomplete and possibly misleading. Indirect CRL
issuer
> (when the ICRL Authority) is not a CA, its certificate will also have
> these characteristics.
>
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Denis Pinkas
> Sent: Sunday, September 18, 2005 10:32 AM
> To: David A. Cooper
> Cc: pkix; Sam Hartman
> Subject: Re: IESG last call changes to the CRL AIA draft
>
>
>
> David,
>
> Thank you for the explanations. The current text addition proposal is
> the following:
>
> "When different public keys are used to validate signatures on
> certificates and CRLs, the desired certificate is stored in the
> userCertificate attribute as specified in [RFC 2587]".
>
> Along the lines of your explanations, I would propose:
>
> "When the certificate pointed to by the AIA extension in the CRL is
only
> used to verify
> signatures on CRLs, but not signatures on certificates (i.e. different
> public keys are used to validate signatures on certificates and CRLs),
> the desired certificate is stored in the
> userCertificate attribute as specified in [RFC 2587]".
>
> Denis

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8J9ZZor010029; Mon, 19 Sep 2005 02:35:35 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8J9Fnvv073764; Mon, 19 Sep 2005 02:15:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8J9Fl1j073443 for ; Mon, 19 Sep 2005 02:15:47 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 10:15:36 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: IESG last call changes to the CRL AIA draft
Date: Mon, 19 Sep 2005 10:15:34 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: IESG last call changes to the CRL AIA draft
Thread-Index: AcW8jNgwbnBq+ztQSrCAePCNsvo2JQAa/Vuw
From: "Stefan Santesson"
To: "Santosh Chokhani" , "pkix" , "Sam Hartman"
X-OriginalArrivalTime: 19 Sep 2005 09:15:36.0832 (UTC) FILETIME=[B2402000:01C5BCFA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8J9Fm1j073690
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Process wise this document is approved by IESG and is currently in the
RFC editors queue.

On the fact I don't see any reason to change the current text. The
current text is correct and expresses the relevant conclusion, that is,
one must be prepared to look in all the 3 listed attributes when using
the directoryName form of accessLocation.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 18 september 2005 17:53
> To: 'pkix'; 'Sam Hartman'
> Subject: RE: IESG last call changes to the CRL AIA draft
>
>
> This statement is incomplete and possibly misleading. Indirect CRL
issuer
> (when the ICRL Authority) is not a CA, its certificate will also have
> these
> characteristics.
>
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Denis Pinkas
> Sent: Sunday, September 18, 2005 10:32 AM
> To: David A. Cooper
> Cc: pkix; Sam Hartman
> Subject: Re: IESG last call changes to the CRL AIA draft
>
>
>
> David,
>
> Thank you for the explanations. The current text addition proposal is
> the following:
>
> "When different public keys are used to validate signatures on
> certificates and CRLs,
> the desired certificate is stored in the userCertificate attribute as
> specified in [RFC 2587]".
>
> Along the lines of your explanations, I would propose:
>
> "When the certificate pointed to by the AIA extension in the CRL is
only
> used to verify
> signatures on CRLs, but not signatures on certificates (i.e. different
> public keys are used
> to validate signatures on certificates and CRLs), the desired
> certificate is stored in the
> userCertificate attribute as specified in [RFC 2587]".
>
> Denis

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8J99X6N064661; Mon, 19 Sep 2005 02:09:33 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8J99XKB064660; Mon, 19 Sep 2005 02:09:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from b.mx.secunet.com (b.mx.secunet.com [213.68.205.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8J99WBR064504 for ; Mon, 19 Sep 2005 02:09:32 -0700 (PDT) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by b.mx.secunet.com (Postfix) with ESMTP id 87DF9719 for ; Mon, 19 Sep 2005 11:06:57 +0200 (CEST)
Received: from snsrv019.secumail.de (unknown [10.53.40.80]) by b.mx.secunet.com (Postfix) with ESMTP id 6F6302A for ; Mon, 19 Sep 2005 11:06:57 +0200 (CEST)
Received: from [10.208.1.212] ([10.208.1.212]) by snsrv019.secumail.de with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Sep 2005 11:10:18 +0200
Message-ID: <[email-masked]>
Date: Mon, 19 Sep 2005 11:09:26 +0200
From: Johannes Merkle
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [email-masked]
Subject: (no subject)
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Sep 2005 09:10:18.0046 (UTC) FILETIME=[F43D3DE0:01C5BCF9]
X-Virus-Scanned: by secunet
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

auth 50ce0ca598fcefb4aeeb56e7bc1532b1 subscribe ietf-pkix \
Johannes Merkle

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IG8GOF018309; Sun, 18 Sep 2005 09:08:16 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8IG8Gj3018308; Sun, 18 Sep 2005 09:08:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from carter-zimmerman.mit.edu (vsat-148-64-166-190.c005.g4.mrt.starband.net [148.64.166.190]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IG84mH018291 for ; Sun, 18 Sep 2005 09:08:13 -0700 (PDT) (envelope-from [email-masked])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 82D60E0049; Sun, 18 Sep 2005 12:07:41 -0400 (EDT)
To: Denis Pinkas
Cc: "David A. Cooper" , pkix
Subject: Re: IESG last call changes to the CRL AIA draft
References: <[email-masked]>
From: Sam Hartman
Date: Sun, 18 Sep 2005 12:07:41 -0400
In-Reply-To: <[email-masked]> (Denis Pinkas's message of "Sun, 18 Sep 2005 16:31:54 +0200")
Message-ID:
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

>>>>> "Denis" == Denis Pinkas writes:

Denis> David, Thank you for the explanations. The current text
Denis> addition proposal is the following: "When different public
Denis> keys are used to validate signatures on certificates and
Denis> CRLs, the desired certificate is stored in the
Denis> userCertificate attribute as specified in [RFC 2587]".
Denis> Along the lines of your explanations, I would propose:

Denis> attribute as specified in [RFC 2587]". Denis

Denis, the proposed text is no longer proposed. The document has been
approved and sent to the rfc editor.

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IFrBcQ017515; Sun, 18 Sep 2005 08:53:11 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8IFrB26017514; Sun, 18 Sep 2005 08:53:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IFrAnM017507 for ; Sun, 18 Sep 2005 08:53:10 -0700 (PDT) (envelope-from [email-masked])
Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j8IFr7vU017274; Sun, 18 Sep 2005 11:53:09 -0400
From: "Santosh Chokhani"
To: "'pkix'" , "'Sam Hartman'"
Subject: RE: IESG last call changes to the CRL AIA draft
Date: Sun, 18 Sep 2005 11:52:54 -0400
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This statement is incomplete and possibly misleading. Indirect CRL issuer
(when the ICRL Authority) is not a CA, its certificate will also have these
characteristics.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Sunday, September 18, 2005 10:32 AM
To: David A. Cooper
Cc: pkix; Sam Hartman
Subject: Re: IESG last call changes to the CRL AIA draft

David,

Thank you for the explanations. The current text addition proposal is
the following:

"When different public keys are used to validate signatures on
certificates and CRLs,
the desired certificate is stored in the userCertificate attribute as
specified in [RFC 2587]".

Along the lines of your explanations, I would propose:

"When the certificate pointed to by the AIA extension in the CRL is only
used to verify
signatures on CRLs, but not signatures on certificates (i.e. different
public keys are used
to validate signatures on certificates and CRLs), the desired
certificate is stored in the
userCertificate attribute as specified in [RFC 2587]".

Denis

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IEVHg6009566; Sun, 18 Sep 2005 07:31:17 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8IEVHaw009565; Sun, 18 Sep 2005 07:31:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IEVFM8009540 for ; Sun, 18 Sep 2005 07:31:16 -0700 (PDT) (envelope-from [email-masked])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA50166; Sun, 18 Sep 2005 16:48:00 +0200
Received: from bull.net ([129.181.81.102]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005091816343171:1914 ; Sun, 18 Sep 2005 16:34:31 +0200
Message-ID: <[email-masked]>
Date: Sun, 18 Sep 2005 16:31:54 +0200
From: Denis Pinkas
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper"
CC: pkix , Sam Hartman
Subject: Re: IESG last call changes to the CRL AIA draft
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/09/2005 16:34:32, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/09/2005 16:34:33, Serialize complete at 18/09/2005 16:34:33
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

David,

Thank you for the explanations. The current text addition proposal is
the following:

"When different public keys are used to validate signatures on
certificates and CRLs,
the desired certificate is stored in the userCertificate attribute as
specified in [RFC 2587]".

Along the lines of your explanations, I would propose:

"When the certificate pointed to by the AIA extension in the CRL is only
used to verify
signatures on CRLs, but not signatures on certificates (i.e. different
public keys are used
to validate signatures on certificates and CRLs), the desired
certificate is stored in the
userCertificate attribute as specified in [RFC 2587]".

Denis

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8G6HhQQ083546; Thu, 15 Sep 2005 23:17:43 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8G6HhXe083545; Thu, 15 Sep 2005 23:17:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mailrelay2.tu-graz.ac.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8G6HfUw083522 for ; Thu, 15 Sep 2005 23:17:42 -0700 (PDT) (envelope-from [email-masked])
Received: from thor.iaik.tugraz.at (thor.iaik.tugraz.at [129.27.152.13]) by mailrelay2.tu-graz.ac.at (8.13.4/8.13.4) with ESMTP id j8G6HZlQ010484; Fri, 16 Sep 2005 08:17:35 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 3C98D14C002; Fri, 16 Sep 2005 08:17:35 +0200 (CEST)
Received: from thor.iaik.tugraz.at ([127.0.0.1]) by localhost (thor [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25913-07; Fri, 16 Sep 2005 08:17:35 +0200 (CEST)
Received: from iaik.at (mailhost.iaik.tugraz.at [129.27.152.30]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 0484414C001; Fri, 16 Sep 2005 08:17:35 +0200 (CEST)
Received: from NOTEBOOKLIPP [129.27.152.246] by iaik.at with ESMTP (SMTPD32-7.07) id A37A1064005A; Fri, 16 Sep 2005 08:17:30 +0200
From: "Peter Lipp"
To: "'Tom Gindin'"
Cc:
Subject: AW: Loop in revocation checking
Date: Fri, 16 Sep 2005 08:17:30 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
In-Reply-To:
Thread-Index: AcW6c7wdexdjRUa/RPWVrHJNCkZAYQAElb9A
Message-Id: <20050916081744.SM02120@NOTEBOOKLIPP>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at iaik.tugraz.at
X-Scanned-By: MIMEDefang 2.52 on 129.27.10.19
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> Thus, what difference does it make what
> revocation mechanisms are referenced in the AIA or CRLDP
> extensions of such a certificate? They should never be executed.
None. I knew that this was irrelevant for the problem itself, but thought it
may illustrate the strangeness... :-)

Peter

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8G44RNY069211; Thu, 15 Sep 2005 21:04:27 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8G44RQb069210; Thu, 15 Sep 2005 21:04:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8G44Qn6069175 for ; Thu, 15 Sep 2005 21:04:26 -0700 (PDT) (envelope-from [email-masked])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8G449tM019981 for ; Fri, 16 Sep 2005 00:04:09 -0400
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8G44CTU097370 for ; Fri, 16 Sep 2005 00:04:12 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j8G441w9019104 for ; Fri, 16 Sep 2005 00:04:11 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j8G440nP019043; Fri, 16 Sep 2005 00:04:00 -0400
In-Reply-To: <200509150806248.SM02120@NOTEBOOKLIPP>
To: "Peter Lipp"
Cc: [email-masked]
MIME-Version: 1.0
Subject: Re: Loop in revocation checking
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin
Message-ID:
Date: Fri, 16 Sep 2005 00:03:58 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 09/16/2005 00:04:00, Serialize complete at 09/16/2005 00:04:00
Content-Type: text/plain; charset="US-ASCII"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Peter:

I don't understand the function of the last item in your problem
statement. What part of the validation algorithm checks the revocation
status of a self-signed certificate, which cannot be part of a chain
except as a trust anchor? Thus, what difference does it make what
revocation mechanisms are referenced in the AIA or CRLDP extensions of
such a certificate? They should never be executed.
I would not deny that out of band checks of the revocation status
of a trust anchor within a store of trust anchors might be useful, but
such checks are not part of the validation algorithm. In any case, a
trust anchor whose revocation can ever be checked should naturally be
represented by a cross certificate rather than a self-signed one, and the
corresponding trusted issuer name is the SUBJECT of that cross
certificate.
For Todd, I have a different question. If you have some use cases
(or paradigms, or workflows) to bring to the WG's attention in this area,
why don't you do so instead of objecting that standards are being drawn up
without them?

Tom Gindin

"Peter Lipp"
Sent by: [email-masked]
09/15/2005 02:06 AM

To:
cc:
Subject: Loop in revocation checking

Folks, Experts, Friends....

We are faced with a situation, where a certification service plans to use
the following scenario:

- A self-signed root CA, as usual.
- A CRL issuer, using the indirect CRL mechanism.
- An OCSP responder.
- The Certificate for the CRL issuer contains an AIA-extension pointing
to the OCSP-responder.
- The Certificate for the OCSP responder contains a
CRL-Distribution-Point pointing to the CRL issuer.
- The certificates for OCSP-Responder and CRL issuer both contain
an AIA extension pointing to the OCSP responder and the CRL
distribution point.
- The self signed certificate contains both an AIA-extension pointing
to the OCSP-responder and a CRL distribution point pointing to the CRL
issued by the CRL issuer.

If I now go and use standard validation algorithms, it hopefully will
detect
there is a loop and has to make a decision. (Basically this could also
happen if the OCSP-responder certificate points to the same responder or
in
other cases).

Now we observe, that

- we have never seen such a construction (and were not looking for one
so far)
- it seems as if none of the current standards mention, discourage or
even prohibit such a construction. Nor does any of them recommend it.

In our discussion we came to a deadlock, where everybody was convinced to
be
right - deadlock. We have decided to post this here to this distinguished
community...

Assuming that this service will serve a pontentially very large user base,
we have asked ourselves (and now you :-) the following questions:

- if any implementation detects the loop, what would the logical
decision to be taken be (assuming that we get "not revoked" responses):
- don't know, ask policy
- can't check revocation status - there is something
wrong, don't
accept certificate
- didn't see revocation, so certs must be ok
- if any of the two services has the others certificate revoked, we
have a case where we have a lier and a truthsayer and don't know
which is which - so we wouldn't accept the certificate, would we?
- if you have your own implementation, have you considered that case
and what would happen?
- any other opinion that you wish to offer (besides security issues
like what happens if the revocation service (OCSP and CRL) gets hacked)?

The argument of the service implementers is: "it is obvious how to
interpret
the situation - any decent implementation will detect the loop and
Consider
the status of the certificate as 'not revoked'" and since standards don't
prescribe different things, they may implement it that way (and clients
will
be flexible enough to adapt if not).

The idea behind the concept is that this way the root CA never has to
issue
a CRL while the service is operating and keeps administration effort low.

I am looking forward to your distinguished opinions ...

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FJuVc8029272; Thu, 15 Sep 2005 12:56:31 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8FJuVme029271; Thu, 15 Sep 2005 12:56:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mailrelay2.tu-graz.ac.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FJuTqa029255 for ; Thu, 15 Sep 2005 12:56:30 -0700 (PDT) (envelope-from [email-masked])
Received: from thor.iaik.tugraz.at (thor.iaik.tugraz.at [129.27.152.13]) by mailrelay2.tu-graz.ac.at (8.13.4/8.13.4) with ESMTP id j8FJuNpd024900; Thu, 15 Sep 2005 21:56:23 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 2B9FF14C002; Thu, 15 Sep 2005 21:56:24 +0200 (CEST)
Received: from thor.iaik.tugraz.at ([127.0.0.1]) by localhost (thor [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24099-02; Thu, 15 Sep 2005 21:56:24 +0200 (CEST)
Received: from iaik.at (mailhost.iaik.tugraz.at [129.27.152.30]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 010C414C001; Thu, 15 Sep 2005 21:56:24 +0200 (CEST)
Received: from NOTEBOOKLIPP [129.27.152.251] by iaik.at with ESMTP (SMTPD32-7.07) id A1E7FFD005A; Thu, 15 Sep 2005 21:56:23 +0200
From: "Peter Lipp"
To:
Cc: "'Piyush Jain'"
Subject: AW: Loop in revocation checking
Date: Thu, 15 Sep 2005 21:56:23 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcW5u6L4Tol85DANR2OK8bgfLThynwAZsySwAAND6EA=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
In-Reply-To: <[email-masked]>
Message-Id: <200509152156838.SM02120@NOTEBOOKLIPP>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at iaik.tugraz.at
X-Scanned-By: MIMEDefang 2.52 on 129.27.10.19
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> A few more questions on your trust model
No, it's not our, it's their trust model :-) I just wanted to make this
point.

> - You mentioned that you are using the indirect CRL mechanism. Is the
> CRL issuer also self signed and directly trusted by clients and OCSP
> responder?
No.

> If not, then how do you trust the indirect CRL signer?
It gets a certificate from the root.

> - Is the OCSP responder cert self signed or is it issued by
> the self signed CA?
The latter.

> This implies that the status of certificate could not be
> determined. So you must try to obtain the status using other
> means (possibly an alternative AIA), failing which the status
> must be treated as unknown.
I agree. But does this follow from some standard text or is this just common
knowledge that never has made it to a standard or ....

Peter

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FJHiMa026712; Thu, 15 Sep 2005 12:17:44 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8FJHi0q026711; Thu, 15 Sep 2005 12:17:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mms-dmz.tumbleweed.com (mms-dmz.tumbleweed.com [216.148.232.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FJHf5q026703 for ; Thu, 15 Sep 2005 12:17:42 -0700 (PDT) (envelope-from [email-masked])
Received: from 10.1.5.72 by mms-dmz.tumbleweed.com with ESMTP ( Tumbleweed MMS SMTP Relay (Email Firewall v6.1.1)); Thu, 15 Sep 2005 12:27:51 -0700
X-Server-Uuid: 6C567EC4-4768-4F66-893F-838D00B15500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Loop in revocation checking
Date: Thu, 15 Sep 2005 12:14:45 -0700
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Loop in revocation checking
Thread-Index: AcW5u6L4Tol85DANR2OK8bgfLThynwAZsySw
From: "Piyush Jain"
To: "Peter Lipp" , [email-masked]
X-WSS-ID: 6F3714BD2SK17876207-01-03
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8FJHg5q026706
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Peter,

A few more questions on your trust model
- You mentioned that you are using the indirect CRL mechanism. Is the CRL issuer also self signed and directly trusted by clients and OCSP responder?
If not, then how do you trust the indirect CRL signer?
- Is the OCSP responder cert self signed or is it issued by the self signed CA?

Now going back to your original questions :
Q1) if any implementation detects the loop, what would the logical decision to be taken be (assuming that we get "not revoked" responses):
A. An intelligent software will detect and break the loop. This implies that the status of certificate could not be determined. So you must try to obtain the status using other means (possibly an alternative AIA), failing which the status must be treated as unknown.

Q2) if any of the two services has the others certificate revoked, we have a case where we have a lier and a truthsayer and don't know which is which - so we wouldn't accept the certificate, would we?
A.) If you encounter a revoked status then the certificate must not be accepted. Efficient softwares will stop processing when they encounter a revoked status. So ther won't be any loop in this case.

Q3) if you have your own implementation, have you considered that case and what would happen?
A.) If you are running into this issue in a closed PKI then it would usually point to an incorrectly deployed validation infrastructure. You need to revisit how you estblish trust in your OCSP responders and CRLs.

Q4) any other opinion that you wish to offer (besides security issues like what happens if the revocation service (OCSP and CRL) gets hacked)?
A.) Its typical for CAs to issue short lived responder certificates with a nocheck extension. This implies that revocation status check is not required on OCSP responder's certificates.

Piyush
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Peter Lipp
Sent: Wednesday, September 14, 2005 11:07 PM
To: [email-masked]
Subject: Loop in revocation checking

Folks, Experts, Friends....

We are faced with a situation, where a certification service plans to use
the following scenario:

- A self-signed root CA, as usual.
- A CRL issuer, using the indirect CRL mechanism.
- An OCSP responder.
- The Certificate for the CRL issuer contains an AIA-extension pointing
to the OCSP-responder.
- The Certificate for the OCSP responder contains a
CRL-Distribution-Point pointing to the CRL issuer.
- The certificates for OCSP-Responder and CRL issuer both contain
an AIA extension pointing to the OCSP responder and the CRL
distribution point.
- The self signed certificate contains both an AIA-extension pointing
to the OCSP-responder and a CRL distribution point pointing to the CRL
issued by the CRL issuer.

If I now go and use standard validation algorithms, it hopefully will detect
there is a loop and has to make a decision. (Basically this could also
happen if the OCSP-responder certificate points to the same responder or in
other cases).

Now we observe, that

- we have never seen such a construction (and were not looking for one
so far)
- it seems as if none of the current standards mention, discourage or
even prohibit such a construction. Nor does any of them recommend it.

In our discussion we came to a deadlock, where everybody was convinced to be
right - deadlock. We have decided to post this here to this distinguished
community...

Assuming that this service will serve a pontentially very large user base,
we have asked ourselves (and now you :-) the following questions:

-
- don't know, ask policy
- can't check revocation status - there is something wrong, don't
accept certificate
- didn't see revocation, so certs must be ok
- if any of the two services has the others certificate revoked, we
have a case where we have a lier and a truthsayer and don't know
which is which - so we wouldn't accept the certificate, would we?
- if you have your own implementation, have you considered that case
and what would happen?
- any other opinion that you wish to offer (besides security issues
like what happens if the revocation service (OCSP and CRL) gets hacked)?

The argument of the service implementers is: "it is obvious how to interpret
the situation - any decent implementation will detect the loop and Consider
the status of the certificate as 'not revoked'" and since standards don't
prescribe different things, they may implement it that way (and clients will
be flexible enough to adapt if not).

The idea behind the concept is that this way the root CA never has to issue
a CRL while the service is operating and keeps administration effort low.

I am looking forward to your distinguished opinions ...

"Tumbleweed E-mail Firewall " made the following
annotations on 09/15/05 12:27:53
------------------------------------------------------------------------------
This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
==============================================================================

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FED55M094973; Thu, 15 Sep 2005 07:13:05 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8FED5nF094972; Thu, 15 Sep 2005 07:13:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FED3o9094955 for ; Thu, 15 Sep 2005 07:13:04 -0700 (PDT) (envelope-from [email-masked])
Received: from 204.127.135.43 ([204.127.135.43]) by worldnet.att.net (mtiwmhc13) with SMTP id <2005091514124711300n22dde>; Thu, 15 Sep 2005 14:12:58 +0000
Received: from [64.127.102.91] by 204.127.135.43; Thu, 15 Sep 2005 14:12:46 +0000
From: [email-masked]
To: "Peter Lipp" ,
Subject: Re: Loop in revocation checking
Date: Thu, 15 Sep 2005 14:12:46 +0000
Message-Id: <091520051412[email-masked]>
X-Mailer: AT&T Message Center Version 1 (Feb 14 2005)
X-Authenticated-Sender: dG9kZC5nbGFzc2V5QGF0dC5uZXQ=
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Peter - this question of yours documents WHY "user use paradigm's" and workflow's are needed for ANYTHING this organization wants to proffer. Especially if its to be accepted under the SOX reporting requirements.

Todd Glassey
-------------- Original message ----------------------
From: "Peter Lipp"
>
> Folks, Experts, Friends....
>
> We are faced with a situation, where a certification service plans to use
> the following scenario:
>
> - A self-signed root CA, as usual.
> - A CRL issuer, using the indirect CRL mechanism.
> - An OCSP responder.
> - The Certificate for the CRL issuer contains an AIA-extension pointing
> to the OCSP-responder.
> - The Certificate for the OCSP responder contains a
> CRL-Distribution-Point pointing to the CRL issuer.
> - The certificates for OCSP-Responder and CRL issuer both contain
> an AIA extension pointing to the OCSP responder and the CRL
> distribution point.
> - The self signed certificate contains both an AIA-extension pointing
> to the OCSP-responder and a CRL distribution point pointing to the CRL
> issued by the CRL issuer.
>
> If I now go and use standard validation algorithms, it hopefully will detect
> there is a loop and has to make a decision. (Basically this could also
> happen if the OCSP-responder certificate points to the same responder or in
> other cases).
>
> Now we observe, that
>
> - we have never seen such a construction (and were not looking for one
> so far)
> - it seems as if none of the current standards mention, discourage or
> even prohibit such a construction. Nor does any of them recommend it.
>
> In our discussion we came to a deadlock, where everybody was convinced to be
> right - deadlock. We have decided to post this here to this distinguished
> community...
>
> Assuming that this service will serve a pontentially very large user base,
> we have asked ourselves (and now you :-) the following questions:
>
> - if any implementation detects the loop, what would the logical
> decision to be taken be (assuming that we get "not revoked" responses):
> - don't know, ask policy
> - can't check revocation status - there is something wrong, don't
> accept certificate
> - didn't see revocation, so certs must be ok
> - if any of the two services has the others certificate revoked, we
> have a case where we have a lier and a truthsayer and don't know
> which is which - so we wouldn't accept the certificate, would we?
> - if you have your own implementation, have you considered that case
> and what would happen?
> - any other opinion that you wish to offer (besides security issues
> like what happens if the revocation service (OCSP and CRL) gets hacked)?
>
> The argument of the service implementers is: "it is obvious how to interpret
> the situation - any decent implementation will detect the loop and Consider
> the status of the certificate as 'not revoked'" and since standards don't
> prescribe different things, they may implement it that way (and clients will
> be flexible enough to adapt if not).
>
> The idea behind the concept is that this way the root CA never has to issue
> a CRL while the service is operating and keeps administration effort low.
>
> I am looking forward to your distinguished opinions ...
>
>

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FCEemg083994; Thu, 15 Sep 2005 05:14:40 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8FCEeuc083993; Thu, 15 Sep 2005 05:14:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FCEcoI083979 for ; Thu, 15 Sep 2005 05:14:39 -0700 (PDT) (envelope-from [email-masked])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8FCEUWJ006755 for ; Thu, 15 Sep 2005 08:14:30 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8FCEUlR102194 for ; Thu, 15 Sep 2005 08:14:30 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j8FCEUYW002171 for ; Thu, 15 Sep 2005 08:14:30 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j8FCEUZe002166; Thu, 15 Sep 2005 08:14:30 -0400
In-Reply-To: <[email-masked]>
To: "David A. Cooper"
Cc: Denis Pinkas , Sam Hartman , pkix , [email-masked]
MIME-Version: 1.0
Subject: Re: IESG last call changes to the CRL AIA draft
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin
Message-ID:
Date: Thu, 15 Sep 2005 08:14:23 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 09/15/2005 08:14:29, Serialize complete at 09/15/2005 08:14:29
Content-Type: text/plain; charset="US-ASCII"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

David:

RFC 3280 section 4.2.1.10 says that CRL Signing certificates MAY
contain basicConstraints. There is some tension between X.509 and RFC
3280 on this point. Of course, any CRL Signing certificate which doesn't
contain basicConstraints does belong in userCertificate.

Tom Gindin

"David A. Cooper"
Sent by: [email-masked]
09/12/2005 05:21 PM

To: Denis Pinkas
cc: pkix , Sam Hartman

Subject: Re: IESG last call changes to the CRL AIA draft

Denis Pinkas wrote:

> Maybe I missed something, but the question is: in which case the
> certificate located through
> this extension, used to validate signatures on CRLs may not be a CA
> certificate ?

Denis,

According to X.509, in order for a certificate to be stored in the
cACertificate or crossCertificatePair attribute, the certificate "shall
include a basicConstraints extension with the cA value set to TRUE."
The cA value of the basicConstraints extension "indicates if the
certified public key may be used to verify certificate signatures." So,
if subject public key in the certificate pointed to by the AIA extension
in the CRL is used to verify signatures on CRLs but not signatures on
certificates, then the certificate would not include a basicConstraints
extension with the cA value set to TRUE and so the certificate could not
be stored in the cACertificate or crossCertificatePair attribute. The
only other attribute that is defined for holding public key certificates
is the userCertificate attribute.

Dave

>> During IESG last call on the CRL AIA draft, David Cooper submitted some
>> editorial comments which has been corrected and included in a new draft
>> 03, submitted today.
>>
>> The changes are:
>>
>> 1) Clarification that a certificate located through this extension,
used
>> to validate signatures on CRLs may not be a CA certificate and thus may
>> be found in the userCertificate attribute. The old text in section 2
>> was:
>>
>> When the accessLocation is a directoryName, the information is to
>> be obtained by the application from whatever directory server is
>> locally configured. The entry for the directoryName contains CA
>> certificates in the crossCertificatePair and/or cACertificate
>> attributes as specified in [RFC 2587]. The protocol that
>> application uses to access the directory (e.g., DAP or LDAP) is a
>> local matter.
>>
>> The new text reads:
>>
>> When the accessLocation is a directoryName, the information is to
>> be obtained by the application from whatever directory server is
>> locally configured. When one CA public key is used to validate
>> signatures on certificates and CRLs, the desired CA certificate is
>> stored in the crossCertificatePair and/or cACertificate attributes
>> as specified in [RFC 2587]. When different public keys are used to
>> validate signatures on certificates and CRLs, the desired
>> certificate is stored in the userCertificate attribute as specified
>> in [RFC 2587]. Thus, implementations that support the directoryName
>> form of accessLocation MUST be prepared to find the needed
>> certificate in any of these three attributes. The protocol that an
>> application uses to access the directory (e.g., DAP or LDAP) is a
>> local matter.
>>
>> 2) Removing the DER encoded requirement for CMS messages and instead
use
>> reliance on RFC 2797 to specify necessary coding conventions.
>>
>> 3) Aligning the ldap examples so that all now includes the ";binary"
>> option.
>>
>> The changes have been concluded and edited in cooperation with Russ,
>> Sam, Steve and Tim.
>>
>>
>> Stefan Santesson
>> Program Manager, Standards Liaison
>> Windows Security
>>
>>
>>
>>
>>
>
>
>
>

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8F66qqe000145; Wed, 14 Sep 2005 23:06:52 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8F66quq000144; Wed, 14 Sep 2005 23:06:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mailrelay2.tu-graz.ac.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8F66pAF000138 for ; Wed, 14 Sep 2005 23:06:51 -0700 (PDT) (envelope-from [email-masked])
Received: from thor.iaik.tugraz.at (thor.iaik.tugraz.at [129.27.152.13]) by mailrelay2.tu-graz.ac.at (8.13.4/8.13.4) with ESMTP id j8F66iBi017264 for ; Thu, 15 Sep 2005 08:06:44 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 4FA8318CF99 for ; Thu, 15 Sep 2005 08:06:45 +0200 (CEST)
Received: from thor.iaik.tugraz.at ([127.0.0.1]) by localhost (thor [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11191-07 for ; Thu, 15 Sep 2005 08:06:45 +0200 (CEST)
Received: from iaik.at (mailhost.iaik.tugraz.at [129.27.152.30]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 2059418CF8D for ; Thu, 15 Sep 2005 08:06:45 +0200 (CEST)
Received: from NOTEBOOKLIPP [129.27.152.250] by iaik.at with ESMTP (SMTPD32-7.07) id AF6F4BB0056; Thu, 15 Sep 2005 08:06:39 +0200
From: "Peter Lipp"
To:
Subject: Loop in revocation checking
Date: Thu, 15 Sep 2005 08:06:39 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
Thread-Index: AcW5u6L4Tol85DANR2OK8bgfLThynw==
Message-Id: <200509150806248.SM02120@NOTEBOOKLIPP>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at iaik.tugraz.at
X-Scanned-By: MIMEDefang 2.52 on 129.27.10.19
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Folks, Experts, Friends....

We are faced with a situation, where a certification service plans to use
the following scenario:

- A self-signed root CA, as usual.
- A CRL issuer, using the indirect CRL mechanism.
- An OCSP responder.
- The Certificate for the CRL issuer contains an AIA-extension pointing
to the OCSP-responder.
- The Certificate for the OCSP responder contains a
CRL-Distribution-Point pointing to the CRL issuer.
- The certificates for OCSP-Responder and CRL issuer both contain
an AIA extension pointing to the OCSP responder and the CRL
distribution point.
- The self signed certificate contains both an AIA-extension pointing
to the OCSP-responder and a CRL distribution point pointing to the CRL
issued by the CRL issuer.

If I now go and use standard validation algorithms, it hopefully will detect
there is a loop and has to make a decision. (Basically this could also
happen if the OCSP-responder certificate points to the same responder or in
other cases).

Now we observe, that

- we have never seen such a construction (and were not looking for one
so far)
- it seems as if none of the current standards mention, discourage or
even prohibit such a construction. Nor does any of them recommend it.

In our discussion we came to a deadlock, where everybody was convinced to be
right - deadlock. We have decided to post this here to this distinguished
community...

Assuming that this service will serve a pontentially very large user base,
we have asked ourselves (and now you :-) the following questions:

- if any implementation detects the loop, what would the logical
decision to be taken be (assuming that we get "not revoked" responses):
- don't know, ask policy
- can't check revocation status - there is something wrong, don't
accept certificate
- didn't see revocation, so certs must be ok
- if any of the two services has the others certificate revoked, we
have a case where we have a lier and a truthsayer and don't know
which is which - so we wouldn't accept the certificate, would we?
- if you have your own implementation, have you considered that case
and what would happen?
- any other opinion that you wish to offer (besides security issues
like what happens if the revocation service (OCSP and CRL) gets hacked)?

The argument of the service implementers is: "it is obvious how to interpret
the situation - any decent implementation will detect the loop and Consider
the status of the certificate as 'not revoked'" and since standards don't
prescribe different things, they may implement it that way (and clients will
be flexible enough to adapt if not).

The idea behind the concept is that this way the root CA never has to issue
a CRL while the service is operating and keeps administration effort low.

I am looking forward to your distinguished opinions ...

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8F5nhb5098530; Wed, 14 Sep 2005 22:49:43 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8F5nhGm098529; Wed, 14 Sep 2005 22:49:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mailrelay2.tu-graz.ac.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8F5nfJW098514 for ; Wed, 14 Sep 2005 22:49:42 -0700 (PDT) (envelope-from [email-masked])
Received: from thor.iaik.tugraz.at (thor.iaik.tugraz.at [129.27.152.13]) by mailrelay2.tu-graz.ac.at (8.13.4/8.13.4) with ESMTP id j8F5nYX1016662 for ; Thu, 15 Sep 2005 07:49:34 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 167A214C002 for ; Thu, 15 Sep 2005 07:49:35 +0200 (CEST)
Received: from thor.iaik.tugraz.at ([127.0.0.1]) by localhost (thor [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10964-10 for ; Thu, 15 Sep 2005 07:49:34 +0200 (CEST)
Received: from iaik.at (mailhost.iaik.tugraz.at [129.27.152.30]) by thor.iaik.tugraz.at (Postfix) with ESMTP id D746614C001 for ; Thu, 15 Sep 2005 07:49:34 +0200 (CEST)
Received: from NOTEBOOKLIPP [129.27.152.250] by iaik.at with ESMTP (SMTPD32-7.07) id AB6E4900056; Thu, 15 Sep 2005 07:49:34 +0200
From: "Peter Lipp"
To:
Subject: Loop in revocation checking
Date: Thu, 15 Sep 2005 07:49:34 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
thread-index: AcW5uT+oAk+GUP/oTZu/hsvL9Cjo4Q==
Message-Id: <200509150749423.SM02120@NOTEBOOKLIPP>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at iaik.tugraz.at
X-Scanned-By: MIMEDefang 2.52 on 129.27.10.19
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Folks, Experts, Friends....

We are faced with a situation, where a certification service plans to use
the following scenario:

- A self-signed root CA, as usual.
- A CRL issuer, using the indirect CRL mechanism.
- An OCSP responder.
- The Certificate for the CRL issuer contains an AIA-extension pointing
to the OCSP-responder.
- The Certificate for the OCSP responder contains a
CRL-Distribution-Point pointing to the CRL issuer.
- The certificates for OCSP-Responder and CRL issuer both contain
an AIA extension pointing to the OCSP responder and the CRL
distribution point.
- The self signed certificate contains both an AIA-extension pointing
to the OCSP-responder and a CRL distribution point pointing to the CRL
issued by the CRL issuer.

If I now go and use standard validation algorithms, it hopefully will detect
there is a loop and has to make a decision. (Basically this could also
happen if the OCSP-responder certificate points to the same responder or in
other cases).

Now we observe, that

- we have never seen such a construction (and were not looking for one
so far)
- it seems as if none of the current standards mention, discourage or
even prohibit such a construction. Nor does any of them recommend it.

In our discussion we came to a deadlock, where everybody was convinced to be
right - deadlock. We have decided to post this here to this distinguished
community...

Assuming that this service will serve a pontentially very large user base,
we have asked ourselves (and now you :-) the following questions:

- if any implementation detects the loop, what would the logical
decision to be taken be (assuming that we get "not revoked" responses):
- don't know, ask policy
- can't check revocation status - there is something wrong, don't
accept certificate
- didn't see revocation, so certs must be ok
- if any of the two services has the others certificate revoked, we
have a case where we have a lier and a truthsayer and don't know
which is which - so we wouldn't accept the certificate, would we?
- if you have your own implementation, have you considered that case
and what would happen?
- any other opinion that you wish to offer (besides security issues
like what happens if the revocation service (OCSP and CRL) gets hacked)?

The argument of the service implementers is: "it is obvious how to interpret
the situation - any decent implementation will detect the loop and Consider
the status of the certificate as 'not revoked'" and since standards don't
prescribe different things, they may implement it that way (and clients will
be flexible enough to adapt if not).

The idea behind the concept is that this way the root CA never has to issue
a CRL while the service is operating and keeps administration effort low.

I am looking forward to your distinguished opinions ...

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8DBu5IP097335; Tue, 13 Sep 2005 04:56:05 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8DBu5mp097334; Tue, 13 Sep 2005 04:56:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.um.es (smtp.um.es [155.54.212.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8DBu11l097326 for ; Tue, 13 Sep 2005 04:56:04 -0700 (PDT) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 479671FA25F for ; Tue, 13 Sep 2005 13:55:55 +0200 (CEST)
Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31089-01-45 for ; Tue, 13 Sep 2005 13:55:55 +0200 (CEST)
Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by mail.um.es (Postfix) with SMTP id 1947B1FA248 for ; Tue, 13 Sep 2005 13:55:54 +0200 (CEST)
Received: (qmail 4716 invoked from network); 13 Sep 2005 12:02:31 -0000
Received: from ycaro.dif.um.es (HELO ycaro) (155.54.210.68) by aries.dif.um.es with SMTP; 13 Sep 2005 12:02:31 -0000
Message-ID: <[email-masked]>
From: "Manuel Gil Perez"
To:
Subject: CMC question
Date: Tue, 13 Sep 2005 13:55:32 +0200
Organization: ANTS Research Group
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Dear PKIX members,

When an user needs to retrieve the certificate of another person, i.e. for
encrypting data, the user can do a GetCert request (*) to retrieve it. The
problem is due to that this protocol needs the serial number of the
certificate, but it is possible that in any moment the user only can arrange
the e-mail address or an UID associated with this person.

Is there any way to look for certificates from e-mail addresses, UID, etc.??

Best regards,

(*) http://www.ietf.org/rfc/rfc2797.txt (section "5.9. Get Certificate
Control Attribute")

------
Manuel Gil Pérez
http://pki.umu.euro6ix.org

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8D02JPf031523; Mon, 12 Sep 2005 17:02:19 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8D02JjW031522; Mon, 12 Sep 2005 17:02:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from SMTP.Lamicro.com (66-163-8-251.ip.tor.radiant.net [66.163.8.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8D02Hw7031511 for ; Mon, 12 Sep 2005 17:02:19 -0700 (PDT) (envelope-from [email-masked])
Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO00E33F; 12 Sep 2005 20:06:04 -0400
Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 12 Sep 2005 20:05:48 -0400
Received: from connotech.com (209.71.204.116) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG00E33E; 12 Sep 2005 20:05:46 -0400
Message-ID: <[email-masked]>
Date: Mon, 12 Sep 2005 20:34:15 -0400
From: Thierry Moreau
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Kent
CC: [email-masked]
Subject: Re: A non-critical self-signed certificate extension for trust anchr renewal ...
References: <[email-masked]>
In-Reply-To:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Some time ago, Stephen Kent wrote:

> Thierry,
>
> A few of comments on your I-D:
>
> [...]
>

The revision -01 is now available at
http://www.ietf.org/internet-drafts/draft-moreau-pkix-takrem-01.txt.

Again, thank for your feedback.

--

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada H2M 2A1

Tel.: (514)385-5691
Fax: (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8CLxrTs021911; Mon, 12 Sep 2005 14:59:53 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8CLxrfW021910; Mon, 12 Sep 2005 14:59:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8CLxq7t021878 for ; Mon, 12 Sep 2005 14:59:52 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Sep 2005 22:59:46 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: IESG last call changes to the CRL AIA draft
Date: Mon, 12 Sep 2005 22:59:46 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: IESG last call changes to the CRL AIA draft
Thread-Index: AcW326j1ItVejoERQSqZcH8gCgSfFwACVpjg
From: "Stefan Santesson"
To: "Denis Pinkas" ,
Cc: "PKIX" , "Sam Hartman"
X-OriginalArrivalTime: 12 Sep 2005 21:59:46.0235 (UTC) FILETIME=[49BB90B0:01C5B7E5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8CLxr7t021900
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

When the CRL is signed by a CRL issuer that does not use the same
private signing key to sign certificates.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 12 september 2005 13:03
> To: [email-masked]
> Cc: PKIX; Sam Hartman
> Subject: Re: IESG last call changes to the CRL AIA draft
>
>
>
> Maybe I missed something, but the question is: in which case the
> certificate located through
> this extension, used to validate signatures on CRLs may not be a CA
> certificate ?
>
> Denis
>
>
> >During IESG last call on the CRL AIA draft, David Cooper submitted
some
> >editorial comments which has been corrected and included in a new
draft
> >03, submitted today.
> >
> >The changes are:
> >
> >1) Clarification that a certificate located through this extension,
used
> >to validate signatures on CRLs may not be a CA certificate and thus
may
> >be found in the userCertificate attribute. The old text in section 2
> >was:
> >
> > When the accessLocation is a directoryName, the information is
to
> > be obtained by the application from whatever directory server is
> > locally configured. The entry for the directoryName contains CA
> > certificates in the crossCertificatePair and/or cACertificate
> > attributes as specified in [RFC 2587]. The protocol that
> > application uses to access the directory (e.g., DAP or LDAP) is
a
> > local matter.
> >
> >The new text reads:
> >
> > When the accessLocation is a directoryName, the information is
to
> > be obtained by the application from whatever directory server is
> > locally configured. When one CA public key is used to validate
> > signatures on certificates and CRLs, the desired CA certificate
is
> > stored in the crossCertificatePair and/or cACertificate
attributes
> > as specified in [RFC 2587]. When different public keys are used
to
> > validate signatures on certificates and CRLs, the desired
> > certificate is stored in the userCertificate attribute as
specified
> > in [RFC 2587]. Thus, implementations that support the
directoryName
> > form of accessLocation MUST be prepared to find the needed
> > certificate in any of these three attributes. The protocol that
an
> > application uses to access the directory (e.g., DAP or LDAP) is
a
> > local matter.
> >
> >2) Removing the DER encoded requirement for CMS messages and instead
use
> >reliance on RFC 2797 to specify necessary coding conventions.
> >
> >3) Aligning the ldap examples so that all now includes the ";binary"
> >option.
> >
> >The changes have been concluded and edited in cooperation with Russ,
> >Sam, Steve and Tim.
> >
> >
> >Stefan Santesson
> >Program Manager, Standards Liaison
> >Windows Security
> >
> >
> >
> >
> >
>

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8CLLeT0018895; Mon, 12 Sep 2005 14:21:40 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8CLLeFh018894; Mon, 12 Sep 2005 14:21:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8CLLeVA018887 for ; Mon, 12 Sep 2005 14:21:40 -0700 (PDT) (envelope-from [email-masked])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j8CLLZlt018384; Mon, 12 Sep 2005 17:21:36 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j8CLKpYt015192; Mon, 12 Sep 2005 17:20:51 -0400 (EDT)
Message-ID: <[email-masked]>
Date: Mon, 12 Sep 2005 17:21:35 -0400
From: "David A. Cooper"
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050416
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas
CC: pkix , Sam Hartman
Subject: Re: IESG last call changes to the CRL AIA draft
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Denis Pinkas wrote:

> Maybe I missed something, but the question is: in which case the
> certificate located through
> this extension, used to validate signatures on CRLs may not be a CA
> certificate ?

Denis,

According to X.509, in order for a certificate to be stored in the
cACertificate or crossCertificatePair attribute, the certificate "shall
include a basicConstraints extension with the cA value set to TRUE."
The cA value of the basicConstraints extension "indicates if the
certified public key may be used to verify certificate signatures." So,
if subject public key in the certificate pointed to by the AIA extension
in the CRL is used to verify signatures on CRLs but not signatures on
certificates, then the certificate would not include a basicConstraints
extension with the cA value set to TRUE and so the certificate could not
be stored in the cACertificate or crossCertificatePair attribute. The
only other attribute that is defined for holding public key certificates
is the userCertificate attribute.

Dave

>> During IESG last call on the CRL AIA draft, David Cooper submitted some
>> editorial comments which has been corrected and included in a new draft
>> 03, submitted today.
>>
>> The changes are:
>>
>> 1) Clarification that a certificate located through this extension, used
>> to validate signatures on CRLs may not be a CA certificate and thus may
>> be found in the userCertificate attribute. The old text in section 2
>> was:
>>
>> When the accessLocation is a directoryName, the information is to
>> be obtained by the application from whatever directory server is
>> locally configured. The entry for the directoryName contains CA
>> certificates in the crossCertificatePair and/or cACertificate
>> attributes as specified in [RFC 2587]. The protocol that
>> application uses to access the directory (e.g., DAP or LDAP) is a
>> local matter.
>>
>> The new text reads:
>>
>> When the accessLocation is a directoryName, the information is to
>> be obtained by the application from whatever directory server is
>> locally configured. When one CA public key is used to validate
>> signatures on certificates and CRLs, the desired CA certificate is
>> stored in the crossCertificatePair and/or cACertificate attributes
>> as specified in [RFC 2587]. When different public keys are used to
>> validate signatures on certificates and CRLs, the desired
>> certificate is stored in the userCertificate attribute as specified
>> in [RFC 2587]. Thus, implementations that support the directoryName
>> form of accessLocation MUST be prepared to find the needed
>> certificate in any of these three attributes. The protocol that an
>> application uses to access the directory (e.g., DAP or LDAP) is a
>> local matter.
>>
>> 2) Removing the DER encoded requirement for CMS messages and instead use
>> reliance on RFC 2797 to specify necessary coding conventions.
>>
>> 3) Aligning the ldap examples so that all now includes the ";binary"
>> option.
>>
>> The changes have been concluded and edited in cooperation with Russ,
>> Sam, Steve and Tim.
>>
>>
>> Stefan Santesson
>> Program Manager, Standards Liaison
>> Windows Security
>>
>>
>>
>>
>>
>
>
>
>

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8CK2beQ010542; Mon, 12 Sep 2005 13:02:37 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8CK2agj010541; Mon, 12 Sep 2005 13:02:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8CK2ZLq010513; Mon, 12 Sep 2005 13:02:35 -0700 (PDT) (envelope-from [email-masked])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id WAA32326; Mon, 12 Sep 2005 22:19:17 +0200
Received: from bull.net ([129.181.81.107]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005091222053943:3620 ; Mon, 12 Sep 2005 22:05:39 +0200
Message-ID: <[email-masked]>
Date: Mon, 12 Sep 2005 22:02:59 +0200
From: Denis Pinkas
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [email-masked]
CC: PKIX , Sam Hartman
Subject: Re: IESG last call changes to the CRL AIA draft
References:
In-Reply-To:
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/09/2005 22:05:40, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/09/2005 22:05:41, Serialize complete at 12/09/2005 22:05:41
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Maybe I missed something, but the question is: in which case the
certificate located through
this extension, used to validate signatures on CRLs may not be a CA
certificate ?

Denis

>During IESG last call on the CRL AIA draft, David Cooper submitted some
>editorial comments which has been corrected and included in a new draft
>03, submitted today.
>
>The changes are:
>
>1) Clarification that a certificate located through this extension, used
>to validate signatures on CRLs may not be a CA certificate and thus may
>be found in the userCertificate attribute. The old text in section 2
>was:
>
> When the accessLocation is a directoryName, the information is to
> be obtained by the application from whatever directory server is
> locally configured. The entry for the directoryName contains CA
> certificates in the crossCertificatePair and/or cACertificate
> attributes as specified in [RFC 2587]. The protocol that
> application uses to access the directory (e.g., DAP or LDAP) is a
> local matter.
>
>The new text reads:
>
> When the accessLocation is a directoryName, the information is to
> be obtained by the application from whatever directory server is
> locally configured. When one CA public key is used to validate
> signatures on certificates and CRLs, the desired CA certificate is
> stored in the crossCertificatePair and/or cACertificate attributes
> as specified in [RFC 2587]. When different public keys are used to
> validate signatures on certificates and CRLs, the desired
> certificate is stored in the userCertificate attribute as specified
> in [RFC 2587]. Thus, implementations that support the directoryName
> form of accessLocation MUST be prepared to find the needed
> certificate in any of these three attributes. The protocol that an
> application uses to access the directory (e.g., DAP or LDAP) is a
> local matter.
>
>2) Removing the DER encoded requirement for CMS messages and instead use
>reliance on RFC 2797 to specify necessary coding conventions.
>
>3) Aligning the ldap examples so that all now includes the ";binary"
>option.
>
>The changes have been concluded and edited in cooperation with Russ,
>Sam, Steve and Tim.
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
>
>
>
>
>

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8CJo3Y2009487; Mon, 12 Sep 2005 12:50:03 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8CJo3N0009483; Mon, 12 Sep 2005 12:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8CJo32w009463 for ; Mon, 12 Sep 2005 12:50:03 -0700 (PDT) (envelope-from [email-masked])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EEuJW-0004E8-S8; Mon, 12 Sep 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-pkixrep-04.txt
Message-Id:
Date: Mon, 12 Sep 2005 15:50:02 -0400
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

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

Title : Internet X.509 Public Key Infrastructure Repository Locator Service
Author(s) : S. Boeyen, P. Hallam-Baker
Filename : draft-ietf-pkix-pkixrep-04.txt
Pages : 5
Date : 2005-9-12

This document defines a PKI repository locator service. The service
makes use of DNS SRV records defined in accordance with RFC 2782. The
service enables certificate using systems to locate PKI repositories

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-pkixrep-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-pkixrep-04.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pkixrep-04.txt

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

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

--OtherAccess--

--NextPart--

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j89JoFIf025380; Fri, 9 Sep 2005 12:50:15 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j89JoFwZ025379; Fri, 9 Sep 2005 12:50:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j89JoE5F025371 for ; Fri, 9 Sep 2005 12:50:14 -0700 (PDT) (envelope-from [email-masked])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EDosy-0008Ds-Br; Fri, 09 Sep 2005 15:50:08 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-gost-cppk-03.txt
Message-Id:
Date: Fri, 09 Sep 2005 15:50:08 -0400
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 : Using the GOST R 34.10-94, GOST R 34.10-2001
and GOST R 34.11-94 algorithms with the
Internet X.509 Public Key Infrastructure
Certificate and CRL Profile.
Author(s) : S. Leontiev, D. Shefanovski
Filename : draft-ietf-pkix-gost-cppk-03.txt
Pages : 18
Date : 2005-9-9

This document supplements RFC 3279. It describes encoding formats,
identifiers and parameter formats for the algorithms GOST R 34.10-94,
GOST R 34.10-2001 and GOST R 34.11-94 for use in Internet X.509
Public Key Infrastructure (PKI).

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-gost-cppk-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-gost-cppk-03.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-gost-cppk-03.txt

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

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

--OtherAccess--

--NextPart--

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j86L1iZl074135; Tue, 6 Sep 2005 14:01:44 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j86L1i8X074134; Tue, 6 Sep 2005 14:01:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j86L1hO2074128 for ; Tue, 6 Sep 2005 14:01:43 -0700 (PDT) (envelope-from [email-masked])
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1ECkZb-0008LJ-6N; Tue, 06 Sep 2005 17:01:43 -0400
X-test-idtracker: no
From: The IESG
To: IETF-Announce
Cc: Internet Architecture Board , RFC Editor , pkix mailing list , pkix chair , pkix chair
Subject: Protocol Action: 'Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)' to Proposed Standard
Message-Id:
Date: Tue, 06 Sep 2005 17:01:43 -0400
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

The IESG has approved the following document:

- 'Certificate Extensions and Attributes Supporting Authentication in
Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) '
as a Proposed Standard

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

The IESG contact persons are Sam Hartman and Russ Housley.

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

Technical Summary

This document defines mechanisms supporting Extensible Authentication
Protocol (EAP) authentication methods that employ X.509
public key certificates. This document defines two EAP extended key usage
values and a public key certificate extension to carry Wireless LAN (WLAN
System Service identifiers (SSIDs), and describes how these mechanisms may
be applied to support authentication in Point-to-Point Protocol (PPP) and
Wireless Local Area Networks (WLAN).

Working Group Summary

The working group had consensus to advance the draft to Proposed
Standard.

Protocol Quality

This document obseletes and replaces RFC 3770. It has been reviewed
by the PKIX working group. It has been reviewed for the IESG by Sam
Hartman.

Note to RFC Editor

Section 1.1:

old: Three changes are included
new: Five significant changes are included:

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j86KAafA068253; Tue, 6 Sep 2005 13:10:36 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j86KAaSU068252; Tue, 6 Sep 2005 13:10:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j86KAVBX068246 for ; Tue, 6 Sep 2005 13:10:35 -0700 (PDT) (envelope-from [email-masked])
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1ECjlz-0007kI-Hk; Tue, 06 Sep 2005 16:10:27 -0400
X-test-idtracker: no
From: The IESG
To: IETF-Announce
Cc: Internet Architecture Board , RFC Editor , pkix mailing list , pkix chair , pkix chair
Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure Authority Information Access CRL Extension' to Proposed Standard
Message-Id:
Date: Tue, 06 Sep 2005 16:10:27 -0400
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Authority Information Access CRL
Extension '
as a Proposed Standard

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

The IESG contact persons are Sam Hartman and Russ Housley.

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

Technical Summary

This document updates RFC 3280 by defining the Authority Information
Access Certificate Revocation Lists (CRL) extension. RFC 3280 [PKIX1]
provides for bottom-up discovery of certification paths through the
Authority Information Access extension. This document defines the use
of the Authority Information Access extension in CRLs, enabling a CRL
checking application to to locate certificates that may be useful in
the construction of a valid CRL issuer certification path to an
appropriate trust anchor.

Working Group Summary

The working group had consensus to advance the draft to proposed standard.

Protocol Quality

This document has been reviewed by members of the [email-masked]
mailing list, the RFC 3280bis design team, and by the working groupc
chairs. This document was reviewed for the IESG by Sam Hartman.

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81FpHTg048182; Thu, 1 Sep 2005 08:51:17 -0700 (PDT) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j81FpHtG048181; Thu, 1 Sep 2005 08:51:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81FpFiv048170 for ; Thu, 1 Sep 2005 08:51:16 -0700 (PDT) (envelope-from [email-masked])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Sep 2005 16:51:09 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Where to store SRV based names
Date: Thu, 1 Sep 2005 16:51:12 +0100
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Where to store SRV based names
Thread-Index: AcWnbXON1HuJUnrVR2CTqobM+i7BMwHny3bQ
From: "Stefan Santesson"
To:
Cc: , "Russ Housley"
X-OriginalArrivalTime: 01 Sep 2005 15:51:09.0799 (UTC) FILETIME=[F8C3FF70:01C5AF0C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j81FpGiv048175
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Steve,

Do you have any comments on this issue whether a SRV RR query string
ever will need more than IA5String to be expressed or if we should use
UTF-8 to be on the safe side?

If you are uncertain, could you check with the DNS Directorate for
guidance?

Thanks

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 22 augusti 2005 15:58
> To: Stefan Santesson
> Cc: [email-masked]; [email-masked]
> Subject: RE: Where to store SRV based names
>
> I went to the DNS tutorial at IETF63. One of the points that was made
was
> that the DNS itself did not limit the character set. It stores an
octet
> string.
>
> I suggest that we ask the DNS Directorate for advice. Perhaps you can
> work
> with Steve Bellovin, who is a member of the DNS Directorate to carry
the
> question forward. I suspect you will have to help him formulate a
concise
> question.
>
> Russ
>
> At 10:55 AM 8/22/2005, Stefan Santesson wrote:
>
> >Originally I suggested IA5String but many voices suggested UTF-8, so
> >that is what will go into next draft unless someone has a reason to
> >suggest otherwise.
> >
> >
> >Stefan Santesson
> >Program Manager, Standards Liaison
> >Windows Security
> >
> > > -----Original Message-----
> > > From: [email-masked]
> >[mailto:[email-masked]]
> > > On Behalf Of David Chadwick
> > > Sent: den 22 augusti 2005 12:22
> > > To: Tom Gindin
> > > Cc: PKIX
> > > Subject: Re: Where to store SRV based names
> > >
> > >
> > >
> > >
> > > Tom Gindin wrote:
> > > > David:
> > > >
> > > > We shouldn't use the OID assigned to the subjectAltName
> > > extension.
> > > > Instead we should assign a new OID, to be assigned to an
> >OTHER-NAME.
> > >
> > >
> > > Hi Tom
> > >
> > > this is what I intended. Sorry if my last email was not clear
enough
> > >
> > >
> > > We
> > > > also can't use PrintableString with Stefan's syntax, because
> > > > PrintableString doesn't include underscore and the SRV key
normally
> > > > contains underscores. So what is the right string type:
IA5String,
> > > > VisibleString (a tighter fit than IA5String, but less familiar),
or
> > > > UTF8String (internationalizable)?
> > >
> > > It all depends upon what the DNS can store in its SRV RR.
IA5string
> > > would surely work, but maybe internationalised DNS can store
> >UFT8Strings
> > > as well, which would be better. We need a DNS expert to advise.
> > >
> > > > I agree with the general approach of defining a syntax
which
> >can
> > > > be used either within GeneralName or in a directory attribute.
> > >
> > > thanks
> > >
> > > David
> > >
> > > >
> > > > Tom Gindin
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > David Chadwick
> > > > Sent by: [email-masked]
> > > > 08/11/2005 05:25 AM
> > > >
> > > > To: PKIX
> > > > cc:
> > > > Subject: Where to store SRV based names
> > > >
> > > >
> > > >
> > > > As a result of my previous message and the various replies to
it, it
> > > > seems like the arguments against using the
> >subjectDirectoryAttributes
> > > > extension to store the attribute are
> > > >
> > > > i) we only have a hammer, so the extension has to be a nail
(i.e. we
> > > > only support subjectAltNames (and not SDA) so it has to go
there),
> >and
> > > >
> > > > ii) since attributes can be anything, we dont want to use them
to
> >store
> > > > this attribute, since attributes are a catch all.
> > > >
> > > > I dont actually find either arguement technically convincing,
> >although I
> > > > do find i) pragmatically convincing. (But if we were to extend
this
> > > > argument PKIX could have been stillborn, because by using this
> >argument
> > > > we could have said ten years ago that few people were supporting
> > > > certificate extensions so lets not use any of them :-)
> > > >
> > > > However, I do have a solution to offer as follows. Assume that
n.n.n
> >is
> > > > the OID assigned to the subjectAltNames extension. The we define
the
> > > > following attribute using this OID
> > > >
> > > > srvName ATTRIBUTE ::= {
> > > > WITH SYNTAX PrintableString (SIZE
> >(1..128))
> > > > EQUALITY MATCHING RULE caseIgnoreMatch
> > > > ID n.n.n }
> > > >
> > > > By doing this we ensure:
> > > > i) the extension will be carried in the subjectAltNames
extension
> > > > ii) the syntax and matching rules for the srv string are fully
and
> > > > compactly defined
> > > > iii) If anyone also wanted to store the string in LDAP as an
> >attribute
> > > > they could do so using the above definition.
> > > >
> > > > regards
> > > >
> > > > David
> > > >
> > > >
> > >
> > > --
> > >
> > > *****************************************************************
> > > David W. Chadwick, BSc PhD
> > > Professor of Information Systems Security
> > > The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
> > > Tel: +44 1227 82 3221
> > > Fax +44 1227 762 811
> > > Mobile: +44 77 96 44 7184
> > > Email: [email-masked]
> > > Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> > > Research Web site: http://sec.cs.kent.ac.uk
> > > Entrust key validation string: MLJ9-DU5T-HV8J
> > > PGP Key ID is 0xBC238DE5
> > >
> > > *****************************************************************